Dokumentation

Fehler-Tracking

Erfassen Sie die Ausnahmen, die Ihre Anwendung wirft, gruppiert zu Issues — in jedem Tarif, auch im kostenlosen. Es spricht das Protokoll von Sentry, Sie behalten also das SDK, das Sie bereits haben, und ändern eine Zeile Konfiguration.

Einrichtung

Legen Sie im Dashboard ein Projekt an und kopieren Sie dessen DSN. Richten Sie dann Ihr vorhandenes SDK darauf:

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

Das ist die ganze Integration. Jedes Sentry-SDK funktioniert — JavaScript, Python, Ruby, Go, PHP, .NET — weil es deren Wire-Protokoll ist und nicht etwas Ähnliches.

Der Schlüssel in einer DSN ist kein Geheimnis. Ein Browser-SDK liefert ihn im Seiten-Bundle aus; er benennt also ein Projekt und autorisiert sonst nichts. Bauen Sie nichts, das ihn für privat hält.

Wie aus Fehlern Issues werden

Ereignisse, die dasselbe Problem sind, werden zu einem Issue gruppiert. Die Gruppierung nutzt den Ausnahmetyp, die Meldung und die Form des Stacks — niemals Zeilennummern, denn ein zusätzlicher Import am Dateianfang würde sonst ein Issue in zwei aufspalten und einen langjährigen Fehler neu aussehen lassen.

Ein Issue, das Sie geschlossen hatten und das dann erneut auftritt, wird als Regression wieder geöffnet und alarmiert Sie, statt einem geschlossenen Issue still ein weiteres Vorkommen hinzuzufügen.

Source Maps

Laden Sie die Maps für ein Release hoch, und ein minifizierter Browser-Stack wird lesbar. Laden Sie sie aus Ihrem Build über die API hoch — siehe die API-Referenz.

Maps werden zuerst über debug_id zugeordnet und danach über Release plus Dateiname. Angewendet werden sie, wenn Sie ein Issue lesen, nicht wenn das Ereignis ankommt — was eine nützliche Folge hat: eine nach den Fehlern hochgeladene Map wird trotzdem auf sie angewendet. Das ist meist die Reihenfolge, in der die Dinge passieren.

Fehler an einem Vorfall

Wenn die Überwachung einen Vorfall eröffnet, sammelt sie die Fehler, die Ihre Anwendung während der Bestätigung dieses Ausfalls geworfen hat, und hängt eine Zusammenfassung an den Vorfall selbst.

Es lohnt sich zu wissen, warum das nützlicher ist als nachträgliches Suchen: Das Zeitfenster hört auf zu existieren, sobald der Vorfall existiert, und die Ereignisse stehen auf einer Aufbewahrungsuhr, die lange vor dem Vorfall abläuft. Die Zusammenfassung wird deshalb in dem Moment erfasst, in dem das möglich ist, und danach beim Vorfall aufbewahrt.

In einem Agenturkonto ist die Zusammenfassung auf den Arbeitsbereich beschränkt, damit der Vorfall des einen Kunden nicht die Stacktraces eines anderen in eine E-Mail trägt.

Logs von Ihren Servern und Netzwerkgeräten

Ab Business nimmt ein Projekt auch die Logs entgegen, die Ihre Maschinen ohnehin schreiben: Syslog von Linux sowie von Cisco- und Juniper-Geräten, das Windows-Ereignisprotokoll und das macOS Unified Log. Richten Sie einen bereits vorhandenen Log-Versand auf den Log-Endpunkt Ihres Projekts, der auf der Projektseite neben der DSN steht. Auf den Maschinen selbst ist nichts zu installieren.

Gespeichert werden nur Fehler. Syslog-Stufen unterhalb von err, Windows-Stufen unterhalb von Error und alles, was das macOS-Log Defaultoder leiser nennt, wird verworfen, bevor es gezählt oder berechnet wird — ein gesunder Host kostet Sie also nichts, und Warnungen, für die niemand alarmiert würde, füllen Ihre Issue-Liste nicht.

Log-Einträge werden gruppiert wie Ausnahmen: nach dem Programm, das sie ausgegeben hat, und nach der Meldung, nicht nach dem Host. Ein fehlerhaftes Deployment auf zwanzig Webservern ist ein Issue, das zwanzigmal gesehen wurde, nicht zwanzig Issues. Wo Geräte ihre Meldungen selbst benennen, gruppieren wir nach diesem Namen — ein ausgefallener Port ist ein Issue, welcher Port es auch war.

Da sich eine Log-Zeile weit häufiger wiederholt als eine Ausnahme, behalten wir pro Stunde ein Beispiel je Issue und zählen den Rest. Die Anzahl der Vorkommen und das Diagramm sind exakt; was Sie nicht bekommen, ist eine eigene Kopie der hundertsten identischen Zeile.

Kontingente

Jeder Tarif hat ein monatliches Ereigniskontingent — 5.000 bei Free, 50.000 bei Starter, 250.000 bei Pro, 1.000.000 bei Business. Die Aufnahme ist zusätzlich pro Projekt ratenbegrenzt, was der Fall ist, der tatsächlich eintritt: Eine Ausnahme in einer Retry-Schleife kann sonst in Minuten ein Monatskontingent verbrennen.

Einzelne Ereignisse werden entsprechend der Fehler-Aufbewahrung Ihres Tarifs behalten — sieben Tage bei Free, dreißig bei Starter, sechzig bei Pro, neunzig bei Business. Die daraus gebauten Issues überdauern die Ereignisse: Ihre Zähler sowie das erste und letzte Auftreten bleiben so lange erhalten wie die Verlaufsaufbewahrung Ihres Tarifs.

Was wir nicht tun

Kein Session Replay, kein Performance-Tracing, kein Profiling. Das hier ist Ausnahme-Tracking, das zufällig neben Ihrer Verfügbarkeitsüberwachung liegt, damit „die Website läuft und wirft fünfhundert Fehler pro Minute“ ein Bildschirm ist und nicht zwei Produkte.