📈 Prometheus Metriken

Info

✨ Prometheus Metriken ist auf LiteLLM Enterprise verfügbar

Holen Sie sich einen kostenlosen 7-Tage-Testschlüssel

LiteLLM stellt einen /metrics Endpunkt zur Verfügung, den Prometheus abfragen kann

Schnellstart

Wenn Sie die LiteLLM CLI mit litellm --config proxy_config.yaml verwenden, müssen Sie pip install prometheus_client==0.20.0 installieren. Dies ist bereits im LiteLLM Docker Image vorinstalliert

Fügen Sie dies zu Ihrer proxy config.yaml hinzu

model_list:
 - model_name: gpt-3.5-turbo
    litellm_params:
      model: gpt-3.5-turbo
litellm_settings:
  callbacks: ["prometheus"]

Starten Sie den Proxy

litellm --config config.yaml --debug

Testanfrage

curl --location 'http://0.0.0.0:4000/chat/completions' \
    --header 'Content-Type: application/json' \
    --data '{
    "model": "gpt-3.5-turbo",
    "messages": [
        {
        "role": "user",
        "content": "what llm are you"
        }
    ]
}'

Metriken anzeigen unter /metrics, Besuchen Sie https://:4000/metrics

https://:4000/metrics

# <proxy_base_url>/metrics

Virtuelle Schlüssel, Teams, Interne Benutzer

Verwenden Sie dies zur Verfolgung pro Benutzer, Schlüssel, Team usw.

Metrikname	Beschreibung
`litellm_spend_metric`	Gesamtausgaben, pro `"user", "key", "model", "team", "end-user"`
`litellm_total_tokens`	Eingabe- + Ausgabetokens pro `"end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "model"`
`litellm_input_tokens`	Eingabetokens pro `"end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "model"`
`litellm_output_tokens`	Ausgabetokens pro `"end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "model"`

Team - Budget

Metrikname	Beschreibung
`litellm_team_max_budget_metric`	Maximales Budget für Team-Labels: `"team_id", "team_alias"`
`litellm_remaining_team_budget_metric`	Verbleibendes Budget für Team (ein in LiteLLM erstelltes Team) Labels: `"team_id", "team_alias"`
`litellm_team_budget_remaining_hours_metric`	Stunden bis zum Zurücksetzen des Team-Budgets Labels: `"team_id", "team_alias"`

Virtueller Schlüssel - Budget

Metrikname	Beschreibung
`litellm_api_key_max_budget_metric`	Maximales Budget für API-Schlüssel-Labels: `"hashed_api_key", "api_key_alias"`
`litellm_remaining_api_key_budget_metric`	Verbleibendes Budget für API-Schlüssel (ein in LiteLLM erstellter Schlüssel) Labels: `"hashed_api_key", "api_key_alias"`
`litellm_api_key_budget_remaining_hours_metric`	Stunden bis zum Zurücksetzen des API-Schlüssel-Budgets Labels: `"hashed_api_key", "api_key_alias"`

Virtueller Schlüssel - Ratenbegrenzung

Metrikname	Beschreibung
`litellm_remaining_api_key_requests_for_model`	Verbleibende Anfragen für einen LiteLLM virtuellen API-Schlüssel, nur wenn ein modellspezifisches Ratenlimit (rpm) für diesen virtuellen Schlüssel festgelegt wurde. Labels: `"hashed_api_key", "api_key_alias", "model"`
`litellm_remaining_api_key_tokens_for_model`	Verbleibende Tokens für einen LiteLLM virtuellen API-Schlüssel, nur wenn ein modellspezifisches Token-Limit (tpm) für diesen virtuellen Schlüssel festgelegt wurde. Labels: `"hashed_api_key", "api_key_alias", "model"`

Budget-Metriken beim Start initialisieren

Wenn Sie möchten, dass LiteLLM die Budget-Metriken für alle Schlüssel und Teams emittiert, unabhängig davon, ob sie Anfragen erhalten oder nicht, setzen Sie prometheus_initialize_budget_metrics auf true in der config.yaml

So funktioniert es

Wenn prometheus_initialize_budget_metrics auf true gesetzt ist
- Alle 5 Minuten führt LiteLLM einen Cronjob aus, um alle Schlüssel und Teams aus der Datenbank zu lesen
- Anschließend emittiert es die Budget-Metriken für jeden Schlüssel und jedes Team
- Dies dient zur Befüllung der Budget-Metriken auf dem /metrics Endpunkt

litellm_settings:
  callbacks: ["prometheus"]
  prometheus_initialize_budget_metrics: true

Proxy-Level Tracking Metriken

Verwenden Sie dies, um die allgemeine LiteLLM Proxy-Nutzung zu verfolgen.

Tatsächliche Verkehrsrate zum Proxy verfolgen
Anzahl der **clientseitigen** Anfragen und Fehler bei Anfragen an den Proxy

Metrikname	Beschreibung
`litellm_proxy_failed_requests_metric`	Gesamtzahl der fehlgeschlagenen Antworten vom Proxy – der Client hat keine Erfolgsantwort von LiteLLM Proxy erhalten. Labels: `"end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "exception_status", "exception_class"`
`litellm_proxy_total_requests_metric`	Gesamtzahl der an den Proxy-Server gesendeten Anfragen – Verfolgung der clientseitigen Anfragen. Labels: `"end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "status_code"`

LLM Provider Metriken

Verwenden Sie dies für die Überwachung von LLM API-Fehlern und die Verfolgung verbleibender Raten- und Token-Limits

Verfolgte Labels

Label	Beschreibung
litellm_model_name	Der Name des LLM-Modells, das von LiteLLM verwendet wird
requested_model	Das im Request gesendete Modell
model_id	Die model_id der Bereitstellung. Automatisch von LiteLLM generiert, jede Bereitstellung hat eine eindeutige model_id
api_base	Die API-Basis der Bereitstellung
api_provider	Der LLM API-Provider, der für den Provider verwendet wird. Beispiel (azure, openai, vertex_ai)
hashed_api_key	Der gehashte API-Schlüssel der Anfrage
api_key_alias	Der Alias des verwendeten API-Schlüssels
team	Das Team der Anfrage
team_alias	Der Alias des verwendeten Teams
exception_status	Der Status der Ausnahme, falls vorhanden
exception_class	Die Klasse der Ausnahme, falls vorhanden

Erfolg und Fehler

Metrikname	Beschreibung
`litellm_deployment_success_responses`	Gesamtzahl der erfolgreichen LLM API-Aufrufe für die Bereitstellung. Labels: `"requested_model", "litellm_model_name", "model_id", "api_base", "api_provider", "hashed_api_key", "api_key_alias", "team", "team_alias"`
`litellm_deployment_failure_responses`	Gesamtzahl der fehlgeschlagenen LLM API-Aufrufe für eine bestimmte LLM-Bereitstellung. Labels: `"requested_model", "litellm_model_name", "model_id", "api_base", "api_provider", "hashed_api_key", "api_key_alias", "team", "team_alias", "exception_status", "exception_class"`
`litellm_deployment_total_requests`	Gesamtzahl der LLM API-Aufrufe für die Bereitstellung – Erfolg + Fehler. Labels: `"requested_model", "litellm_model_name", "model_id", "api_base", "api_provider", "hashed_api_key", "api_key_alias", "team", "team_alias"`

Verbleibende Anfragen und Tokens

Metrikname	Beschreibung
`litellm_remaining_requests_metric`	Verfolgt `x-ratelimit-remaining-requests`, das von der LLM API-Bereitstellung zurückgegeben wird. Labels: `"model_group", "api_provider", "api_base", "litellm_model_name", "hashed_api_key", "api_key_alias"`
`litellm_remaining_tokens`	Verfolgt `x-ratelimit-remaining-tokens`, das von der LLM API-Bereitstellung zurückgegeben wird. Labels: `"model_group", "api_provider", "api_base", "litellm_model_name", "hashed_api_key", "api_key_alias"`

Bereitstellungsstatus

Metrikname	Beschreibung
`litellm_deployment_state`	Der Status der Bereitstellung: 0 = einwandfrei, 1 = teilweiser Ausfall, 2 = vollständiger Ausfall. Labels: `"litellm_model_name", "model_id", "api_base", "api_provider"`
`litellm_deployment_latency_per_output_token`	Latenz pro Ausgabetoken für die Bereitstellung. Labels: `"litellm_model_name", "model_id", "api_base", "api_provider", "hashed_api_key", "api_key_alias", "team", "team_alias"`

Fallback (Failover) Metriken

Metrikname	Beschreibung
`litellm_deployment_cooled_down`	Anzahl der Male, die eine Bereitstellung durch die LiteLLM Load Balancing Logik heruntergefahren wurde. Labels: `"litellm_model_name", "model_id", "api_base", "api_provider", "exception_status"`
`litellm_deployment_successful_fallbacks`	Anzahl erfolgreicher Fallback-Anfragen vom primären Modell -> Fallback-Modell. Labels: `"requested_model", "fallback_model", "hashed_api_key", "api_key_alias", "team", "team_alias", "exception_status", "exception_class"`
`litellm_deployment_failed_fallbacks`	Anzahl fehlgeschlagener Fallback-Anfragen vom primären Modell -> Fallback-Modell. Labels: `"requested_model", "fallback_model", "hashed_api_key", "api_key_alias", "team", "team_alias", "exception_status", "exception_class"`

Anfragelatenz Metriken

Metrikname	Beschreibung
`litellm_request_total_latency_metric`	Gesamtlatenz (Sekunden) für eine Anfrage an den LiteLLM Proxy Server – verfolgt für die Labels "end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "model"
`litellm_overhead_latency_metric`	Latenz-Overhead (Sekunden), der durch die LiteLLM-Verarbeitung hinzugefügt wird – verfolgt für die Labels "end_user", "hashed_api_key", "api_key_alias", "requested_model", "team", "team_alias", "user", "model"
`litellm_llm_api_latency_metric`	Latenz (Sekunden) nur für den LLM API-Aufruf – verfolgt für die Labels "model", "hashed_api_key", "api_key_alias", "team", "team_alias", "requested_model", "end_user", "user"
`litellm_llm_api_time_to_first_token_metric`	Zeit bis zum ersten Token für den LLM API-Aufruf – verfolgt für die Labels `model`, `hashed_api_key`, `api_key_alias`, `team`, `team_alias`[Hinweis: Wird nur für Streaming-Anfragen emittiert]

[BETA]Benutzerdefinierte Metriken

Verfolgen Sie benutzerdefinierte Metriken auf Prometheus für alle oben genannten Ereignisse.

Definieren Sie die benutzerdefinierten Metriken in der config.yaml

model_list:
  - model_name: openai/gpt-3.5-turbo
    litellm_params:
      model: openai/gpt-3.5-turbo
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  callbacks: ["prometheus"]
  custom_prometheus_metadata_labels: ["metadata.foo", "metadata.bar"]

Senden Sie eine Anfrage mit den benutzerdefinierten Metadaten-Labels

curl -L -X POST 'http://0.0.0.0:4000/v1/chat/completions' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <LITELLM_API_KEY>' \
-d '{
    "model": "openai/gpt-3.5-turbo",
    "messages": [
      {
        "role": "user",
        "content": [
          {
            "type": "text",
            "text": "What's in this image?"
          }
        ]
      }
    ],
    "max_tokens": 300,
    "metadata": {
        "foo": "hello world"
    }
}'

Überprüfen Sie Ihren /metrics Endpunkt auf die benutzerdefinierten Metriken

... "metadata_foo": "hello world" ...

Systemgesundheit überwachen

Um die Gesundheit von LiteLLM-begleitenden Diensten (Redis / PostgreSQL) zu überwachen, führen Sie Folgendes aus:

model_list:
 - model_name: gpt-3.5-turbo
    litellm_params:
      model: gpt-3.5-turbo
litellm_settings:
  service_callback: ["prometheus_system"]

Metrikname	Beschreibung
`litellm_redis_latency`	Histogramm der Latenz für Redis-Aufrufe
`litellm_redis_fails`	Anzahl der fehlgeschlagenen Redis-Aufrufe
`litellm_self_latency`	Histogramm der Latenz für erfolgreiche LiteLLM API-Aufrufe

DB Transaktions-Queue-Gesundheitsmetriken

Verwenden Sie diese Metriken, um die Gesundheit der DB Transaktions-Queue zu überwachen. Z.B. Überwachung der Größe der In-Memory- und Redis-Puffer.

Metrikname	Beschreibung	Speichertyp
`litellm_pod_lock_manager_size`	Zeigt an, welcher Pod die Sperre zum Schreiben von Updates in die Datenbank hat.	Redis
`litellm_in_memory_daily_spend_update_queue_size`	Anzahl der Elemente in der täglichen In-Memory-Ausgaben-Update-Queue. Dies sind die aggregierten Ausgabenprotokolle für jeden Benutzer.	In-Memory
`litellm_redis_daily_spend_update_queue_size`	Anzahl der Elemente in der täglichen Redis-Ausgaben-Update-Queue. Dies sind die aggregierten Ausgabenprotokolle für jeden Benutzer.	Redis
`litellm_in_memory_spend_update_queue_size`	In-Memory-aggregierte Ausgabenwerte für Schlüssel, Benutzer, Teams, Teammitglieder usw.	In-Memory
`litellm_redis_spend_update_queue_size`	Redis-aggregierte Ausgabenwerte für Schlüssel, Benutzer, Teams usw.	Redis

🔥 Von LiteLLM gepflegte Grafana Dashboards

Link zu von LiteLLM gepflegten Grafana Dashboards

https://github.com/BerriAI/litellm/tree/main/cookbook/litellm_proxy_server/grafana_dashboard

Hier ist ein Screenshot der Metriken, die Sie mit dem LiteLLM Grafana Dashboard überwachen können

Veraltete Metriken

Metrikname	Beschreibung
`litellm_llm_api_failed_requests_metric`	veraltet verwenden Sie `litellm_proxy_failed_requests_metric`
`litellm_requests_metric`	veraltet verwenden Sie `litellm_proxy_total_requests_metric`

Authentifizierung am /metrics Endpunkt hinzufügen

Standardmäßig ist der /metrics Endpunkt nicht authentifiziert.

Sie können die Ausführung der LiteLLM-Authentifizierung auf dem /metrics Endpunkt aktivieren, indem Sie Folgendes in der Konfiguration festlegen

litellm_settings:
  require_auth_for_metrics_endpoint: true

FAQ

Was sind `_created` vs. `_total` Metriken?

_created Metriken sind Metriken, die beim Start des Proxys erstellt werden
_total Metriken sind Metriken, die für jede Anfrage inkrementiert werden

Sie sollten die _total Metriken für Ihre Zählungszwecke verwenden

📈 Prometheus Metriken

Schnellstart​

Virtuelle Schlüssel, Teams, Interne Benutzer​

Team - Budget​

Virtueller Schlüssel - Budget​

Virtueller Schlüssel - Ratenbegrenzung​

Budget-Metriken beim Start initialisieren​

Proxy-Level Tracking Metriken​

LLM Provider Metriken​

Verfolgte Labels​

Erfolg und Fehler​

Verbleibende Anfragen und Tokens​

Bereitstellungsstatus​

Fallback (Failover) Metriken​

Anfragelatenz Metriken​

[BETA]Benutzerdefinierte Metriken​

Systemgesundheit überwachen​

DB Transaktions-Queue-Gesundheitsmetriken​

🔥 Von LiteLLM gepflegte Grafana Dashboards ​

Veraltete Metriken​

Authentifizierung am /metrics Endpunkt hinzufügen​

FAQ​

Was sind _created vs. _total Metriken?​