Skip to main content
DNZ can send its query log, its audit log or DNZ Proxy’s request log somewhere else as it is written, like Cloudflare Logpush: an HTTP endpoint (a SIEM, Vector, Fluent Bit, Logstash, Splunk), Grafana Loki, S3-compatible storage or syslog. Set it up under Settings → Integrations → Log push (superadmins). On a --proxy-only server only DNZ Proxy’s request log can be pushed.

What is sent

Query log
Audit log
DNZ Proxy request log
A query log job can take only some answers: local, forwarded, cached, blocked, error.

DNZ Proxy’s request log

The nodes push their own lines. The log stays on each node and nothing goes through DNZ, so proxy traffic never loads it. A job goes to the nodes of the proxies it names (none named: every DNZ Proxy) with their configuration; each node reads its own log from a cursor it keeps, batches and sends.
Each node has to reach the destination itself, and localhost is each node’s own machine. Test sends its line from DNZ, so a node that can’t reach the destination shows on the job’s row, not there.
A job’s passwords and keys reach the node over its authenticated stream and stay in its memory: they are never written to its state directory. A node that restarts while DNZ is away keeps serving and logging, and pushes again once it is connected, from where it stopped. A push sends at most 50,000 lines, so with Every request the job’s interval decides how much traffic it keeps up with: 1,666 requests a second at the default 30 seconds, 10,000 at 5 seconds. Measurements: Proxy benchmarks. While a proxy has no such job a visit costs nothing more. How it goes shows on the job’s row: how many of its nodes push, fail or don’t report, the longest lag and the last error, and Nodes lists them. Nodes older than this version skip the job, serving and logging as before: the row names them, so you know which to update.

Destinations

HTTP

The batch as NDJSON (optionally gzipped) with your headers. Vector, Fluent Bit, Logstash and Splunk HEC (/services/collector/raw) take it.

Grafana Loki

/loki/api/v1/push with labels job=dnz, dataset, server and yours; tenant and basic auth.

S3-compatible

One gzipped NDJSON object per batch, by day: AWS S3, Cloudflare R2, Backblaze B2, MinIO.

Syslog

RFC 5424 over UDP, or TCP with octet counting; the JSON is the message.
localhost or 127.0.0.1 is DNZ’s own machine (in Docker, its container). Use the address DNZ reaches the destination on; the form warns otherwise.

Try it with Vector

1

Run a receiver

vector.yaml
2

Point a job at it

add sends a test line right away; docker logs -f vector shows the queries as they come.

Delivery

  • Every 30 seconds by default (5 to 3600), in batches of 5,000 lines.
  • A new job starts with what is logged from then on.
  • Each job keeps a cursor: a push that fails is sent again from the same place, so nothing is lost or sent twice while the log still has it.
  • Every server pushes its own query log ("server" tells them apart); only the cluster’s leader pushes the shared audit log.
  • Every DNZ Proxy node pushes its own request log, with its own cursor. As a Loki server label, in an S3 object’s name and as the syslog host it is <proxy>-<node>.

CLI

dnz_logpush_lines_total and dnz_logpush_failures_total are on the metrics endpoint, per server and with {source="proxy",job,proxy,node} per node, with dnz_logpush_lag_seconds, dnz_logpush_last_push_timestamp_seconds and dnz_logpush_node_pushing. The MCP tool logpush_jobs lists the jobs with what their nodes report.