Observability overview

An API7 Gateway deployment has four layers that fail independently: the data plane that proxies traffic, the control plane that configures it, the PostgreSQL database that stores that configuration, and the Dashboard that people log in to. They do not emit the same signals, and API7 does not emit all of them — some come from your own platform. This page says which is which, so you know what you still have to instrument.

What each layer emits

Two consequences worth reading twice:

• Database observability is yours to build. API7 stores every route, service, consumer and certificate in PostgreSQL, but it exports no database metrics. If you want to know about connection-pool exhaustion, replication lag or disk pressure before they take the control plane down, you have to instrument PostgreSQL yourself.
• Only the data plane is traced. A slow Dashboard save produces no span. Traces answer questions about proxied traffic, not about configuration operations.

Metrics

Data-plane metrics come from the prometheus plugin and are exposed on port 9091. Monitor Metrics covers enabling the plugin and the scrape configuration; the prometheus plugin reference (opens in Plugin Hub docs) has the full metric and label list.

Two operational cautions:

• The metrics depend on a prometheus global rule. If your declarative configuration omits global_rules.prometheus, an adc sync deletes it and all gateway metrics stop.
• Labels like route, consumer and matched_uri multiply series. Review cardinality against your Prometheus capacity before enabling them in a large deployment.

If you already run Prometheus, Use an Existing Prometheus covers both migration paths — scraping data planes directly, or receiving metrics through the DP Manager's remote-write channel.

Logging

The gateway writes an access log and an error log. Configure Centralized Logging documents the default format string, the JSON variant, and where each component writes.

Shipping them off the node:

• On Kubernetes, Collect Gateway Logs on Kubernetes covers an OpenTelemetry Collector DaemonSet, and Send Kubernetes Error Logs to Splunk covers error-log forwarding.
• Send Access Logs to Splunk uses the gateway's own logger plugin instead of a collector.
• Include Consumer Labels in Access Logs adds tenant or team attribution to each line, which is what makes per-consumer chargeback and per-team error budgets possible.

To correlate a log line with a trace, add $opentelemetry_trace_id and $opentelemetry_span_id to the log format — Configure Distributed Tracing shows the format string.

Tracing

The opentelemetry plugin emits one span per request with the route and status attached, and exports over OTLP. Configure Distributed Tracing covers the collector address, sampling, and the extra attributes worth attaching.

For a single misbehaving route, a trace backend is often more machinery than you need. Capture Request Traces with Debug Sessions records matching requests — including per-plugin and per-phase timings and the request's own log lines — from the Dashboard, without a collector.

Alerts and SLOs

Two mechanisms, and you will probably want both:

• The Dashboard's built-in alerting evaluates control-plane events — an instance going offline, a certificate approaching expiry, a licence quota being crossed. These are things Prometheus cannot see. Start at Configure Alerts.
• Prometheus alerting covers request-level symptoms: error ratio, latency, saturation. Alerts and SLOs has the SLIs, the PromQL, and how to choose your own thresholds.

Incident Dashboards has the panel queries for triage.

Related

• Ports and Endpoints — every listener named here, and what should reach it.
• Configure Readiness and Liveness Probes — wiring the health endpoints into Kubernetes or a load balancer.
• Troubleshoot API7 Gateway — turning these signals into a diagnosis.