Traffic analytics
Built-in screens with top channels and consumers, trends, drill-down and CSV exports.
The Dashboard's Analytics menu answers these questions from hourly aggregates of the audit log, with no external tooling to install:
- Which APIs matter - a ranking of channels by traffic and by distinct consumers
- Who consumes them - each consumer is a first-class entity with its own page
- How errors and latency trend over a day, a week, a month or a quarter
- Why the errors happen - authentication, rate limiting, upstream systems or the gateway itself
- What exactly happened - any point on a chart drills down to the actual requests in the audit log
The screens are fixed. For anything they do not answer, and for alerting, use the Prometheus metrics endpoint.
The four screens
The entry point is the Analytics menu in the Dashboard. All times are UTC and every screen offers the same windows: last 24 hours, last 7 days, last 30 days and last 90 days.
Overview
Total traffic, error rate and latency percentiles of the window, one traffic chart, and two rankings - the top 10 channels and the top 10 consumers, each row with its own trend line and each linking to its own screen.
Per channel
One channel's traffic, its error and latency numbers, the breakdown of its consumers, and the error-source split - how many errors were authentication failures, rate limits, upstream failures or gateway errors.
Per consumer
A consumer is a security definition - a partner, a customer or an internal caller. Its page shows everything that credential does across all channels: volume and error trends, which channels it calls, when it was last seen, and its own error-source split - whether its failures are authentication, rate limits, upstream systems or the gateway. Use it to answer questions such as when a customer went quiet or which one keeps hitting their rate limit.
Requests that failed authentication have no credential by definition - they aggregate under a fixed Anonymous consumer and show up in each channel's error split as authentication errors.
Drill-down
Any point on a per-channel chart, and every row of a consumer's channel table, links into the audit log pre-filtered to that channel, that credential and that time window - a spike at 14:00 is one click away from the actual requests with their CIDs and payloads, within audit retention.
CSV exports
Every screen exports its table as CSV - the CSV pill next to Copy in the chart header downloads the same rows the screen shows, with the current time window applied.
The anomaly marker
Points on the traffic charts can have a marker meaning "unusual for this hour of the week". The baseline for Tuesday 14:00 is the median of recent Tuesday-14:00 values, the band around it is a few median absolute deviations, and a point outside the band gets the marker.
Every marker is fully explainable from the chart itself - there is no model, no training and no configuration. It is a chart annotation, not a paging system: alerting stays with Prometheus and whatever alert manager you connect to it.
The rollup process
The screens read a durable store of hourly aggregates, not the live traffic tables. A standalone process, the rollup, reads new audit log events, aggregates them into hourly rows - per channel, consumer and status class - and exits.
In containers, the rollup runs from cron every five minutes and there is nothing to configure. Outside containers, it is one command:
or, from a source installation:
Schedule it with cron the same way the containers do:
The rollup is watermark-based and idempotent - it remembers the last event it has seen, rerunning it is always safe, and overlapping runs are harmless.
Because the aggregates are extracted before audit rows expire, audit retention does not bound the trends - hourly rows are a few per channel per hour and are kept indefinitely at negligible size, so a year-long trend query reads hundreds of rows, not millions.
The analytics store
By default, the hourly rows go to an SQLite database file called analytics.db and there is nothing to configure. Like the audit log, the store can live in an external database instead - the Zato_Analytics_DB_* environment variables mirror the audit log's Zato_Audit_Log_DB_* set exactly:
| Variable | Default | Description |
|---|---|---|
Zato_Analytics_DB_Type | sqlite | The database type - one of sqlite, mysql, postgresql or oracle |
Zato_Analytics_DB_Host | (none) | The host the database runs on |
Zato_Analytics_DB_Port | 3306, 5432 or 1521 | The port the database listens on, defaulting per database type |
Zato_Analytics_DB_Username | (none) | The username to connect with |
Zato_Analytics_DB_Password | (none) | The password to connect with |
Zato_Analytics_DB_Name | analytics.db | The database name - the service name with Oracle DB, or the full file path with SQLite |
Zato_Analytics_DB_SSL | off | Whether to encrypt the connections with SSL/TLS - on or off |
Zato_Analytics_DB_SSL_CA_File | (system store) | Path to the CA certificate the server certificate is verified against |
Zato_Analytics_DB_SSL_Cert_File | (none) | Path to the client certificate, for mutual TLS |
Zato_Analytics_DB_SSL_Key_File | (none) | Path to the client private key, for mutual TLS |
Zato_Analytics_DB_SSL_Verify | on | Whether to verify the server certificate and hostname when SSL is on |
The schema is created automatically the first time the rollup runs - there is no migration step. The rollup and the Dashboard both read these variables, so set them for both processes.
What feeds the screens
The screens show what the audit log records - a channel with its audit log checkbox turned off contributes nothing to analytics. The per-consumer pages rely on the audit log knowing which credential authenticated each request, which it records automatically for every audited channel.