Monitoring

For liveness checks, Galleon provides two endpoints without authentication:

healthz suits liveness probes; readyz — readiness probes and the post-deployment readiness check.

Restricting access

Access to the health endpoints is restricted by the server.monitoring_allowlist address list; the default is loopback only, so local checks work without setup while network requests are denied.

Rules:

• the TCP connection address is checked; X-Forwarded-* headers are not considered — a request through a reverse proxy is judged by the address of the proxy itself;
• a denial is indistinguishable from a nonexistent path (404); the reason is visible only in the log (deny_reason=monitoring_ip_denied);
• an explicitly set empty list denies everyone, including local checks;
• the 0.0.0.0/0 value opens the endpoints to everyone.

server:
  monitoring_allowlist: ["127.0.0.0/8", "::1/128", "10.0.0.0/8"]

If the checks do not come from loopback, their addresses have to be on the list: for external monitoring through a reverse proxy that is the proxy’s own address. The exact source address is visible in the access log of the rejected request — the client_ip field in the record with deny_reason=monitoring_ip_denied.

Observing the instance

Observation is built on logs and PostgreSQL tooling:

• The server log — three fields absent on healthy traffic provide ready-made monitors: sqlstate (database errors), deny_reason (access denials), served_stale (external registry degradation). See Logging for details.
• The state of external registry connections — the “Remote” column on the “Settings” → “Repositories” page (see Repositories).
• PostgreSQL — the standard tooling: activity by the galleon and galleon-oci-meta application names (the connections serving container images carry no label), database size, slow queries.
• Disk — the storage directory usage.