# Manage collectors ## Your machine (Docker) ### Stopping and removing ```sh dbgorilla collector stop # pause, keeping its identity dbgorilla collector start # resume dbgorilla collector uninstall # remove and deprovision its identity ``` `stop` is reversible. `uninstall` is not: it discards the collector's identity on the server, and reinstalling gives you a new collector rather than the same one back. There is one exception: if you are signed out, `uninstall` cannot reach the server, so it removes the local container and leaves the identity and local state in place, then tells you to sign in and run it again. Nothing is orphaned, and the destructive half has not happened yet. If `install` says a collector already exists, run `dbgorilla collector status` first. The error suggests `uninstall`, but that destroys a working collector to solve a problem you may not have. ### Removing the database from DBGorilla After `uninstall`, the database stays on Home, marked Disconnected. To remove it: 1. Click your name at the bottom of the sidebar, then **Admin Portal**. 2. Open **Components**. 3. Expand the database and click **Delete Component**. 4. Confirm with **Delete**. The confirmation says what this does: it permanently removes the component and all of its stored topology and telemetry (metrics, workload, activity), and it cannot be undone. ## AWS ### Day-to-day ```sh dbgorilla collector status # what it is and whether it is connected dbgorilla collector logs -f # follow the logs dbgorilla collector stop # pause it; the identity is kept dbgorilla collector start # resume dbgorilla collector restart ``` `stop` and `start` are reversible. The task stops; the config, the secrets and the identity stay where they are. :::caution[`status` always exits 0] It returns success even when the collector is unreachable, its stack is gone, or the control plane has never heard from it. Check the output and ignore the exit code. `dbgorilla collector status && echo ok` prints `ok` for a dead collector. The two lines that matter are `Deploy:` (whether it is running at all) and `Connection:` (whether DBGorilla can see it; `not yet seen by control plane` means no). ::: `logs` reads CloudWatch Logs, so it needs valid AWS credentials. If yours have expired, `logs` fails even though the collector is fine. ### Removing it ```sh dbgorilla collector uninstall ``` This deletes the CloudFormation stack, deprovisions the identity on the server, and clears the local config and secrets. It asks for confirmation first. If you are signed out, it deletes the stack but keeps the identity and your local state, and tells you to sign in and run it again, so the identity is never left orphaned. ## Google Cloud ### Day-to-day ```sh dbgorilla collector status # deployment state, and whether it is connected dbgorilla collector logs -f # follow the container logs from Cloud Logging dbgorilla collector stop # pause it; the identity is kept dbgorilla collector start # resume dbgorilla collector restart ``` `stop` scales the instance group to zero and `start` back to one. Both are reversible; the config, the secrets and the identity stay where they are. :::caution[`status` always exits 0] It returns success even when the collector is unreachable, its deployment is gone, or the control plane has never heard from it. Check the output and ignore the exit code. The two lines that matter are `Deploy:` (whether it is running at all) and `Connection:` (whether DBGorilla can see it; `not yet seen by control plane` means no). A deployment that reports ACTIVE with no connection usually means the VPC has no route to the internet. ::: `logs` reads Cloud Logging, so it needs valid Google Cloud credentials. If yours have expired, `logs` fails even though the collector is fine. Re-running the install updates a collector in place. `dbgorilla collector install --target gcp` re-discovers the database it monitors, so a read replica added since joins its login scope; with `--db-instance-id` it moves to another database. Its identity, endpoints, image and networking stay as they are, and nothing is torn down. A password-auth collector keeps the password already in Secret Manager; `--db-password` rotates it, and `--db-password ""` moves it to IAM authentication. ```sh dbgorilla collector upgrade # roll to the newest collector image ``` `upgrade` changes only the image. Both commands wait for the instance to roll to the new configuration, and a stopped collector stays stopped through either. Where the collector runs cannot change in place: to move it to another project, VPC or subnetwork, `uninstall` and install again. ### Removing it ```sh dbgorilla collector uninstall ``` This deletes the Infrastructure Manager deployment and waits for its resources to go, removes the secrets the CLI wrote to Secret Manager, deprovisions the identity on the server, and clears the local config. It asks for confirmation first. If it is interrupted mid-way, the identity has not been deprovisioned: check `dbgorilla collector status` and run `uninstall` again. ## Kubernetes ### Upgrading and removing ```bash helm upgrade dbg-collector oci://dbgorillapublic.azurecr.io/charts/dbg-collector \ --namespace databases \ --values ./values.yaml \ --set-file config.inline=./collector.toml helm uninstall dbg-collector --namespace databases ``` `helm uninstall` removes the workload but does **not** deprovision the collector's identity in DBGorilla. To retire a collector permanently, delete it in the app as well. A new install always means a new collector; the old one does not resume. ## CloudNativePG ### Upgrading and removing Same as for [Kubernetes](#upgrading-and-removing). `helm uninstall` removes the Role and the binding with the rest of the release.