Audit Trails and Cribl Stream's Event Stream

This post covers two audit trails in a Cribl Stream deployment: internal logs and metrics the router can route as data, and the record global secrets changes leave in files, Git, and a Leader log.

Why the router itself needs an audit trail

A log router sits between nearly every logging source and nearly every destination, and its own state changes what anyone downstream can see: a routing change can move an entire stream to another store, a pipeline edit can strip fields before records land, and a destination's authentication setting decides whether a stream keeps reaching an endpoint.

Auditors treat that middlebox as part of the control surface. Frameworks like PCI DSS, SOC 2, and HIPAA generally expect an organization to demonstrate who changed a security-relevant configuration, when, and to what, and that expectation reaches logging middleware the same way it reaches firewalls.

So a router's audit trail should cover three things: configuration changes, the credential and encryption state of the paths it manages, and its own operational history, which lets an investigator reconstruct what was flowing at a given time.

The Cribl Internal source

The Cribl Internal Source page describes a Source that captures Cribl Stream's own internal logs and metrics and sends them through Routes and Pipelines. Under a Worker Group you choose between two options, CriblLogs and CriblMetrics. Their Input IDs are prefilled with the option names and cannot be changed, and the page notes that custom Cribl Internal Sources cannot be configured. Once enabled, you can send the events to Destinations through the Routing table or via QuickConnect.

The CriblMetrics option offers what the page calls Cribl's most up-to-date and precise view of event throughput and transformation, aggregated every 2 seconds at the Worker Process level. With the Full fidelity toggle on, the generated metrics include the cribl.logstream.host, cribl.logstream.index, cribl.logstream.project, cribl.logstream.source, and cribl.logstream.sourcetype families. Cribl Stream ships with a cribl_metrics_rollup Pipeline for coarser reporting: attach it to the Source as a pre-processing Pipeline, and its Rollup Metrics Function reports at a default Time Window of 30 seconds that you can adjust.

The CriblLogs option is coarser: it tracks logs written once per minute, which the page calls less granular than CriblMetrics. In Distributed mode, CriblLogs can process internal logs only from Worker Processes, with logs on the Leader remaining on the Leader. In both Distributed and Single-instance modes, the option omits API Process logs, meaning telemetry and license-validation traffic. In Cribl.Cloud, on Cribl-managed Worker Groups, the CriblLogs internal Source contains only logs related to Sources and Destinations.

Every event and metric from the Source carries two internal fields, source (set to cribl) and host (set to the hostname of the Cribl instance), and the page says to use those fields to guide the events through Cribl Routes. Metrics events can also carry a duplicated sourcetype attribute, and the page's fix is to enable the final Eval Function in the cribl_metrics_rollup Pipeline, or a clone of it, which applies this Filter expression, copied from the Cribl Internal Source page:

_metric && _metric.startsWith('cribl.logstream.sourcetype.')

That leaves only event_sourcetype, and, per the page, prevents duplicate sourcetype events from being routed to Destinations. The same duplication logic explains the event_source and event_host dimensions: because a downstream service such as Splunk might overwrite source or host, the Source copies their values into those dimensions so the originals remain intact. If your destination does not overwrite them, the page says to drop or suppress the added dimensions.

Global secrets: backup and audit

The Back Up, Audit, and Troubleshoot Global Secrets page starts from a location: on the Leader, Cribl persists global secrets configuration under $CRIBL_HOME/local/cribl/. There, secret-stores.yml declares each secret store, secret-folders.yml declares the folders (including the backing secretStoreId and sharing configuration), secret-folders/<folder-id>/global-secrets.yml holds per-folder secret metadata without values for sensitive fields, and secret-folders/<folder-id>/values.json holds encrypted values for folders backed by the built-in cribl secret store; it is not present for externally backed folders and is not tracked in Git. Cribl updates these files when you save changes, and the page says not to edit them manually.

On-prem, the files to back up on the Leader Node include the three YAML files, values.json (built-in store only, encrypted, not in Git), and $CRIBL_HOME/local/cribl/auth/cribl.secret, required to decrypt values.json. Git tracks the YAML metadata but excludes each values.json, so without it, the page warns, built-in store secrets cannot be recovered from Git alone. In Cribl.Cloud, Cribl backs up the built-in store's configuration and encrypted values itself, with restoration running through Cribl Support. Externally backed folders keep their values in memory only and re-fetch them from the provider when the Leader restarts, so the page says to plan disaster recovery for those folders separately.

For the audit itself, the page names two complementary views of global secrets activity. The first is Git-tracked metadata: a global commit carries the definition files like the rest of the Leader configuration, diffs show metadata and sharing rule changes rather than plaintext values, and the commit history records who committed. The second is the Leader's audit.log: create, update, delete, reload, and related operations on secret stores, secret folders, and global secrets each emit a JSON line carrying the time, the action, the resource type (one of global-secrets, secret-folders, or secret-stores), the authenticated user or API key context, resource identifiers, the outcome, and a reason in case of failure.

Two constraints stand out. Cribl never writes global secret values to audit.log, so the trail records actions on secrets without exposing them. And audit events are written only on the Leader, not per node.

The page demonstrates the format with this example line for deleting a global secret, copied from the global secrets page:

{"time":"2026-06-14T08:43:01.945Z","action":"delete","type":"global-secrets","user":"admin","id":"myid4","outcome":"success","folderId":"payments-secrets1","secretType":"text","requestId":"123a4567-8910-bcde-1f2g-34a5bcd678ef","service":"secrets"}

For Worker Groups and Edge Fleets the page adds a third mechanism: to give each a safe audit trail of global secret changes in Git, Cribl writes a marker file, global-secrets-marker.yml, under its configuration path. The file holds fingerprints of credential fields, not values, so diffs show which fields changed without listing secret values. Its structure, copied from the global secrets page:

'secretFolderId/globalSecretId':
  description: 'My global secret'
  secrets:
    username: a1b2c3d4e5f67890
    password: 90f8e7d6c5b4a321

Each fingerprint is the first 16 hexadecimal characters of the SHA-256 digest of the field's value, applied to sensitive fields such as password as well as non-sensitive ones such as username. Cribl refreshes the fingerprints when sharing rules change for a secret folder, when a folder reloads from an externally backed store, or when a shared secret is added, updated, or removed. A commit of Group or Fleet configuration always includes the marker file, and you cannot deselect it in the commit file list.

What the docs flag

The pages also flag these limitations:

• CriblLogs, written once per minute, might fail to reflect Worker Process crashes or restarts, in contrast to the every-2-second CriblMetrics aggregation.
• CriblLogs omits API Process logs (telemetry and license-validation traffic) in both Distributed and Single-instance modes, processes internal logs only from Worker Processes in Distributed mode, and on Cribl.Cloud-managed Worker Groups contains only logs related to Sources and Destinations.
• All Cribl internal fields are subject to change: the page says Cribl provides them to assist with analytics and diagnostics but does not guarantee that they will remain available.
• Marker fingerprints reflect what Cribl last wrote into Group or Fleet configuration; they do not prove which credential value a node is using at the moment.
• If an externally backed store is unavailable when the Leader restarts, the marker file can omit or remove entries, showing a diff even though the credentials did not change, and a subsequent refresh after the store recovers can show another diff.
• The page is explicit that fingerprints and descriptions facilitate audits but are not a substitute for access control, external provider audit logs, or runtime monitoring.

Frequently asked questions

Does Cribl Stream's audit log include global secret values?

No, Cribl never writes global secret values to the audit log on the Leader. Each line records the time, action, resource type, the authenticated user or API key context, the outcome, and a reason in case of failure. The logged operations cover create, update, delete, reload, and related operations on secret stores, folders, and secrets.

Where are Cribl Stream global secrets audit events written?

Cribl Stream writes them only on the Leader, as JSON lines to the Leader's audit log, not per node. A Git-tracked metadata view complements it: a global commit carries the definition files, and commit history records who committed the changes.

What does the Cribl Internal source in Cribl Stream expose?

The Cribl Internal Source exposes Cribl Stream's own internal logs and metrics as events that go through Routes and Pipelines, via two options. CriblLogs tracks logs written once per minute, while CriblMetrics aggregates event throughput and transformation every 2 seconds at the Worker Process level.

How does Cribl Stream record global secret changes for a Worker Group in Git?

Cribl Stream writes a marker file, global-secrets-marker.yml, under the Group's or Fleet's configuration path, holding fingerprints of credential fields rather than the secret values. Each fingerprint is the first 16 hexadecimal characters of the SHA-256 digest of the field's value, and a commit of Group or Fleet configuration always includes the file.