Betriebsfehler

Dokumentation · Anbindung

Deine Anwendung meldet ihre Fehler aus dem Betrieb selbst — der Posteingang sammelt und zählt sie, und du entscheidest, ob daraus ein Reparatur-Lauf wird. Am Ende steht höchstens ein Entwurfs-Pull-Request, nie ein Merge.

Deine Anwendung meldet einen Fehler aus dem Betrieb selbst zurück — Anvil Coder sammelt ihn, zählt ihn, und du entscheidest, ob daraus ein Reparatur-Lauf wird. Am Ende steht höchstens ein Entwurfs-Pull-Request, nie ein Merge.

Alle Bildschirmfotos zeigen eine Demo-Umgebung mit Beispieldaten.

In 15 Minuten angebunden

1. Kanal anlegen. Im Cockpit unter Integrationen (oder in der Projekt-Liste über die drei Punkte → Kanäle für Betriebsfehler) wählst du das Projekt und legst einen Kanal an. Du bekommst dabei einen Schlüssel und die Adresse, an die gemeldet wird.
2. Schlüssel eintragen. Der Schlüssel beginnt mit anv_srv_ und gehört in die Konfiguration deiner Anwendung — genauso wie eine Datenbank-Zugangsdaten. Er steht nicht ins Repository. Wie das SDK in eine Laravel- oder Spring-Boot-Anwendung kommt, steht im Kapitel Anvil Feed einbauen.
3. Umgebung binden. Ein Kanal allein nimmt noch nichts an. Binde die Umgebung, die dein SDK sendet (production, staging, …) — oder * für alle. Beim Anlegen wird bereits eine Bindung für * mit der Regel Planen, Freigabe abwarten gesetzt, damit die erste Meldung ankommt.
4. Einmal melden lassen. Löse in deiner Anwendung einen Fehler aus (oder schicke die Beispiel-Anfrage aus dem Server-Vertrag). Nach wenigen Sekunden steht der Vorfall im Posteingang.

Der Schlüssel wird genau einmal angezeigt. Gespeichert wird bei uns nur seine Prüfsumme und die ersten Zeichen, damit du ihn in der Liste wiedererkennst. Verloren heisst: sperren und einen neuen Kanal anlegen — nicht „beim Support nachfragen”.

Der Posteingang

Gleichartige Fehler werden zusammengefasst: derselbe Dienst, dieselbe Ausnahme, dieselben obersten drei Stellen der Aufrufkette ergeben einen Vorfall mit einem Zähler. Ein Fehler, der zehntausendmal auftritt, füllt also nicht zehntausend Zeilen.

Die Spalte Vorkommen zeigt diesen Zähler. Die einzelnen Meldungen werden nach 30 Tagen gelöscht, der Zähler bleibt — deshalb kann im Detail „412 Meldungen” stehen, während nur noch sechs einzelne Meldungen gespeichert sind. Das Cockpit sagt das an der Stelle auch dazu.

Über die Status-Knöpfe oben schränkst du die Liste ein. Ohne Auswahl siehst du alle Status.

Was die Status bedeuten

Status	Bedeutung
Beobachtet	Angekommen, noch nicht eingeordnet.
Eingeordnet	Der Vorfall ist einem Projekt und einer Bindung zugeordnet und kommt für eine Reparatur in Frage.
Wartet auf Freigabe	Ein Reparatur-Lauf ist geplant. Er startet erst, wenn ein Mensch freigibt.
Eingereiht	Freigegeben, wartet auf einen freien Platz.
Lauf läuft	Der Reparatur-Lauf arbeitet.
Entwurfs-PR offen	Es gibt einen Pull Request — als Entwurf. Prüfen und zusammenführen ist Menschenarbeit.
Braucht einen Menschen	Automatisch geht es nicht weiter. Die Begründung steht daneben.
Ignoriert	Bewusst nicht bearbeitet, mit Begründung. Lässt sich wieder aufnehmen.
Geschlossen	Ein Mensch hat den Vorfall abgeschlossen.

Geschlossen wird immer von Hand. Anvil Coder kann heute nicht beobachten, ob der Fehler im Betrieb aufgehört hat — also behauptet es das auch nicht.

Ein Vorfall im Detail

Oben stehen die Kennzahlen: Status, Schwere, Projekt, Dienst, Umgebung, die erste und die letzte Version, in der der Fehler auftrat, und die Bindung, über die er hereinkam. Darunter:

• Vorkommen — der Zähler, eine kleine Tages-Kurve und die noch gespeicherten Einzelmeldungen mit Version, SDK und Anfrage.
• Fehlermeldung und Aufrufkette — die obersten Stellen zuerst; wo das SDK Quelltext mitgeschickt hat, lässt er sich aufklappen.
• Reparatur-Versuche — je Versuch der Status, der Nachweis, der Basis-Commit und der Link zum Entwurfs-PR.

Die zwei Nachweis-Etiketten

Sie stehen wörtlich im Cockpit, weil sie hier erklärt werden und weil jedes freundlichere Wort mehr behaupten würde, als gemessen wurde:

• BUILD_GREEN — der Bau war grün. Mehr nicht. Ob der Fehler weg ist, weiss dieser Nachweis nicht.
• VERIFIED_BUILD — der Lauf ist sauber durchgelaufen, ein Test-Abschnitt wurde ausgeführt und das VERIFY-Gate war grün.

Es gibt kein Etikett „Regression bewiesen”. Ein Beweis wäre: derselbe Test schlägt auf dem alten Stand fehl und geht mit der Änderung durch. Diese Messung baut Anvil Coder heute nicht — und was nicht gemessen wird, wird auch nicht behauptet.

Die Production-Karte im Dashboard

Solange ein Projekt seine Vorfälle nicht von aussen ans Dashboard meldet, füllt der Vorfall-Speicher dessen Production-Karte: offene Vorfälle stehen als „offen”, ein laufender Reparatur-Lauf und ein offener Entwurfs-PR als „in Bearbeitung”; geschlossene und ignorierte verschwinden von der Karte. Ein Vorfall, der einen Menschen braucht, zählt dabei als offen — entschärft ist daran nichts, die Maschine wartet nur.

Pro Projekt schreibt genau eine Quelle die Karte. Meldet dein Projekt Vorfälle bereits über die externe Dashboard-Schnittstelle (PUT /api/ingest/dashboard/…/incidents), behält diese Quelle die Karte — der Vorfall-Speicher überschreibt sie nicht. Zwei Schreiber auf einer Karte hiessen: der letzte gewinnt, und kein Bild ist je vollständig. Der Posteingang zeigt deine Vorfälle in beiden Fällen unverändert.

Wer darf was

• Jedes Mitglied der Organisation liest den Posteingang und jeden Vorfall.
• Eigentümer der Organisation entscheiden: freigeben, ignorieren, an einen Menschen übergeben, wieder aufnehmen, schliessen. Ignorieren und Übergeben verlangen eine Begründung (höchstens 800 Zeichen) — sie steht später als einzige Erklärung neben dem Status.
• Kanäle anlegen, sperren und Umgebungen binden dürfen ebenfalls nur Eigentümer: ein Kanal erzeugt einen Schlüssel.

Eine Freigabe wechselt den Status nicht sofort. Der Reparatur-Dienst übernimmt sie bei seinem nächsten Durchlauf, in der Regel binnen 15 Sekunden.

Umgebungen und Regeln

Eine Bindung sagt, was mit Meldungen aus einer Umgebung geschehen darf:

Regel	Wirkung
Nur beobachten	Der Vorfall wird gesammelt und gezählt. Kein Lauf.
Planen, Freigabe abwarten (Voreinstellung)	Der Lauf wird geplant — die Planung wird abgerechnet — und wartet auf die Freigabe eines Menschen.
Selbständig bis zum Entwurfs-PR	Ohne Rückfrage bis zum Entwurfs-PR. Setzt zusätzlich voraus, dass das Projekt Läufe automatisch starten darf.
Abgeschaltet	Es passiert nichts.

Meldungen aus einer Umgebung ohne Bindung werden angenommen und verworfen; die Antwort nennt no_binding. Wer eine neue Umgebung ausrollt, bindet sie vorher.

Zwei weitere Grenzen, die im Alltag auffallen:

• Höchstens fünf Reparatur-Versuche pro Projekt in 24 Stunden. Ist die Grenze erreicht, wird der Vorfall auf Braucht einen Menschen gesetzt und die Grenze benannt — er verschwindet nicht.
• Reparieren kann Anvil Coder nur auf einem Code-Hoster, für den der Weg nachweislich funktioniert. Ist dein Projekt woanders zu Hause, lehnt das Binden einer reparierenden Regel ab — Planen, Freigabe abwarten und Selbständig bis zum Entwurfs-PR — mit einem Hinweis, der die möglichen Hoster nennt. Nur beobachten und Abgeschaltet kannst du auf jedem Hoster binden: beide fassen deinen Code nicht an. So kann auch ein GitLab-Projekt seine Vorfälle sammeln und zählen lassen, ohne dass jeder davon unter Braucht einen Menschen landet.

Das Tempo-Limit

Der Kanal nimmt 600 Anfragen pro Minute an — Anfragen, nicht einzelne Meldungen. Ein SDK, das bis zu 50 Meldungen pro Anfrage bündelt, kommt damit auf 30 000 Meldungen pro Minute. Darüber antwortet der Server mit 429 und einem Retry-After; die SDKs halten sich daran.

Die vollständigen Regeln der Schnittstelle — Statuscodes, Ablehnungsgründe, Grössenschranken und ein curl-Beispiel — stehen im Server-Vertrag des Anvil Feed.

Häufige Fragen

Meine Meldungen kommen nicht an. Prüfe der Reihe nach: Ist der Schlüssel unverändert übernommen worden (er beginnt mit anv_srv_)? Ist die Umgebung gebunden, die dein SDK sendet? Antwortet der Server 404, ist die Funktion auf diesem Server nicht eingeschaltet — das Cockpit sagt das an der Karte auch so.

Der Dienstname in meinem SDK hat sich geändert. Der Vorfall bleibt beim Projekt des Schlüssels; der neue Name wird am Vorfall vermerkt. Ein SDK, das einmal richtig konfiguriert war, wird nicht wegen einer Umbenennung abgewiesen.

Warum wurde mein Pull Request nicht zusammengeführt? Weil ein Reparatur-Lauf grundsätzlich beim Entwurf endet. Das ist keine Einstellung, die man vergessen hat, sondern die Zusage dieser Funktion.