Skip to content

Observability & Audit Settings

What this screen is for

Observability & Audit is one of the eight purpose groups of Platform Settings. It decides what the platform records about itself — distributed traces and metrics, the tamper-evident audit trail, application logs, and the search backend those logs land in — and, through three subsystems, where any of that is sent outside the deployment.

Seven cards hang under the group, in this order: Tracing & Metrics, Audit Trail, Logging, Dashboards & Search, Observability Export, SIEM / XDR Forwarding and Platform Alerts. The first four are lists of configuration values and are covered on this page. The last three hold no configuration value at all — they administer records with a lifecycle of their own, and each has its own page.

Only a handful of the values on the first four cards accept a write. The rest are shown so the inventory is complete, not so you can change them: most are read-only observations of the deployment, some are masked secrets you can only see the presence of, and two are real parameters the deployment owns. Expect to read this group far more often than you edit it.

What must exist first

This is a platform screen, reached in the platform context and served only to the platform tenant. Beyond that:

  • The permission to read platform configuration. It is what puts Platform Settings in the sidebar and what fetches the catalogue these cards count.
  • The permission to write platform configuration, for any change at all. Without it every value is readable and none carries an edit control.
  • Separate permissions again for the three subsystem screens. Each has its own read permission and its own write permission, described on its own page, and holding platform-configuration read does not carry them.

Decisions you make here

The catalogue is read once when you open the surface, so every count here and on every screen below was read at the same moment. The Posture filter above the cards narrows all of them at once to Editable, Read-only or Secrets, and a value falls into exactly one bucket — a secret is a secret whether or not it is writable.

Tracing & Metrics

Values covering trace and metric export, the telemetry collector and the alert evaluator. Most are read-only: the endpoint and protocol the services export telemetry to, the export queue, batch size and delay, the trace propagation and sampling settings, the resource attributes, and the collector's log level. They record what the deployment supplies; changing them means changing the deployment.

The ones that are not read-only are the important ones. The alert evaluation interval is writable, bounded between 10,000 and 900,000 milliseconds, and applies live — the evaluator re-reads it after each pass and re-arms its own schedule, so a new cadence takes effect within at most one old interval. It governs two things at once: how quickly a platform alert can fire, and how fresh the System Health document is.

The weekly alert digest slot is writable too, and applies live: the day of the week, the local time and the time zone at which the scheduled platform alerts are delivered as one weekly digest. The zone is a region time zone or UTC, never a fixed offset.

The collector debug verbosity is deployment-owned rather than writable, and basic is its only admitted value: normal and detailed write the records themselves into the collector log, which the log store ingests, so the collector refuses to start at either.

Audit Trail

Only one value here is a control. The audit retention period is writable with the platform-configuration write permission alone, bounded between 365 and 3,650 days, and applies live. The value is stamped onto each audit record as it is written, so it governs new records and does not rewrite the ones already stored.

Twelve months is a floor no administrator can lower: PCI DSS v4.0.1 requirement 10.5.1 asks for at least twelve months of audit-log history, and the platform keeps no other copy of the audit rows. The default is that floor, 365 days; raise it when a longer obligation applies, knowing the audit tables grow with it.

The rest is inventory: read-only entries describing where the audit store is and the roles that write and read it, and masked secrets — the key that signs audit events for tamper detection, and the credentials of the audit writer and reader roles.

Logging

Values for the log pipeline. Most are read-only: the log shipper's configuration and its log level, and the log levels of several platform services. One masked secret is the credential the log shipper authenticates to the search backend with.

The one deployment-owned value is the log ingestion start position, and the trade-off is worth knowing before the deployment is changed: reading from the head re-ships everything already on disk the first time a file is tailed, while reading from the end loses whatever was written before the collector started.

Masked secrets only: the search backend's administrator credential and the password protecting its TLS keystore. There is nothing editable on this card. What you can read is whether each is stored, never what it is — the platform substitutes a mask before sending, so the console never holds a copy, and there is no reveal control.

How it relates to other screens

The three subsystems in this group each have their own page:

What this group configures, other screens read. The audit trail these values govern is queried elsewhere, the live state the alert evaluator measures is drawn on the health panel, and the map of everything your installation is connected to is its own surface.

Where to read more