BLUF — ein Canary ohne geeigneten Traffic hat nicht bestanden. Trennen Sie fehlende Nachweise, Messfehler und nachgewiesene Regressionen. Erhöhen Sie den Traffic erst, wenn eine release-spezifische Beobachtung vergleichbarer Workloads eine festgelegte Richtlinie erfüllt. Definieren Sie in Argo Rollouts sowohl Erfolgs- als auch Fehlerbedingungen: Eine falsche Erfolgsbedingung allein kann sonst zum Fehler statt zum gewünschten unklaren Ergebnis führen.
Die praktische Entscheidung lautet, ob ein neuer KI-Dienst mehr Traffic erhalten darf — nicht, ob ein leeres Dashboard ruhig aussieht. Die folgende Umsetzung kombiniert getestete Prometheus-Regeln mit dem tatsächlichen Argo-Prometheus-Provider und dessen Ausdrucksauswertung. Es handelt sich um einen lokalen synthetischen Test, nicht um einen produktiven Rollout, einen Kubernetes-Integrationstest oder einen Nachweis der Modellqualität.
Wo diese Freigabeprüfung hingehört
Ein unveränderbares LLM-Release-Bundle identifiziert Kandidat und Rückfallversion. Segmentierte Offline-Release-Gates prüfen die Antwortqualität vor dem Einsatz. Dieser Beitrag ergänzt eine andere Kontrolle: Welche Schlussfolgerung darf der laufende Rollout-Controller ziehen, wenn Betriebsnachweise fehlen, ungültig oder zu knapp sind?
Die Argo-Dokumentation zur Analyse unterscheidet erfolgreiche, fehlgeschlagene und unklare Analysen. Eine Inline-Analyse blockiert den Rollout während ihrer Ausführung; ein unklares Ergebnis kann die Fortsetzung bis zu einem Eingriff pausieren. Verwenden Sie für diesen Entwurf eine ausdrückliche Inline-Freigabegrenze. Eine Hintergrundanalyse, die beim Abschluss des Rollouts lediglich beendet wird, ist kein gleichwertiger verpflichtender Nachweis.
Beginnen Sie mit einem Dienst und einer definierten Anfrageklasse. Trennen Sie kurze interaktive Anfragen von langen Kontexten, Streaming von Nicht-Streaming und wesentlich unterschiedliche Routen. Prüfen Sie jede erforderliche Klasse. Canary und Kontrollversion benötigen unterschiedliche unveränderbare Release-Selektoren, aber dieselbe Eignungsdefinition, dasselbe Beobachtungsfenster und dieselben Ergebnisgruppen. Eine fehlende geschützte Klasse bleibt fehlend; eine andere, stark genutzte Klasse darf ihren Nenner nicht ersetzen.
Trennen Sie Nachweiserzeugung und Freigabebefugnis
An der Anfragegrenze entstehen begrenzte Labels für Dienst, Release, Klasse und Endergebnis. Prometheus leitet Nenner und Zustandsvergleiche ab. Ein Eignungsfilter entfernt Ergebnisse ohne ausreichendes Volumen, Beobachtungsalter oder Aktualität. Die resultierende Gate-Zeitreihe enthält 1 für eine erfüllte Richtlinie, 0 für deren Verletzung oder keinen Messwert bei unzureichender Evidenz. Argo interpretiert diesen Vertrag; die verantwortliche Person bewahrt Erklärung und mögliche Ausnahmeentscheidung auf.
Geben Sie dieser Auswertung keine Zugangsdaten für fachliche Aktionen. Sie benötigt lesenden Metrikzugriff und eine eng begrenzte Anbindung an die Release-Steuerung, nicht die Befugnis, Bestellungen auszulösen oder Anlagensteuerungen zu ändern. Ein Traffic-Rollback stellt die Weiterleitung zur vorherigen Version wieder her. Bereits versandte E-Mails, Zahlungen oder physische Aktionen einer Canary-Anfrage macht er nicht rückgängig.
Legen Sie den Messvertrag vor den Schwellenwerten fest
Im Lehrbeispiel zählt ai_requests_total abgeschlossene Anfragen mit vorinitialisierten Ergebnissen ok und error. Die Selektoren lauten service="inference", class="short" sowie release="candidate-a" beziehungsweise "baseline-a". Fehler zählen als Ergebnisse, nicht als fehlende Anfragen. Legen Sie vor dem Einsatz im Gateway fest, wie Client-Abbrüche, Zeitüberschreitungen und Wiederholungen in den Nenner eingehen. Ein Abschlusszähler allein zeigt keinen wachsenden Bestand unerledigter Anfragen; ergänzen Sie Kontrollen für Annahme, Alter offener Arbeit und Zeitüberschreitungen.
N(r) bezeichnet sum(increase(ai_requests_total{service="inference",class="short",release="r"}[5m])). E(r) verwendet dieselbe Zunahme, beschränkt auf outcome="error", geteilt durch N(r). Diese Schreibweise beschreibt die Ersetzung des Release-Labels in einer Vorlage, keine PromQL-Funktionsdefinition. Durch Vorinitialisierung beider Ergebnisse wird eine fehlende Fehlerzeitreihe nicht mit einer gemessenen Null verwechselt. Verbergen Sie einen ausgefallenen Exporter nicht durch einen pauschalen Null-Ersatzwert.
Das Beispiel lässt den Vergleich nur zu, wenn beide N-Werte mindestens 100 erreichen, die jeweils neuesten Messwerte aller aktuell ausgewählten Anfragezähler weniger als 30 Sekunden alt sind und beide Beobachtungsstart-Gauges mindestens 300 Sekunden Beobachtung anzeigen. Das sind ausdrücklich betriebliche Regeln, keine statistischen Konfidenzgarantien. Prometheus increase extrapoliert Zähleränderungen; das Ergebnis ist eine Schätzung und kann Nachkommastellen enthalten, kein exaktes Ereignisjournal.
Die eigene Metrik ai_observation_start_seconds hält fest, wann die Beobachtung für Release und Klasse begann. Die Instrumentierung muss sie verantworten und bei unterbrochener Kontinuität zurücksetzen. Ein beliebiger Deployment-Zeitpunkt darf nicht als Nachweis durchgängiger Telemetrie dienen. Der Test setzt diese Gauge synthetisch. Gleichen Sie produktiv erwartete Instanzen, Scrape-Zustand und fehlende Intervalle separat ab: Die Aktualitätsprüfung vorhandener Zeitreihen erkennt keine Instanz, deren Zeitreihen vollständig verschwunden sind.
Ein getesteter PromQL-Vertrag ohne grünen Ersatzwert
Bilden Sie den Zustandswert H als Produkt dreier boolescher Vergleiche: (E(candidate) <= bool 0.02), (E(baseline) <= bool 0.02) und (E(candidate) - E(baseline) <= bool 0.005). Nur wenn beide absoluten Fehlerbudgets und das relative Regressionsbudget eingehalten werden, ergibt sich 1. Eine beeinträchtigte Kontrollversion kann einen ebenso beeinträchtigten Kandidaten nicht akzeptabel erscheinen lassen. Die absolute Zwei-Prozent-Grenze und der relative Spielraum von einem halben Prozentpunkt sind Lehrwerte; leiten Sie echte Budgets aus Ihrem Dienstvertrag ab.
Bilden Sie die Eignung G mit filternden Vergleichen ohne bool: N(candidate) >= 100 and N(baseline) >= 100 sowie Aktualitäts- und Beobachtungsalter-Prüfungen für beide Releases. Zeichnen Sie anschließend H and G als ai:canary_gate mit expliziten Labels release="candidate-a" und class="short" auf. In PromQL ist and eine Mengenüberschneidung: H bleibt nur erhalten, wenn G ein passendes Element enthält. Der Zahlenwert von G wird dabei nicht als boolescher Wert verrechnet. Die synthetischen Ausdrücke aggregieren vor dem Hinzufügen der Regel-Labels auf ein Element ohne Labels; die Zuordnung ist deshalb bewusst festgelegt.
Für jedes Release lautet die Aktualitätsprüfung time() - min(timestamp(ai_requests_total{service="inference",class="short",release="candidate-a"})) < 30; für die Kontrollversion ersetzen Sie den Release-Selektor. Das Beobachtungsalter prüfen Sie mit time() - max(ai_observation_start_seconds{service="inference",class="short",release="candidate-a"}) >= 300. Summieren Sie nicht mehrere Releases vor der Nennerberechnung und vergleichen Sie nach der Aggregation keine unterschiedlichen Klassenmischungen.
Erzeugen Sie die Regel aus dem Release-Manifest für genau Kandidat, Kontrollversion und Klasse. Überschreiben Sie keine globale Regel, die mehrere gleichzeitige Rollouts gemeinsam nutzen. Das Beispiel wertet alle 15 Sekunden aus. Argo fragt die ausgewählte ai:canary_gate-Zeitreihe mit einem zusätzlichen Filter time() - timestamp(ai:canary_gate{dieselben Selektoren}) < 30 ab. Diese zweite Grenze erfasst ein aufgezeichnetes Regelergebnis, das nicht mehr aktualisiert wird, obwohl seine zugrunde liegenden Zählerprüfungen zuvor bestanden hatten.
Machen Sie „unklar“ zu einem ausdrücklichen Argo-Ergebnis
Das ausgeführte AnalysisTemplate verwendet apiVersion argoproj.io/v1alpha1, kind AnalysisTemplate und eine Metrik namens eligible-health. Die Argumente heißen prometheus-address, canary-release und workload-class. Die Instant-Abfrage wählt die Gate-Zeitreihe anhand dieser Release- und Klassenargumente aus und prüft die Aktualität des Regelergebnisses. Übernehmen Sie keinen synthetischen Testhost in ein Deployment; setzen Sie einen geprüften Prometheus-Endpunkt und minimal berechtigte Authentifizierung ein.
| Vorlagenfeld | Getesteter Wert | Grund für die ausdrückliche Festlegung |
|---|---|---|
| count | 1 | Eine Inline-Entscheidung nach dem Beobachtungsfenster |
| failureLimit | 0 | Eine gemessene Regelverletzung wird nicht ignoriert |
| inconclusiveLimit | 0 | Unzureichende Evidenz verlangt einen Eingriff |
| consecutiveErrorLimit | 0 | Ein Provider-Fehler ist keine gesunde Messung |
| provider.prometheus.timeout | 10 | Abfrageversuch in Sekunden begrenzen |
| successCondition | len(result) == 1 && !isNaN(result[0]) && !isInf(result[0]) && result[0] == 1 | Genau einen endlichen Bestehenswert verlangen |
| failureCondition | len(result) == 1 && !isNaN(result[0]) && !isInf(result[0]) && result[0] == 0 | Nur beim vereinbarten Verletzungswert fehlschlagen |
Die kurzschließende Längenprüfung verhindert den Indexzugriff auf einen leeren Vektor. Bei leeren, nicht endlichen oder unerwartet mehrfachen Ergebnissen sind beide Bedingungen falsch; der versionsgebundene Auswerter klassifiziert dies als Inconclusive. Mit successCondition allein wertet er eine falsche Erfolgsbedingung dagegen als Fehler. Das ist dokumentiertes Verhalten, kein kosmetisches Etikett: Verantwortliche sollen fehlende Nachweise reparieren und keine gemessene Regression behaupten.
Platzieren Sie die Inline-Analyse nach einem definierten Traffic- und Beobachtungsschritt. Verwenden Sie für eine Inline-Analyse keinen count-Wert von null. Bleibt der Traffic unter der Mindestmenge, pausieren Sie den Rollout, verlängern die Beobachtung innerhalb einer vorab festgelegten Höchstdauer oder beenden die Exposition zur Untersuchung. Wiederholte Neustarts bis zu einem zufälligen Bestehen sind keine Nachweisrichtlinie. Die Grenzwerte der Vorlage wurden lokal in den versionsgebundenen Argo-Typ eingelesen; ihr vollständiger Rollout-Lebenszyklus muss weiterhin im Staging-Cluster erprobt werden.
Was die lokalen Tests tatsächlich ergaben
Der Test verwendete Go 1.24.6, Argo Rollouts v1.8.3 und promtool 3.5.0. Dies sind Reproduktionsversionen, keine Behauptung über die neuesten oder bevorzugten Produktionsversionen. Der versionsgebundene Argo-Provider und die Bedingungsauswertung wurden ausgeführt, nicht in einem ähnlich aussehenden Richtlinienskript nachgebaut.
Promtool prüfte die Aufzeichnungsregel und bestand zehn synthetische Zeitreihenfälle: gesund, wenig Traffic, kein Traffic, Canary-Verletzung, beeinträchtigte Kontrollversion, zu kurze Beobachtung, falsche Klasse, fehlender Zähler, veralteter Zähler und eine Workload-Verschiebung mit viel Traffic der langen Klasse, aber zu wenigen kurzen Anfragen. Anschließend verarbeitete der Argo-Provider kontrollierte Loopback-HTTP-Antworten in vierzehn Fällen, einschließlich Instant- und Range-Ergebnissen sowie HTTP 503. Das sind zwei ergänzende Testebenen. Ein echter Prometheus-Server, Kubernetes-Controller, Service Mesh oder Sprachmodell war nicht beteiligt.
| Beobachteter Testfall | Abfrage- oder Provider-Ergebnis | Bedeutung für die Freigabe |
|---|---|---|
| Geeigneter gesunder Vergleich | Gate 1; Successful | Nur für diese Betriebsprüfung freigabefähig |
| Geeigneter Canary verletzt Vorgabe | Gate 0; Failed | Fortsetzung stoppen und untersuchen oder abbrechen |
| Kontrollversion beeinträchtigt | Gate 0 | Absolute Grenze verhindert irreführenden relativen Erfolg |
| Wenig oder kein Traffic; falsche Klasse | Leeres Abfrageergebnis | Unklar statt gesund |
| Fehlender oder veralteter Zähler; kurze Beobachtung | Leeres Abfrageergebnis | Nachweise vor der Entscheidung wiederherstellen |
| NaN; beide Unendlichkeiten; zwei Instant-Werte | Inconclusive | Ungültige oder mehrdeutige Messung zurückweisen |
| Metrik-Backend liefert HTTP 503 | Error | Provider-Zugriff reparieren; Ergebnis nicht erfinden |
| Sechs Range-Werte mit späterer Null | Failed | Nur der erste Wert hätte die Verletzung verdeckt |
| Fünf Range-Werte; NaN; leerer Range | Inconclusive | Abdeckung oder Gültigkeit reicht nicht aus |
Bewahren Sie Vorlage, Regeln, Eingabezeitreihen, go.mod/go.sum, Werkzeugversionen und beobachtete Ausgabe gemeinsam auf. Reproduzieren Sie die Abfrageebene mit promtool check rules rules.yaml und promtool test rules rules-test.yaml. Für die Provider-Ebene dient go run . im aufbewahrten Testprojekt. Der Provider-Test liest die tatsächliche Vorlage und prüft die erwarteten Phasen. Die HTTP-Antworten sind ausdrücklich synthetische Testeingaben, keine aufgezeichnete Produktionstelemetrie.
Range-Abfragen benötigen mehr als result[0]
Die Argo-Prometheus-Dokumentation empfiehlt, bei einer Range-Abfrage sämtliche zurückgegebenen Werte auszuwerten. Der lokale Range-Test verlangt sechs endliche Werte aus dem vereinbarten Wertebereich 0/1. Für Erfolg müssen alle sechs 1 sein; jede 0 führt nach bestandener Gültigkeitsprüfung zum Fehler. Eine spätere Null wurde korrekt als Failed klassifiziert. Ein leerer Range darf nicht allein deshalb bestehen, weil ein all-Prädikat kein Gegenbeispiel findet.
Eine subtilere Grenze bleibt bestehen: Der versionsgebundene Provider führt die Matrix-Messwerte vor der Bedingungsauswertung zu einer flachen Liste zusammen. Eine Länge von sechs beweist weder eine einzige beabsichtigte Zeitreihe noch sechs korrekte Zeitstempel oder vollständige Klassenabdeckung. Prüfen Sie Labels, Zeitraster, erwartete Zeitreihenpopulation und Warnungen der Rohantwort, bevor Sie eine produktive Range-Freigabe darauf stützen. Zwei unvollständige Zeitreihen könnten sonst wie ein vollständiges Fenster wirken. Die veröffentlichte Instant-Vorlage erhebt diesen Range-Abdeckungsanspruch nicht; die separaten Range-Tests belegen nur die Werteauswertung.
Ergänzen Sie Latenz, ohne ein Perzentil zu erfinden
Das SLO-Konzept für Inferenz definiert die nutzerbezogene Latenzgrenze. Bei einem klassischen Histogramm aggregieren Sie Bucket-Raten über Replikate, erhalten le sowie die erforderlichen Release- und Klassendimensionen und berechnen erst dann histogram_quantile. Mitteln Sie niemals p95-Werte einzelner Instanzen. Die Prometheus-Hinweise zu Histogrammen erklären, warum vorab berechnete Summary-Quantile nicht zu einem Dienstperzentil aggregierbar sind.
Bei einem festen Latenzbudget kann der Anteil der Beobachtungen innerhalb eines passenden Buckets leichter prüfbar sein als ein interpoliertes Perzentil. Verifizieren Sie, dass jede relevante Instanz den Bucket bereitstellt und Zähler wie Nenner dieselbe geeignete Population beschreiben. Ein leeres Histogramm bleibt fehlende Evidenz. Eine schnelle Antwort ist nicht zwangsläufig korrekt; eine niedrige Fehlerrate validiert weder Werkzeugaktionen noch fachliche Qualität.
Bevor diese Prüfung Releases freigeben darf
1. Fixieren Sie Kandidat, Kontrollversion, Anfrageklassen, Zähler, Endergebnisse und Rückfallversion. Verlangen Sie jede geschützte Klasse statt eines bequemen Gesamtwerts.
2. Testen Sie fehlenden Traffic, falsche Selektoren, fehlende Instanzen, veraltete Zeitreihen, Backend-Fehler, Zähler-Resets und veränderte Workload-Mischungen. Prüfen Sie Rohnenner, Abfragewarnungen und das Alter unerledigter Anfragen zusätzlich zum Gate-Wert.
3. Legen Sie Mindestmenge, Dauer, Aktualität sowie absolute und relative Budgets vor der Exposition fest. Dokumentieren Sie maximale Wartezeit, Ausnahmebefugnis und erforderliche Nachweise zur Fortsetzung eines unklaren Laufs.
4. Erproben Sie tatsächlichen Controller, Routing-Schicht und installierte CRDs im Staging. Prüfen Sie Failed, Error und Inconclusive; weisen Sie nach, dass der nächste Traffic-Schritt die Inline-Grenze nicht umgehen kann.
5. Bewahren Sie Release-Manifest, aufgelöste Abfrage, Zeitfenster, Selektoren, Nennernachweise und Entscheidung auf. Begrenzen Sie Label-Kardinalität und Aufbewahrung; rohe Prompts oder Nutzeridentitäten gehören nicht in Metrik-Labels.
Bringen Sie für eine Canary-Gate-Prüfung ein Release-Manifest, die aktuelle Freigabevorlage und die PromQL-Abfrage hinter deren grünem Status mit. Das sinnvolle Ergebnis ist ein getesteter Vertrag für Bestehen, Fehlschlagen und Unklarheit mit verantwortetem Wiederanlauf — kein weiteres Dashboard, das fehlende Arbeit stillschweigend als Erfolg behandelt.
