Check it is working

Your machine (Docker)

Check on it

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:

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.

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.

Google Cloud

Check it worked

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.

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.
• A metrics plane that stays empty means the service account is missing roles/monitoring.viewer.

Kubernetes

Check it worked

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

Four lines say it is healthy:

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.

This warning means one node cannot be reached:

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

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

The same four lines as under 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.