Signal auswählen
Beginnen Sie eine Fehleruntersuchung mit Issues oder Logs. Untersuchen Sie
eine einzelne Ausführung mit einem verfügbaren Trace. Untersuchen Sie den
größeren Zeitraum mit einem Metrik-Verlauf. Für Aktivität und Nutzerbindung
lesen Sie Produktanalysen.
Erfassen Sie nur die Felder, die eine Untersuchung braucht. Verwenden Sie
stabile Namen für Dienste, Operationen und Metriken. Senden Sie keine
Zugangsdaten, Zahlungsdaten oder rohen Anfrage-Bodys. Der Leitfaden
Erfasste Daten steuern beschreibt die
Einstellungen dafür.
Logs
Ein Log ist ein Eintrag der Anwendung zu einem bestimmten Zeitpunkt. Ein nützliches Log hat:- Den Quellzeitpunkt des Ereignisses.
- Einen kanonischen Schweregrad.
- Projekt und Dienst als Bereich.
- Umgebung und Release.
- Trace- und Span-IDs, wenn das Log einen aktiven Trace-Kontext hat.
- Kleine, benannte Attribute mit Kontext zum Ereignis.
occurred_at, severity,
project_id, service_name, environment, release, trace_id, span_id
und attributes. Legen Sie Kontext in benannte Attribute, nicht in den
Nachrichtentext.
Logs mehrerer Dienste in einer Ansicht stehen nicht in einer Trace-Beziehung.
Nur Trace-Kontext stellt diese Beziehung her.
Traces
Ein Trace enthält die Spans einer Anfrage oder Operation. Ein Root-Span hat keinen übergeordneten Span. Ein Child-Span kennzeichnet seinen übergeordneten Span. Alle Spans eines Trace haben dieselbe Trace-ID und unterschiedliche Span-IDs. Siehe Verteiltes Tracing. Ein Log, Issue, eine Aktion oder eine Metrik ohne aktiven Trace-Kontext erhält einen Erfassungs-Trace. Dieser Trace enthält nur Erfassungs-Spans. Er zeigt keinen Anfragepfad. Siehe Erfassungs-Spans.Metriken
Eine Metrik zeichnet einen Messwert über die Zeit auf. Lesen Sie jede Metrik mit Name, Einheit, Dimensionen, Projekt, Zeitraum und Intervall. LogBrew wählt denvalue jedes Punkts anhand von kind und temporality der Metrik:
Ein Beispiel: Drei Delta-Counter-Messwerte mit den Werten
2, 3 und 5 in
einem Intervall ergeben einen value von 10 und einen sample_count von
3. Drei Gauge-Messwerte mit denselben Werten in dieser Reihenfolge ergeben
einen value von 5. Ein p95-Wert ist kein Durchschnitt. Etwa 95 % der
aufgezeichneten Beobachtungen liegen bei diesem Wert oder darunter.
Bei status: "ready" ist die abgeleitete Aggregation verfügbar. Bei
status: "limited" lesen Sie aggregation.limitation und verwenden nur die
rohen Werte. Summieren Sie weder einen Gauge noch einen kumulativen Stream.
Ein Intervall ohne Punkt ist kein gemessener Nullwert. Die Abfragefelder
finden Sie unter Abfragefilter der Telemetrie-API.
GET /api/telemetry/metrics/series liefert diese Punkte. Der Endpunkt
erfordert project_id, name und since. Jede Zeitreihe hat eine
identity mit kind, unit und temporality. Zeitreihen mit
unterschiedlicher Identität bleiben getrennt. Jeder Punkt kann außerdem
Folgendes enthalten:
coverage.truncated ist true, wenn series_limit Zeitreihen mit geringerem
Volumen ausgelassen hat. Um ein Zeitfenster einer Metrik mit dem vorherigen
Zeitfenster gleicher Länge zu vergleichen, führen Sie Folgendes aus:
Issues
Ein Issue gruppiert wiederholte Fehler über einen stabilen Fingerprint. Es hat einen Schweregrad, einen Status, eine Anzahl von Vorkommen sowie die Zeitpunkte „Zuerst gesehen“ und „Zuletzt gesehen“. Die Details eines Issues können Ausnahmeketten, Stackframes, vorherige Schritte, zugehörige Logs und eine Trace-Beziehung ergänzen.last_seen_at ist das neueste Vorkommen der Gruppe. Das Vorkommen, das Sie
auswählen, kann älter sein. Lesen Sie beide Zeitpunkte.
Der status eines Issues ist unresolved, resolved oder archived.
API-Antwortversion 1 zeigt archived als ignored. Die Antwortversionen 2
und 3 ergänzen priority (high, medium oder low) und
priority_source. Version 3 ergänzt außerdem assignee. Siehe
Statuswerte und
Priorität.
Aktionen
Eine Aktion zeichnet Produktaktivität auf. Eine unterstützte Klassifizierung kennzeichnet sie als Seitenaufruf, Bildschirmaufruf oder Interaktion. Ein Ereignisname allein legt die Klassifizierung nicht fest. Diesen Kontext ergänzen Sie wie unter Produktereignisse erfassen beschrieben. Sitzungen sind keine Nutzer. Anonyme Subjekte sind keine identifizierten Nutzer.Werte für den Schweregrad
LogBrew akzeptiert die Aliasse als Eingabe in beliebiger Groß- und
Kleinschreibung. API, CLI und Live-Ereignisse verwenden die kanonischen Werte.
Unbekannte Werte für den Schweregrad werden abgelehnt. Der Schweregrad ist die
aufgezeichnete Dringlichkeit. Er zeigt weder geschäftliche Auswirkungen noch
die Grundursache.
Eine Person kann den angezeigten Schweregrad eines Issues oder eines Logs
ändern. Die Antwort enthält dann ein Objekt
triage mit effective_severity.
Das Feld severity behält den erfassten Wert.
Live- und Snapshot-Lesezugriffe
logbrew read liefert einen Snapshot für das ausgewählte Projekt, den
Zeitraum und die Filter. Führen Sie den Befehl erneut aus, um neue Ereignisse
zu lesen. logbrew watch streamt neue Logs, Issues und Aktionen, solange die
Verbindung offen ist. Traces und Metriken streamt es nicht. Ein
Verbindungsfehler zeigt nicht, dass das Projekt leer ist.
Zustände von Belegen
Antworten halten diese Zustände getrennt: erfasst, nicht erfasst, geschwärzt, gekürzt und nicht verfügbar. Trace-Belege haben vier Zustände:available, not_linked, not_found und unavailable. Ihre Bedeutung
erklärt die Einführung, die
Abdeckungsfelder erklärt
Grenzen der Belege.
Ein neueres SDK fügt früher gesendeten Ereignissen keine Felder hinzu.
Ein Projekt untersuchen
1
Ungelöste Issues finden
2
Ein Issue lesen
Dieser Befehl liest den gespeicherten Verlauf des Issues. Der Filter
--since aus der Liste gilt hier nicht.3
Verfügbaren Trace öffnen
Verwenden Sie die Trace-ID nur, wenn das ausgewählte Vorkommen eine
liefert.
4
Zugehörige Belege lesen
Filtern Sie Logs, Aktionen und Metriken nach demselben Projekt, Dienst,
derselben Umgebung und demselben Release. Verknüpfen Sie Signale nicht
allein über die Zeit.