litellm-observability

LiteLLM Observability

Workflow

1. Define the diagnostic questions, required fields, data classification, retention period, and accessors.
2. Choose SDK callback, Proxy logging, OpenTelemetry, or an external platform.
3. Check the LiteLLM version, callback schema, OpenTelemetry v1/v2, and additional packages.
4. By default, do not send full prompts, responses, secrets, or sensitive metadata to third parties.
5. Create a request ID to correlate client, Proxy, provider, guardrail, MCP, and DB events.
6. Test success, provider error, timeout, budget exceeded, fallback, and guardrail blocked.
7. Deliver query methods, reproduction steps, and actual trace evidence.

When secure configuration, OpenTelemetry considerations, and experiment specifications are needed, read Experiments and References。

Security Baseline

• Third-party observability disables message logging by default.
• Do not write API keys, Authorization headers, database URLs, or full sensitive content to logs.
• Before enabling content logging, data classification, masking, retention period, and third-party data processing review must be completed.
• Failure callbacks must also apply the same masking policy.

Acceptance

• Each request can correlate the required events by request ID.
• Success and at least four failure types can be queried.
• Traces or logs do not contain test secrets or unmasked sensitive data.
• Query results can explain one fallback or guardrail event.