Benachrichtigungen und Statusseiten

Hosting-Integrationen stellen außerdem Änderungen der VM-Stromversorgung, fehlgeschlagene Operationen, Synchronisation und unterstützte Schwellenwerte für den Kontostand bereit. Abrechnungsalarme erfordern Zugriff auf die Abrechnung und eine Währung; eine laufende VM beweist nicht, dass ihr Opfield-Daemon online ist.

Erstellen Sie Ziele, Vorlagen und Alarmregeln für Zustand, Kapazität, Zertifikate, Deployments, Datenbanken, Builds und Plattformzustand. Testen Sie jedes Ziel, bevor Sie sich darauf verlassen.

Benachrichtigungen und Statusseiten dienen unterschiedlichen Zielgruppen. Benachrichtigungen fordern einen internen Verantwortlichen zum Handeln auf; eine Statusseite teilt Kunden mit, was sie erwarten können. Der Dienstverantwortliche legt Auswirkung und Priorität fest, der Verantwortliche in Rufbereitschaft erhält und löst Alarme, und der Kommunikationsverantwortliche veröffentlicht für Kunden geeignete Updates. Senden Sie nicht dieselben rohen technischen Nutzdaten an beide Zielgruppen.

Die Erfolgskriterien sind eindeutig: Eine bedeutsame Bedingung öffnet einen handlungsrelevanten Alarm, die Wiederherstellung schließt oder löst ihn, die Zustellung erreicht einen Kanal mit Verantwortlichem, und ein kundenseitiger Vorfall enthält zutreffende Auswirkungen, ohne Infrastrukturdetails offenzulegen. Ein konfiguriertes Ziel, das nie einen durchgängigen Test bestanden hat, ist nicht produktionsreif.

Zustandsbehaftete Alarme sollten sich öffnen, wenn eine Bedingung beginnt, und sich erholen, wenn sie endet. Konfigurieren Sie Schwellenwerte und Zeitfenster so, dass Flattern vermieden wird. Nehmen Sie Ressource, Auswirkung, Zeitstempel und Aktion für den Operator auf – keine Secrets und keine vollständigen Daemon-Fehler.

Statusseiten stellen Kunden einen ausgewählten Dienstzustand bereit. Der Wartungsmodus sollte als geplante Wartung erscheinen statt als unerklärter Ausfall. Halten Sie interne Topologie, private Node-Namen und sicherheitsrelevante Diagnosen von öffentlichen Seiten fern.

Entscheiden, was kommuniziert werden muss

Ordnen Sie Ereignisse nach Auswirkung auf Kunden und erforderlicher Aktion ein. Kapazitätstrends können als interne Warnungen beginnen; der Verlust eines öffentlichen Kundenablaufs kann sowohl einen dringenden Alarm als auch einen Statusvorfall erfordern. Vermeiden Sie es, für jeden Daemon oder Node eine öffentliche Komponente zu erstellen. Komponenten sollten Produkten oder Fähigkeiten entsprechen, die Kunden kennen, und einen Verantwortlichen haben, der Updates veröffentlichen kann.

Einigen Sie sich vor dem ersten Vorfall auf Schweregrad, Bestätigungszeit, Aktualisierungsrhythmus und Abschlusskriterien. Geplante Wartung sollte die betroffene Fähigkeit, das erwartete Zeitfenster und die Aktion für Kunden angeben. Sicherheitsvorfälle können einen eingeschränkten Kommunikationsprozess statt der sofortigen Offenlegung diagnostischer Details erfordern.

Benachrichtigungen konfigurieren

1. Erstellen Sie das Ziel und speichern Sie Zugangsdaten über den verschlüsselten Einstellungsweg.
2. Senden Sie eine Testbenachrichtigung und prüfen Sie Absenderidentität, Signatur, Darstellung und Zustelllatenz.
3. Erstellen Sie eine Alarmregel für eine bedeutsame Ressourcenbedingung.
4. Wählen Sie Schwellenwert, Auswertungsfenster, Erholungsfenster und Schweregrad.
5. Leiten Sie sie an einen Rufbereitschafts- oder Betriebskanal mit Verantwortlichem.
6. Lösen Sie die Bedingung in einer sicheren Umgebung aus und prüfen Sie sowohl die Öffnungs- als auch die Erholungsnachricht.

Vermeiden Sie Alarme, auf die Operatoren nicht reagieren können. Jede dringende Benachrichtigung sollte die betroffene Ressource, die Auswirkung auf Kunden, die Startzeit, den aktuellen Zustand und die erste sichere Diagnoseaktion nennen.

Alarmregeln erfordern notifications:alerts:view zum Lesen und notifications:alerts:manage zum Erstellen, Ändern oder Löschen. Webhooks und ihr Zustellverlauf erfordern notifications:webhooks:view, und das Erstellen, Testen, Ändern oder Löschen von Webhooks erfordert notifications:webhooks:manage. notifications:webhooks:manage legt außerdem Webhook-URLs, -Header und Zustellungs-Nutzdaten offen.

Regeln können Nodes, Container, Git-Builds, Compose-Projekte, Routen, Pages, Relays, Zertifikate, Datenbanken, verwalteten Speicher, strukturiertes Logging, Integrationssynchronisationen, Hosting-VMs und -Konten sowie Opfield selbst ansteuern. Eine Container-Regel auf Log Size (MB) findet Container, deren Logs unbegrenzt wachsen.

Opfield löst außerdem integrierte Ablaufalarme aus, die die zuständige Ressource nennen: für SSL- und Zertifikate der internen PKI bei den PKI-Schwellen für Warnung und kritisch, für CAs weit vor ihrem Ablauf, für Node-Zertifikate, deren Verlängerung fehlschlägt, und für Tokens von Git-Integrationen bei 30 und 7 Tagen. Jede Schwelle alarmiert einmal, und ein verlängertes Zertifikat alarmiert in seiner neuen Laufzeit erneut. Erstellen Sie für verwalteten Speicher und verwaltete Datenbanken eine Alarmregel für das Zertifikatsereignis Managed Service Certificate Renewal Failed, das sich öffnet, solange die automatische Verlängerung weiter fehlschlägt, und sich nach einer erfolgreichen Verlängerung erholt.

Benachrichtigungsvorlagen verwenden einen kanonischen verschachtelten Kontext. Halten Sie Vorlagen klein und testen Sie die genaue Darstellung im Ziel; historische flache Variablennamen sind keine Aliase und können leer dargestellt werden. Behandeln Sie Vorlagenänderungen als betriebliche Änderungen, denn eine fehlerhafte Nachricht kann Ressource, Schweregrad oder Erholungszustand verbergen, selbst wenn der Transport gelingt.

Rauschen reduzieren

• Verwenden Sie anhaltende Zeitfenster für Schwellenwerte bei CPU, Arbeitsspeicher, Festplatte, Latenz und Fehlerrate.
• Alarmieren Sie bei einem Zustandsübergang, statt denselben unveränderten Zustand zu wiederholen.
• Trennen Sie Kapazitätswarnungen von kritischen Auswirkungen auf Kunden.
• Unterdrücken oder kommentieren Sie Alarme während ausdrücklicher Wartung, statt die Regel zu löschen.
• Prüfen Sie regelmäßig veraltete, dauerhaft stummgeschaltete oder verantwortungslose Regeln.

Statusseiten betreiben

Erstellen Sie Komponenten, die für Kunden sichtbaren Diensten entsprechen, nicht der internen Daemon-Topologie. Ordnen Sie Vorfälle den betroffenen Komponenten zu, veröffentlichen Sie knappe Updates und unterscheiden Sie gemäß dem Kommunikationsprozess die Zustände Untersuchung, identifiziert, Beobachtung und gelöst.

Der Wartungsmodus einer verwalteten Route kann als geplante Wartung erscheinen. Bestätigen Sie, dass die öffentliche Statusansicht keine Node-Namen, privaten Adressen, Stacktraces, Ressourcen-IDs oder Sicherheitsdetails offenlegt.

Während Opfield nicht verfügbar ist

Opfield liefert die öffentliche Statusseite über einen Ingress Node aus, und dieser Node behält die letzte fehlerfreie Kopie der Seite, ihrer Assets und der Statusdaten, die die Seite abfragt. Während Opfield neu startet, aktualisiert wird oder nicht erreichbar ist, erhalten Besucher diese Kopie, die letzte, die abgerufen wurde, solange Opfield antwortete, sodass sie den Zustand kurz vor der Unterbrechung zeigt. Eine Seite, die zuvor nie geladen wurde, zeigt eine kurze Seite „Back in a moment“, die sich selbst neu lädt. Browser speichern die Seite nie, sodass Live-Daten zurückkehren, sobald Opfield antwortet; solange es antwortet, sind die Daten, die ein Besucher sieht, höchstens 5 Sekunden alt. Standardmäßig verwendet die Statusseite einen Upstream, den der Ingress Node erreichen kann. In den Einstellungen der Statusseite können Sie außerdem unter Ingress groups (served by every member) eine Ingress-Gruppe wählen, sodass jedes Mitglied die Seite ausliefert.

Ingress Nodes übernehmen dies, wenn sie sich mit einer aktualisierten Opfield-Installation neu verbinden. Das erste Opfield-Update auf ein Release mit diesem Verhalten unterbricht die Seite noch, weil der Cache leer ist, wenn die alte Opfield-Version stoppt; jedes spätere Update ist abgedeckt.

Schließen Sie einen Vorfall erst, nachdem der Kundenpfad geprüft wurde, nicht schon dann, wenn ein interner Alarm grün wird. Veröffentlichen Sie eine für die Zielgruppe geeignete abschließende Zusammenfassung und bewahren Sie detaillierte technische Erkenntnisse im internen Vorfalleintrag auf.

Details für Betreiber: Zustellfehler und Wiederherstellung

Schlägt die Zustellung fehl, prüfen Sie Zustand des Ziels, Authentifizierung, TLS-Validierung, Antwortstatus, Wiederholungsverlauf und Alter der Warteschlange. Rotieren Sie keine Zugangsdaten, ohne jedes abhängige Ziel zu aktualisieren. Senden Sie nach einer Reparatur einen neuen Test und bestätigen Sie das Zustellverhalten der Warteschlange, bevor Sie den Kanal für betriebsbereit erklären.

Halten Sie einen Ausweichkontaktweg für ein ausgefallenes primäres Ziel bereit. Prüfen Sie beim Testen Öffnungs- und Erholungsnachrichten, Deduplizierung, Darstellung, Links und Zeitstempel. Erstellen Sie bei einem echten Ausfall Ziele oder Regeln nicht wiederholt neu: Bewahren Sie den Zustellverlauf, beheben Sie den eng umrissenen Fehler und bestätigen Sie, ob eingereihte Nachrichten noch zugestellt werden sollen oder überholt sind.