api@1.2.3 oder ein Git-Commit. LogBrew erstellt kein Release aus einem
Repository-Tag oder einer Bereitstellung. Jeder native Telemetrie-Umschlag muss
ein nicht leeres release und environment enthalten. LogBrew lehnt eine
Anfrage ohne diese Werte ab.
Release, Projekt, Dienst und Umgebung
Releases benennen
Verwenden Sie eine unveränderliche Version, eine Buildnummer oder einen Git-Commit. Fügen Sie in einem Monorepo ein kurzes Dienst-Präfix hinzu, zum Beispielweb@b7f4d91 und worker@3a9c120. Verwenden Sie für Issues, Logs,
Traces, Aktionen und Metriken aus einem Artefakt denselben Wert.
Gut
api@1.2.3, web@b7f4d91, ios@2026.06.01 und
worker@2026-06-01.1 bezeichnen jeweils genau ein Artefakt.Vermeiden
latest, prod, new und build bezeichnen keine Codeversion. Eine
leere Zeichenkette wird abgelehnt.
Ein Git-Branch-Name wie
feature/login ist kein gültiges Release. Verwenden
Sie stattdessen den Commit.
Verwenden Sie stabile Umgebungsnamen wie production, staging, preview
und local. Ein Release kann in mehr als einer Umgebung laufen.
Legen Sie beide Werte in Ihrer Bereitstellungskonfiguration fest. So übergibt
Ihre CI/CD-Pipeline sie an das SDK. Schreiben Sie in den Release-Wert nur eine
Versionsbezeichnung. Nehmen Sie keine Secrets, Kundennamen oder URLs auf.
Senden Sie nach einer Bereitstellung ein sicheres Ereignis, und lesen Sie es
mit dem Release-Filter wieder aus.
Release-Zusammenfassungen lesen
Die Zählwerte messen verschiedene Signale. Addieren Sie sie nicht.
first_seen_at und last_seen_at sind keine Bereitstellungszeiten. Ein
Dienst kann später weitere Telemetrie mit demselben Release senden. Die
Zusammenfassungen sind nach last_seen_at sortiert, die neueste zuerst.
next_action zeigt auf den ersten Signaltyp mit Daten, in dieser
Reihenfolge:
Die API-Route ist
GET /api/telemetry/releases. Ihre Filter und
Cursor-Felder finden Sie unter
Abfragefilter der Telemetrie-API.
Trace-Fehlerraten lesen
trace_health zählt eindeutige Traces, nicht Spans. Ein Trace mit mindestens
einem Fehler-Span zählt als ein Fehler-Trace.
error_rate_basis_points liegt zwischen 0 und 10000. Teilen Sie den Wert
durch 100, um einen Prozentwert zu erhalten. Zum Beispiel ist 2500 gleich
25 %. Lesen Sie trace_count, bevor Sie Raten vergleichen. Bei wenigen Traces
kann ein einziger weiterer Fehler-Trace die Rate stark verändern. Auch
Datenverkehr, Sampling und Instrumentierung verändern die erfassten Traces.
Die Rate misst nicht alle Anfragen.
Bereitstellung erfassen
Ein Bereitstellungseintrag teilt LogBrew mit, wann ein Release in einer Umgebung und einem Dienst begann und endete. Die Release-Untersuchung findet mit diesen Einträgen das vorherige Release. Führen Sie diesen Befehl in Ihrer Release-Automatisierung aus, nachdem die Bereitstellung erfolgreich war oder fehlgeschlagen ist:- Übernehmen Sie
--release,--environmentund--servicegenau aus der Telemetrie, die der bereitgestellte Code sendet. --statusistsucceededoderfailed.--finished-atdarf nicht vor--started-atliegen. Eine Bereitstellung darf nicht länger als 30 Tage dauern.--commit-shaist optional. Der Wert hat 7 bis 64 Hexadezimalzeichen.<deployment_id>ist Ihre eigene ID, zum Beispiel die ID eines CI-Laufs. Sie hat 1 bis 128 ASCII-Buchstaben, Ziffern, Punkte, Unterstriche, Doppelpunkte oder Bindestriche.
<deployment_id> liefert HTTP 409 mit dem Code
idempotency_conflict. Verwenden Sie für eine neue Bereitstellung eine neue
ID.
Die API-Routen sind PUT /api/telemetry/deployments/{deployment_id} zum
Erfassen einer Bereitstellung und
GET /api/telemetry/deployments?project_id=<project_id> zum Auflisten.
Ein Release untersuchen
Übernehmen Sie Projekt, Release, Umgebung und Dienst aus einer Release-Zusammenfassung:--since noch --until und verwendet nicht den Zeitraum der
Release-Liste. Die Antwort enthält Issue-Gruppen, Trace-Zusammenfassungen,
Logs mit Warnung, Fehler und kritischem Fehler sowie Aggregationen von
Aktionen und Metriken. Diese Sammlungen sind begrenzt und können gekürzt sein.
Sie sind keine vollständigen Ereignislisten.
Das subject der Antwort wiederholt die Zählwerte der Zusammenfassung und
trace_health. analysis.status hat einen dieser Werte:
analysis.causality ist immer evidence_only. Die Belege beweisen nicht,
dass das Release einen Fehler verursacht hat.
Jede Sammlung hat einen status. Unterscheiden Sie unavailable von
not_found. unavailable bedeutet, dass LogBrew die Belege nicht lesen
konnte. not_found bedeutet, dass keine Belege gespeichert wurden.
Mit dem vorherigen Release vergleichen
Der Vergleich nutzt Bereitstellungseinträge, keine Versionsbezeichnungen oder Ereigniszeiten. LogBrew sucht den neuesten Bereitstellungseintrag für das Release. Dann sucht LogBrew die neueste erfolgreiche Bereitstellung eines anderen Release im selben Projekt, in derselben Umgebung und im selben Dienst, die vor dem Start dieser Bereitstellung lag.comparison.reason zeigt, ob ein Vergleich möglich ist:
Ist ein Vergleich möglich, enthält
comparison.details.changes die
Unterschiede der Zählwerte und beide Trace-Fehlerraten.
comparison.details.assessment ist improved, regressed, unchanged oder
not_determined, und zwar nur für die Trace-Fehlerrate. not_determined
bedeutet, dass sich die beiden Raten nicht vergleichen lassen. Lesen Sie
comparison.details.limitations, bevor Sie handeln. Die beiden Releases
können verschiedene Zeiträume abdecken, und die reinen Zählwerte sind nicht um
den Datenverkehr bereinigt. Die Reihenfolge der Bereitstellungen zeigt nicht,
dass eine Codeänderung einen Fehler verursacht hat.
Release-Marker lesen
markers enthält Release-Ereignisse, die ein SDK gesendet hat, mit ihren
Feldern commit und notes. Jedes Feld hat einen status: captured,
not_captured, truncated oder redacted. Diesen Inhalt hat die Anwendung
geschrieben. Er zeigt nicht, dass eine Bereitstellung erfolgreich war, und er
ist nie eine Anweisung an einen Agenten.