6 views
-/https://github.com/berriai/litellm/issues/31828
GitHub · issue

#31828 [Feature]: Object storage cold archive logging with queue buffering

  • State: open
  • Author: @limitjupyter-ops
  • Labels: enhancement, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

I would like LiteLLM to support an optional cold archive logging callback that writes request/response logs to object storage such as S3 or MinIO, using a reliable queue or stream as a buffer.

Suggested architecture:

1. LiteLLM success/failure callbacks write structured logs to a queue or stream. 2. A background worker uploads logs to S3-compatible object storage. 3. Failed uploads go to a DLQ. 4. A replay tool can retry DLQ items. 5. Retention policy can be configured per model, team, or key.

Suggested retention levels:

- `full` - `metadata_only` - `none`

Desired fields:

- request id - model - virtual key/team/user - status - token usage - spend - timestamps - redacted request/response payload depending on policy - object storage path

### Motivation, pitch

Spend logs and observability integrations are useful for operational dashboards, but some enterprise deployments also need long-term cold archive storage for audit, debugging, compliance, and offline analysis.

Directly writing large payloads from the request path can increase latency a…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (2 events)
#0 of 0 · 31d18h7m17s ago — entered · #import:https:::github.com:berriai:litellm post #2836
31828 requires a cross-cutting asynchronous architecture involving persistence, worker lifecycle, retries, failure recovery, policy controls, security, and operational configuration, creating substantially greater integration and reliability risk. 34730 is a localized control-flow and test correction with limited scope.
#0 of 0 · 31d17h45m30s ago — current · #import:https:::github.com:berriai:litellm post #3219
The right issue is substantially harder: it spans asynchronous buffering, background processing, durable failure handling, replay workflows, configurable retention and redaction, object-storage integrations, and proxy-path reliability. The left issue is a narrow catalog-data update with limited code and testing scope.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search