Filter metrics
All three tabs provide a branch selector, time range, Live toggle, Refresh button, and controls to expand or collapse every graph. Live mode is enabled by default and refreshes the graphs approximately every 30 seconds. The default time range is the previous 12 hours. The custom date picker is limited to the previous seven days. The remaining filters depend on the selected tab:
Opening Metrics from a shard or Postgres instance on the database overview
highlights that shard or server in the graphs. The Metrics page does not have
separate shard or server filter menus.
For ranges longer than 15 minutes, click and drag across a graph to narrow the
selected time range. Moving the pointer across one graph highlights the same
timestamp on the other graphs. The menu on an individual graph can save that
graph as an image.
Shard metrics
The Shards tab covers Postgres resource utilization, database activity, replication lag, and instance health. CPU, memory, IOPS, connections, locks, and pod status each have separate primary and replica graphs so you can compare their behavior.
The main graphs summarize the selected instances. Expanding a graph shows its
larger chart and, where available, its per-shard or per-instance breakdown. The
expanded CPU graphs also show memory utilization for the same instance, and the
expanded memory graphs break memory down into mapped, resident, active cache, and
inactive cache bytes.
Increasing replication lag means replica reads may return older data. If no
replica satisfies the router’s configured health and lag requirements, a query
targeted to replicas fails instead of running on a primary. See Choosing where
reads run.
When an out-of-memory event occurs in the selected period, the page also shows
a warning banner. Correlate the event with memory, connections, and query
activity before changing the configuration-profile size.
Storage metrics
The Storage tab separates primary and replica disk use and reports write-ahead log (WAL) archiving health.
Expanding either archive-rate graph shows a per-shard breakdown of successful
and failed operations together.
Investigate a rising archive age, failed archive operations, and unarchived WAL
together. Compare them with disk usage and IOPS from the same period.
Router metrics
Routers plan incoming statements, determine which shards need to participate, and combine distributed results. The Routers tab shows the following graphs for the selected branch or router group:
A query latency increase without a corresponding increase in Postgres resource
utilization can indicate that you should inspect routing behavior, query
fanout, or the work required to combine results.
Metrics elsewhere in the dashboard
The database overview and cluster-configuration pages use recent metrics to summarize router memory, primary CPU and memory, replica lag, and branch or per-shard storage. These summaries provide current infrastructure context. Use the Metrics tabs for historical time-series graphs.Interpret metrics in context
There is no single healthy value for every Neki workload. Establish a baseline for each branch and investigate changes from its normal behavior.- If one shard has higher CPU, IOPS, or storage use than the others, review its routed workload and data topology.
- If router latency rises while one shard is saturated, use Query Insights to find queries that reach that shard or make many shard calls.
- If replica lag increases, compare replica CPU, IOPS, and connection activity on Shards with WAL activity on Storage.
- If multiple instances approach their resource limits, review cluster sizing.
- If a graph changes suddenly, use its time range when searching Logs and Query Insights.