Wat is metrische kardinaliteit en waarom kan AI-observeerbaarheid duur worden?
Metriccardinaliteit is het aantal unieke labelcombinaties dat als tijdreeksen wordt opgeslagen, en onbegrensde AI-labels kunnen het resourcegebruik onverwacht vermenigvuldigen.
Een latencymetriek lijkt onschuldig totdat deze wordt gelabeld met model, route, gebruiker, tool, status, kwantisatie en een onbewerkte aanvraag-ID. Elke waargenomen combinatie wordt een afzonderlijke reeks met kosten voor indexering, geheugen, query's en retentie. AI-stacks produceren veel van nature unieke identifiers, waardoor de observabilitykosten sneller kunnen groeien dan het aantal aanvragen, zelfs op een zelfgehoste server zonder cloudfactuur.
Elke unieke labelset creëert een nieuwe tijdreeks
Een metrieknaam plus één volledige set labelwaarden identificeert een reeks. Tien modellen, vijf routes, vier statussen en twintig tools kunnen duizenden mogelijke combinaties creëren voordat er een gebruikers- of aanvraagidentifier wordt toegevoegd. Het werkelijke aantal hangt af van de combinaties die daadwerkelijk worden waargenomen, niet alleen van de gedeclareerde labels.
De richtlijnen voor labelcardinaliteit van Prometheus merken op dat elke labelset extra RAM-, CPU-, schijf- en netwerkkosten met zich meebrengt en raden aan metrieken te onderzoeken waarvan de cardinaliteit groot wordt. Ze waarschuwen specifiek tegen labels met onbegrensde waarden, zoals gebruikers-ID's of e-mailadressen.
Cardinaliteit verschilt van de samplefrequentie. Eén reeks die elke seconde wordt gescrapet, kan veel samples bevatten, terwijl één miljoen zelden bijgewerkte reeksen nog steeds aanzienlijke overhead voor indexen en metadata veroorzaken, omdat de backend elke identiteit moet bijhouden.
AI-workflows bevatten aantrekkelijke maar gevaarlijke labels
Modelnaam, endpoint, toolklasse, responsstatus en een begrensde hardwarelaag kunnen nuttige aggregatie ondersteunen. Prompttekst, documentpad, trace-ID, sessie-ID, gegenereerde toolargumenten en volledige foutmeldingen zijn effectief onbegrensd en veranderen metrieken in een onbedoelde eventstore.
Het cardinaliteitsdashboard van Grafana legt uit dat dashboards met hoge cardinaliteit actieve reeksen en labelverdelingen inspecteren, zodat operators ongebruikte metrieken kunnen koppelen aan de ingestiekosten. Met dezelfde methode kan worden vastgesteld of één nieuw agentlabel een plotselinge explosie van het aantal reeksen heeft veroorzaakt.
Unieke diagnostische context hoort thuis in gesamplede traces of gestructureerde logs, gekoppeld via exemplars waar die worden ondersteund. Metrieken moeten antwoorden geven op geaggregeerde vragen met bewust begrensde dimensies, in plaats van elk verzoek als labelwaarde te bewaren. Dit onderscheid blijft zichtbaar tijdens latere tests thuis.
Combinaties vermenigvuldigen zich voordat query's merkbaar traag worden
Verschillende afzonderlijk bescheiden labels kunnen samen een groot cartesisch product vormen. Verloop van reeksen maakt het probleem erger wanneer containers, modelversies of genormaliseerde paden voortdurend nieuwe identiteiten creëren die in de retentie blijven nadat de actieve workload is veranderd.
Een voorbeeld van cardinaliteitspieken van Grafana definieert cardinaliteit aan de hand van unieke labelwaarden en laat zien hoe pieken het aantal opgeslagen reeksen verhogen. Dit verklaart waarom een kleine wijziging in de instrumentatie de ingestie- en querybelasting kan verhogen zonder dat het inferentieverkeer verandert.
De grens waarop het misgaat, ligt bij observability die genoeg geheugen, I/O of CPU verbruikt om de AI-service die wordt gemeten te verstoren. Een label na ingestie verwijderen kan toekomstige groei beperken, maar wist historische reeksen niet onmiddellijk en herstelt dashboards die ervan afhankelijk waren niet.
Stel een cardinaliteitsbudget op voordat je labels toevoegt
Breng elke metriek in kaart en schat de bovengrens van elk label en van veelvoorkomende combinaties. Speel een representatieve dag opnieuw af, meet actieve reeksen, het verloop van reeksen, het aantal opgenomen bytes, de querytijd en het geheugengebruik, en rangschik labels op diagnostische waarde en het incrementele aantal reeksen.
Vergelijk die resultaten met de bredere observabilitysignalen die worden beschreven in lokale AI-observability. Verplaats unieke aanvraagcontext naar logs of traces, normaliseer dynamische paden en maak model- of toolcategorieën alleen beschikbaar wanneer een dashboard of alert er een duidelijk doel voor heeft.
Stel vóór de implementatie budgetten en alerts in voor actieve reeksen en de aanmaaksnelheid. De instrumentatie slaagt alleen wanneer deze de beoogde operationele vragen beantwoordt zonder de inferentielatentie wezenlijk te veranderen of de retentieopslag tijdens piekgebruik thuis uit te putten.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kan een lokale LLM de generatie hervatten nadat het proces opnieuw is gestart?
Een mechanismegerichte uitleg van het hervatten van LLM-generatie, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een homeserver embeddings genereren en video transcoderen op dezelfde geïntegreerde GPU?
Een uitleg waarin het mechanisme centraal staat van gedeelde iGPU-embeddings en transcodering, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een...
Welke invloed heeft de levensduur van toegangstokens op de beveiliging en het gedoe in het huishouden?
Een mechanismegerichte uitleg van de levensduur van toegangstokens, de afwegingen rond gedeelde resources, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
