Funktionierte Beispiele für IncidentRelay v2.3.1, überprüft am . Die folgenden Namen, Kennungen und Zeitangaben dienen der Veranschaulichung. Validieren Sie sie in einer Testbereitstellung, bevor Sie Produktionsanmeldeinformationen verwenden.
Geschäftsbeispiel · Einrichtung · Arbeitsbeispiel · Abnahmeprüfungen · Grenzwerte und Fehlermodi
Geschäftsbeispiel: drei Client-Systeme, ein lauter Support-Chat
Anschauliches Szenario, keine Kundenfallstudie. Bei den folgenden Kennzahlen handelt es sich um Vorschläge für Ihr Pilotprojekt, nicht um gemessene Einsparungen oder um die Behauptung, dass IR jedes Berichts-Dashboard umfasst.
Situation und Risiko. Ein Dienstanbieter unterstützt drei Clients, jeweils mit Anwendungs- und Infrastrukturwarnungen. Alles landet in einem Chat. Ingenieure leiten Nachrichten an andere Teams weiter, während wiederholte Warnungen den Originalbericht verdecken. Das Geschäftsrisiko besteht in einer verzögerten Übernahme und einem vermeidbaren Supportaufwand, selbst wenn die Überwachung den Fehler umgehend erkannt hat.
Workflow mit IR. Ordnen Sie jeden Client-Service seinem verantwortlichen Team zu und verwenden Sie das vorgesehene Routen-Token für jeden Absender. Passen Sie Umgebungs- und Servicebezeichnungen an, wählen Sie das Bereitschaftsziel und gruppieren Sie Wiederholungen nur innerhalb der vorgesehenen Eigentumsgrenzen. Testen Sie den Produktionsabrechnungsdienst eines Kunden mit dem unten stehenden Matcher, bevor Sie das Muster erweitern.
Zu validierender betrieblicher Vorteil. Ersetzen Sie die routinemäßige Nachrichtenweiterleitung durch explizites Routing. Halten Sie die erste Reaktion bei dem Team, das handeln kann, und behalten Sie gleichzeitig separate untergeordnete Warnungen bei, wenn mehrere Hosts dasselbe Problem melden.
Was zu messen ist. Zählen Sie Warnungen, die nach der ersten Routing-Entscheidung neu zugewiesen wurden, Gruppen ohne Besitzer und Benachrichtigungen pro zugrunde liegendem Fehler für jeden Client. Überprüfen Sie auch abgelehnte oder nicht übereinstimmende Testereignisse: Weniger Seiten sind kein Erfolg, wenn der Ausfall eines Kunden unsichtbar wird.
Grenze. Beim Label-Abgleich handelt es sich nicht um die Isolierung von Kundendaten. Überprüfen Sie Zugriffsberechtigungen, Anmeldeinformationen und Bereitstellungsgrenzen separat. Inkonsistente Bezeichnungen oder eine zu breite Gruppierung können dennoch dazu führen, dass Arbeit an das falsche Team geschickt wird oder nicht verwandte Symptome kombiniert werden. Validieren Sie diese Fälle, bevor Sie einen anderen Kunden einbinden.
Getrennte Annahme, Besitz und Lieferung
Ein Produktionsabrechnungsdienst und eine Staging-Kopie sollten nicht versehentlich dieselben Leute wecken. Erstellen Sie für das erste Pilotprojekt eine Webhook-Route für das Produktionsabrechnungsteam, wählen Sie dessen Standarddienst und Rotation oder Richtlinie aus und fügen Sie Kanäle hinzu. Sein Einlasstoken wählt die Route aus; Übereinstimmende Labels allein authentifizieren keinen Absender und wählen keine beliebige Route aus.
Ein Narrow-Route-Matcher und ein expliziter Gruppierungsschlüssel
Fügen Sie dies in den Matcher-Editor der Route ein. Es handelt sich um ein Matcher-Objekt, nicht um den eingehenden Webhook-Body. Alle Bedingungen verwenden UND-Semantik. Durch die Vorgabe von Produktions- und Servicekennzeichnungen werden Inszenierungen und nicht gekennzeichnete Veranstaltungen von diesem Weg ferngehalten.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}Legen Sie für dieses Beispiel das Feld group_by der Route fest auf:
["alertname", "severity", "labels.cluster"]Zwei Hosts, die denselben Alarm im selben Cluster melden, können dann eine AlertGroup gemeinsam nutzen und dabei getrennte untergeordnete Identitäten beibehalten. Verwenden Sie für einen generischen Webhook stabile Fingerabdrücke wie billing:node-1:health und billing:node-2:health. Fügen Sie die erwarteten Bezeichnungen für Fehler und Wiederherstellung hinzu und verwenden Sie niemals einen neuen Zeitstempel als Identität für jeden Wiederholungsversuch.
Deduplizierung und Gruppierung sind unterschiedlich: Der gleiche Fingerabdruck aktualisiert ein untergeordnetes Element; Verschiedene Fingerabdrücke mit demselben Gruppenschlüssel erzeugen separate Kinder in einer Gruppe. Route, Team, Quelle und Service sowie Umfangsgruppierung. Fügen Sie instance nur dann zu den Gruppierungsfeldern hinzu, wenn jeder Host eine separate Gruppe sein soll.
Wenn ein Absender wirklich mehrere Teams bedient
Verwenden Sie globale Orchestrierung, wenn die Eigentümerschaft aus dem Veranstaltungsinhalt ausgewählt werden muss. Beginnen Sie im Builder mit den Bedingungen labels.environment equals production und labels.service equals billing-api und wählen Sie dann gültige Team-, Routen- und Serviceobjekte aus derselben Gruppe aus. Kopieren Sie keine numerischen Objekt-IDs zwischen Installationen.
Validieren und simulieren Sie sowohl Übereinstimmungen als auch Nichtübereinstimmungen, veröffentlichen Sie sie und verwenden Sie dann die Kompatibilität von shadow mit hybrid. Überprüfen Sie die tatsächlichen Ausführungen, bevor Sie zu active wechseln. Shadow zeichnet Entscheidungen auf, ohne das Produktionsverhalten zu ändern; Der Simulator beweist keine End-to-End-Lieferung.
Verwenden Sie eine kleine Routing-Testmatrix
| Eingang | Erwartetes Ergebnis für dieses Beispiel |
|---|---|
| Produktionsabrechnungsereignis | Matcher-Pässe; Der ausgewählte Dienst, der Beauftragte und die Kanäle stimmen mit der geplanten Eigentümerschaft überein. |
| Bereitstellung oder fehlendes Serviceetikett | Matcher passt nicht. Bestätigen Sie den vom Absender beabsichtigten alternativen Pfad. In diesem Beispiel wird keine Catch-All-Route erstellt. |
| Doppelter Fingerabdruck | Das gleiche Kind wird aktualisiert. Ein anderer Host-Fingerabdruck erstellt ein zweites untergeordnetes Element in derselben Gruppe, wenn die Gruppierungsbezeichnungen übereinstimmen. |
| Genesung nur für eines von zwei Kindern | Dieses Kind entschließt sich; Die Gruppe feuert weiter, bis sich alle schießenden Kinder erholt haben. Eine verwaiste Wiederherstellung erstellt keine neue Gruppe. |
Vermeiden Sie Regeln, die die Beweise stillschweigend löschen
Ein leerer Matcher gleicht alles ab. Eine Bezeichnung mit dem Namen severity ist nicht automatisch dasselbe Feld wie der normalisierte Ereignisschweregrad. Verwenden Sie den dokumentierten Feldpfad und untersuchen Sie ein echtes normalisiertes Ereignis. Erfordern Sie status=firing nicht auf einem Aufnahmepfad, der auch eine Wiederherstellung akzeptieren muss.
active + legacy wendet keine Orchestrierungsentscheidungen an. In hybrid können ungültige Entitätskombinationen auf den Legacy-Pfad zurückgreifen; Der autorisierende orchestration-Modus blockiert stattdessen die Verarbeitung bei Auswertungs- oder Entitätsvalidierungsfehlern. Wählen Sie das Fehlerverhalten bewusst aus.
Beginnen Sie ohne allgemeine drop- oder suppress-Regeln. Durch Unterdrückung und Gruppierung können Benachrichtigungen reduziert werden, ein schlechtes Überwachungssignal ist jedoch nicht sinnvoll. Behalten Sie eine getestete Vorgängerversion bei und überprüfen Sie unerwartete Nichtübereinstimmungen, bevor Sie den Rollout ausweiten.