Issue beim bestätigten Ausfall anlegen
Das Issue entsteht, sobald genug unabhängige EU-Standorte den Check oft genug hintereinander abweisen, nicht schon bei der ersten fehlgeschlagenen Anfrage; beide Schwellen stehen in deinem Paket.
Uptimeify mit GitLab Issues nutzen.
Ein Zugriffstoken und ein Projekt, und ein bestätigter Ausfall wird zum Issue auf dem Board, auf dem dein Team ohnehin plant.
Was in GitLab ankommt
Was die Alarmkette in GitLab anlegt, steht hier vollständig, und mehr passiert nicht. Einmal lesen, und du weißt, was dein Team sehen wird.
Entwarnung als eigenes Issue ablegen
Die Entwarnung kommt als zweites Issue, mitsamt Zeitpunkt der Behebung und der Dauer des Ausfalls in Minuten.
Jedes Issue beschriften
Jedes Issue entsteht mit den Labels uptimeify und monitoring, damit ein Board-Filter oder eine Regel sie im Backlog findet.
Lesbare Beschreibung schreiben
URL, Kunde, Organisation, der Fehler samt Statuscode, die prüfenden Standorte und die Zeiten kommen als Markdown-Liste an.
Kritisches Zertifikat melden
Ein TLS-Zertifikat, das in seinen kritischen Bereich rutscht, öffnet ein eigenes Issue in dem Projekt, zu dem die Seite gehört.
Mit einer eigenen Instanz arbeiten
Dein GitLab wird über seine eigene Basis-URL angesprochen, die https sein muss und vor dem Aufruf gegen interne Ziele geprüft wird.
Ein Projekt je Kunde
Jeder Kanal benennt sein eigenes Projekt, damit der Ausfall eines Kunden auf dem Board landet, auf dem dessen Betreuer planen.
Test-Issue anlegen
Das Dashboard erzeugt beim Einrichten ein als TEST markiertes Issue, damit eine falsche Projekt-ID vor dem ersten Ausfall auffällt.
Nach einem eng gefassten Token fragen
Ein Projekt- oder persönliches Zugriffstoken mit dem api-Scope genügt, und es liegt verschlüsselt statt im Klartext.
Teams, die ihr Monitoring über Uptimeify fahren
In Minuten eingerichtet. Danach läuft es von allein.
1. Zugriffstoken anlegen
Ein Projekt- oder persönliches Zugriffstoken mit dem api-Scope für das Projekt anlegen, in dem die Issues landen sollen. Neuere GitLab-Versionen verstecken es im Anlegen-Menü hinter Legacy token.
Access token
glpat-xxxxxxxxxxxxxxxxxxxxVerschlüsselt gespeichert
2. Projekt benennen
Die numerische Projekt-ID oder den Gruppen- und Projektpfad eintragen und das Token einfügen.
3. Speichern und testen
Bei eigener Instanz die Basis-URL ergänzen, die Monitore zuordnen und das Test-Issue anlegen.
Bevor du GitLab verbindest.
Nein. Die Entwarnung wird als eigenes Issue abgelegt, statt das erste zu schließen. Das Ausfall-Issue behält Historie und Diskussion, und beide tragen das Label uptimeify, was einer Regel zum Schließen reicht.
Beides. Die numerische ID aus der Projektübersicht funktioniert, und der Gruppen- und Projektpfad ebenso, das ist die lesbare Variante.
Ja. Trage die Basis-URL deiner Instanz ein. Akzeptiert wird nur https, und die Adresse wird vor dem Senden aufgelöst und gegen interne sowie Loopback-Ziele geprüft.
Nein. Deine Quota deckt Monitore und das monatliche SMS- und Sprachkontingent. Issues in GitLab, GitHub oder Jira zehren nicht daran.
Nein. Das Issue entsteht zum bestätigten Ausfall, nicht je fehlgeschlagener Anfrage, und wie viele Nachprüfungen die Bestätigung braucht, legst du je Paket fest.
Jeder Alarm dort, wo dein Team ohnehin arbeitet.
GitLab einmal verbinden, und jeder bestätigte Ausfall landet als Issue in dem Projekt, zu dem die Seite gehört.