Issues und Alerts
Issues und Gruppierung
Jedes Event, das Blipit annimmt, erhält einen Fingerprint. Events mit demselben Fingerprint landen in einem Issue, das die Anzahl, den ersten und letzten Zeitpunkt, die beteiligten Releases und einen Status trägt. Sie arbeiten an Issues, nicht an Events, sodass ein Bug, der zehntausendmal auftritt, eine Zeile in der Liste ist.
1Wie der Fingerprint entsteht
Wenn das SDK ein fingerprint-Array sendet, gewinnt das. Andernfalls hasht Blipit den Exception-Typ plus die letzten fünf In-App-Stack-Frames (Dateiname und Funktion). Gibt es keine In-App-Frames, verwendet es den Exception-Typ und die Meldung, wobei Zahlen, Hex-Adressen und UUIDs ersetzt werden, sodass 'order 4821 not found' und 'order 9 not found' zusammen gruppiert werden. Events ohne Exception werden nach der normalisierten Meldung gruppiert.
2Gruppierung mit Regeln ändern
Öffnen Sie die Projektseite und fügen Sie eine Gruppierungsregel hinzu. Regeln laufen der Reihe nach, und der erste Treffer gewinnt. Eine Regel prüft auf Exception-Typ ist gleich, Meldung passt auf Regex, Dateiname oder Funktion im Stack Frame enthält, oder Tag ist gleich. Gruppieren legt jedes passende Event in ein Issue; Ignorieren verwirft das Event vor dem Speichern. Regeln brauchen bis zu einer Minute, um zu greifen. Regexe sind auf 200 Zeichen begrenzt, müssen kompilieren und dürfen keine Rückverweise, Lookarounds oder verschachtelten Wiederholungen wie (a+)+ verwenden.
3Beheben, ignorieren, wieder öffnen
Ein Issue ist ungelöst, behoben oder ignoriert. Beheben Sie es, wenn Sie einen Fix ausliefern: Kommt der Fehler zurück, wird das Issue als Regression wieder geöffnet und Sie werden alarmiert. Das Issue sagt, ob es im selben Release zurückkam (der Fix wurde nie ausgeliefert) oder in einem späteren (etwas hat es wieder eingeführt). Ignorieren zählt Events weiter, stoppt aber Alerts. Wieder öffnen setzt es zurück auf ungelöst. Die Issues-Liste hat Massenaktionen, und Alert-E-Mails enthalten Links zum Beheben und Ignorieren, die um Bestätigung bitten und einmal funktionieren.
4Schlummern
Von der Issue-Seite aus für 1 Stunde, 24 Stunden, 7 Tage oder die nächsten 100 oder 1.000 Vorkommen schlummern lassen. Events werden weiterhin erfasst und gezählt; Alerts für neue Issues und Regressionen werden bis zum Ende der Schlummerzeit übersprungen. Sicherheits-Alerts sind nicht betroffen.
Gut zu wissen
- Blipit bewahrt den vollständigen Payload für das erste Event eines Issues, jede Regression, jedes Sicherheitsereignis und die ersten 20 Events in jeder UTC-Stunde auf. Andere Events speichern eine Zusammenfassung (ID, Zeit, Plattform, Level, Release, Umgebung, Tags, Nutzer-ID, SDK). Die Issue-Seite sagt 'Vollständige Details für N von M Events'; Stack Trace, Breadcrumbs und KI-Fix lesen den neuesten vollständigen Payload.
- Über der monatlichen Event-Obergrenze Ihres Plans wird 1 von 10 Events behalten und der Rest als gesampelt gezählt; nichts wird berechnet. Die Verbrauchsseite zeigt die gesampelte Anzahl.
- Alerts sind auf 30 Alerts für neue Issues oder Regressionen pro Projekt und Stunde begrenzt, damit ein Fehlersturm Ihr Postfach nicht überflutet.
Kommen Sie nicht weiter? Schreiben Sie an support@blipit.io. Schlüssel und den genauen DSN jedes Projekts finden Sie unter API-Schlüssel in app.blipit.io.

