# Check it is working

## Your machine (Docker)

### Check on it

```sh
dbgorilla collector status
dbgorilla collector logs -f
```

The container is named `dbg-collector`, so `docker ps` and `docker logs dbg-collector` work too.

On CLI 0.8.0, `collector status` for a Docker install prints `Container:`, `Connection:` and
`Workload:` lines.  On a healthy install they read:

```text
Container:  running
Connection: connected
Workload:   collecting (pg_stat_statements in the postgres maintenance DB)
```

Read those lines rather than the exit code.  `collector status` exits 0 even when it cannot reach anything.

:::tip[Query analysis is a separate switch]

A running container and a connected collector say nothing about whether DBGorilla may fetch query
plans for you.  The `commands` list decides that; see
[Query plans and statistics are on by default](/docs/connect/docker/#query-plans-and-statistics-are-on-by-default).
:::

## Google Cloud

### Check it worked

```bash
dbgorilla collector status                              # CLI install
kubectl -n dbg-collector logs -f deploy/dbg-collector   # GKE
docker logs -f dbg-collector                            # VM
```

The four lines that say it is healthy are under [Kubernetes](#kubernetes).

Then look at what it found.  A primary with two read replicas should show three nodes, one writer and two readers, each with Cloud Monitoring metrics.  A Cloud SQL high availability standby is not a node: it has no endpoint and publishes no metrics, so a regional instance with no replicas shows one node, and that is correct.

The log names the failures you are most likely to see:

- A replica reported unreachable can mean the IAM flag was set on the primary and not on the replica.
- A refusal naming `GOOGLE_MANAGED_INTERNAL_CA` means the instance is on the default certificate mode; switch it, or accept the unverified transport as described in [Certificates](/docs/connect/google-cloud/#certificates).
- A metrics plane that stays empty means the service account is missing `roles/monitoring.viewer`.

## Kubernetes

### Check it worked

```bash
kubectl -n databases logs -f deploy/dbg-collector
```

Four lines say it is healthy:

```text
opamp websocket connected
opamp handshake complete
otelcol started
discovered component
```

Then look at what it found.  For a three-node cluster you want three nodes: one writer and two readers.  One node where you expect three points at the [`pg_monitor` grant](/docs/connect/kubernetes/#grants).

This warning means one node cannot be reached:

```text
no instance baseline and a node is unreachable; deferring topology post until all nodes are probed
```

The collector holds back the whole component until every node answers, so a single unreachable replica means **no data at all**, including from the primary.  Usual causes are a NetworkPolicy
that admits the collector to the primary's service but not to individual pods, or a `ca_cert`
path that does not exist in the container.

## CloudNativePG

### Check it worked

```bash
kubectl -n prod-db logs -f deploy/dbg-collector
```

The same four lines as under [Kubernetes](#kubernetes) say it is healthy.

Then confirm full mode actually happened.  A three-instance Cluster should show three members, one writer and two readers, each with its own metrics.

- Three members with standby metrics missing means the pod IPs are not reachable on 9187, usually because a NetworkPolicy admits the service but not the pods.
- One member, or a Cluster that shows no primary, means discovery fell back to metrics-only: check `rbac.namespaces` first, then set `mode = "enabled"` to make the failure loud.