Quota events monitoring — a 429 nem hiba, hanem szignál

A provider rate-limit eseményt (HTTP 429, Anthropic overloaded_error, Gemini RESOURCE_EXHAUSTED) régen hibaként kezeltük: log, retry, fallback chain, és ennyi. Az on-call paging-be is bekerült, ha tartós volt. Hat hónap után rájöttünk: a 429 nem hiba, hanem a piaci kapacitás-helyzet jelzője. Ezt szignállá tenni — chartolható, alertálható, és tendencia-elemezhető — az egyik legalulértékeltebb engine-feature.

A eng_quota_events tábla

CREATE TABLE eng_quota_events (
  id BIGSERIAL PRIMARY KEY,
  occurred_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  tenant_id TEXT,
  provider TEXT NOT NULL,
  model_id TEXT NOT NULL,
  event_type TEXT NOT NULL
    CHECK (event_type IN ('rate_limit_429','overloaded_503',
                          'quota_exhausted','capacity_warning')),
  retry_after_seconds INTEGER,
  fallback_succeeded BOOLEAN,
  fallback_provider TEXT,
  request_category TEXT,
  span_id TEXT,
  raw_response_excerpt TEXT
);
CREATE INDEX ON eng_quota_events (provider, model_id, occurred_at DESC);
CREATE INDEX ON eng_quota_events (tenant_id, occurred_at DESC);

Minden 429 / 503 / quota-exhausted válasz egy sort generál ide. A fallback_succeeded mező azt mondja, hogy a router fallback-chain-je sikeresen elnyelte-e az incidenst (a felhasználó számára láthatatlan lett-e). A request_category a cost-by-category mező itt is ott van — összerendelheted a quota-eseményt azzal a feature-rel, ami kiváltotta.

A real-time graf

A /cockpit/quota-events route két panelt tartalmaz. Az első egy provider × event_type heatmap (utolsó 24 óra, 15-perces buckets). A második egy timeseries, ami a top-3 érintett (provider, model) pár óránkénti event-darabszámát mutatja. Vertikális annotation: a deploy markerek (új modellel váltás), és a slo.degraded események.

A chart automatikusan újratölt 30 másodpercenként SSE-n keresztül (lásd: useAdminEventsStream hook). Egy on-call mérnök egy másik tabban nyitva tarthatja és ránézhet két percenként.

A 429 mint szignál — mire használjuk

1. Kapacitás-tervezés. Ha egy provider rendszeresen 429-ezik egy nagy tenanten, a megoldás nem a retry, hanem a dedikált throughput-csomag rendelése (OpenAI Enterprise, Anthropic Workspaces). A grafikon mutatja, mikor érdemes ebbe a beszélgetésbe belekezdeni.
2. Provider-mix kalibrálás. Ha az Azure OpenAI gpt-4o-ja stabilan 429-ezik, és az OpenAI direct ugyanezt nem, a kérés-mixet átcsoportosítjuk. Egy hét alatt megfordul a 429-arány.
3. Tenant-szintű soft throttling. Ha egyetlen tenant fogyasztja a kvóta 80%-át, a többi tenant lassul. A RouterPolicyService ilyenkor egy tenant-szintű priority queue-t aktivál, ahol a heavy-user tenant kérései a fallback providerre kerülnek elsőként.
4. Provider capacity warning. Néhány provider (Anthropic különösen) küld X-Capacity-Warning headert mielőtt a 429 jönne. Ezt is rögzítjük (capacity_warning event_type), és preemptive route-átállítás történik, mielőtt a felhasználó látna bármi rosszat.

Az alerting bekötés

Nem minden 429 alert-érdemes. A küszöb: ha egy (provider, model) pár 5 percen belül 50+ eseményt generál, ÉS a fallback_succeeded=false arány meghaladja a 10%-ot, Slack-üzenet a #engine-ops csatornán. A fallback_succeeded=true arány nem ad alarmot, mert a felhasználó számára nincs hatás — a router elnyelte. Ezzel a finomítással hetente átlag 2-3 valódi riasztás van, nem napi 20.

Egy konkrét naptári eset

2026 május 28., csütörtök reggel. Az OpenAI gpt-4o p95 latenciája hirtelen 800ms-ről 2400ms-re ugrott, miközben 429-ek is jöttek. A eng_quota_events chartja mutatta: az incidens 06:14-kor kezdődött, kizárólag az eu-west-3 régióban. Az Azure OpenAI-t használó tenantokat ez nem érintette. A router automatikus átállítása az Anthropic Claude 3.5 Sonnet-re tíz perc alatt befejeződött (fallback_succeeded=true arány 94%). A felhasználói panaszok száma ezen az incidens alatt: 0. A status.openai.com csak 09:00-kor jelentett incidenst. Ekkor már a router 2 órája kezelte. Ez a fajta resilience nem lehetséges, ha a 429-eket hibaként kezeli a rendszer.