Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

NautheraAuditExportLagging

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

An audit exporter is more than 15 minutes behind the audit log.

Meaning

nauthera_audit_export_lag_seconds for the exporter named in the exporter label has been above the threshold (900 seconds) for fifteen minutes: the oldest record it has yet to deliver was stored that long ago. The exporter is failing (see NautheraAuditExportFailing), slow, or receiving records faster than it delivers them, or reading the audit log is slow.

Impact

The SIEM or detector reading the export sees events that late: an attack in progress shows up there only after the lag. No record is lost. Users and relying parties are not affected.

Diagnosis

  1. Lag and throughput: max by (exporter) (nauthera_audit_export_lag_seconds{job="<name>"}) and sum by (exporter, result) (rate(nauthera_audit_exported_records_total\{job="&lt;name&gt;"\}[5m])).
  2. Arrival rate into the log: sum(rate(nauthera_audit_events_total{job="<name>"}[5m])).
  3. Read errors: kubectl -n &lt;ns&gt; logs &lt;pod&gt; | jq 'select(.msg=="could not read the audit log to export it")', and the export errors as for NautheraAuditExportFailing.
  4. The lag is measured only by the replica holding the exporter's lease; the others report 0.

Mitigation

  • Failing deliveries: follow NautheraAuditExportFailing.
  • Volume: raise config.audit.export.batch_size (500) so each delivery carries more, or lower audit.level.
  • Slow reads: check database load; see NautheraDatabasePoolExhausted.

Escalation

Tell the owner of the SIEM or log pipeline. Open an issue if the lag grows while the exporter reports no errors and the database is healthy, with the lag, throughput and event-rate graphs.

Alert runbooks · Generated from internal/runbook/alerts.yaml and operator/internal/runbook/alerts.yaml in nauthera-server.