Skip to main content

Audit and Telemetry

Sentinel helps make model access observable and governable. Audit and telemetry are the product surfaces that make that possible.

Telemetry​

Telemetry is the operational view of request behavior. It helps teams answer questions such as:

  • what requests are flowing through the system
  • which provider and route handled them
  • what the latency and status profile looks like
  • whether policy, retries, or fallback were involved

In the hosted product, operators use request visibility to understand what happened, which route handled it, and whether Sentinel itself made a governance decision along the way.

Typical operator-facing signals include:

  • request path
  • provider and routed model
  • status and latency
  • policy outcome
  • retry or attempt metadata
  • tokens or cost when available

Audit​

Audit is the durable evidence trail. It helps answer questions such as:

  • who changed what in the control plane
  • which key or actor triggered a request
  • when a governance or security-relevant action happened
  • what decision the platform made and why

Audit is useful when a request issue turns into a governance, security, or change-management question rather than a simple runtime failure.

Request correlation​

The first operational check for most incidents is the Sentinel request ID:

x-sp-request-id

Treat it as the bridge between:

  • client-visible behavior
  • request records
  • telemetry events
  • audit trails

A request ID lets operators trace one event across runtime behavior, platform decisions, and evidence records.

Operational guidance​

A good operating model usually means:

  • defining retention expectations early
  • separating dashboards used for operations from audit exports used for evidence
  • making policy decisions queryable alongside request outcomes
  • confirming telemetry fields are sufficient for provider, endpoint, and retry analysis

The goal is to make observability useful in the moment and defensible later.