Operations
Meerkat sits on the path of every request, so the questions an operator brings to it are always the same few: is traffic arriving, is it getting through, and who changed something. Each has one screen, and this page says which.
Where to look
| The question | Where it is answered |
|---|---|
| Is traffic arriving, and how fast | The traffic screen, the Metrics entry of the rail |
| Is a service still answering | Upstream health, and the Routes list marks what fails |
Why was that call refused with 429 |
Rate limits |
| Who changed this, and when | The audit trail, which can also be sent to a collector |
| Who called what, and how it went | Logs |
| Where the seconds of THAT request went | Traces |
| Did the scheduled call run, and how | Scheduled calls, the Scheduler entry of the rail |
| How traces, metrics, audit and logs reach my collector | OpenTelemetry export, under Infra, OpenTelemetry |
| Is this node ready for traffic | Health probes |
| When does that certificate expire | TLS and certificates |
| What is actually in a backup | Backup and restore |
| Where does this password live | The vault |
What the gateway records, and for how long
| What | Where it lives | For how long |
|---|---|---|
| Traffic counters | memory, on each node | one hour, lost on restart |
| Endpoint history | memory, on each node | seventy minutes, one point a minute |
| Audit trail | the database | a year by default, chosen by root (three months to five years), then purged |
| Restore points | the database | kept, never pruned |
| Operational log | standard error, structured | whatever collects it |
| Access log | standard output, structured, off by default | whatever collects it |
| Traces | nothing here: exported over OTLP | the collector, a few days |
Nothing about traffic is written to disk, and that is deliberate: an app gateway is not a time-series database, and an installation that wants a year of curves pushes the counters over OTLP to a collector that writes them into the one it already runs (metrics).
Logs are structured. The level is set at startup, and the console can change it live. An access log - one line per request crossing the front door - turns on when asked. It carries the same identifier as traces, which is the join between a line of the gateway's and a service's own business audit.
A backup and a configuration export are not the same thing
A snapshot is the whole database: accounts, sessions, the vault, the audit trail, the certificates. It is what restores this installation.
A configuration export is routes, roles, authorities, themes and settings, as a file a person can read and diff. It reproduces a gateway elsewhere. It carries no account, no certificate and no secret value, so it is not a backup.
What is per node and what is shared
| Kept by each node | Shared through the database |
|---|---|
| traffic counters (summed for the screen) | the audit trail and the restore points |
| the circuit breaker's verdict on an upstream | routes, certificates, settings, the vault |
| rate-limit counters | the brute-force counter on sign-ins |
| the live channel's own subscribers (messages are relayed) | sessions and API tokens |