Besseres Monitoring und Warnmeldungen für Fastlys TLS Certification Authority

Bei diesem Blogpost handelt es sich um den letzten Teil einer Reihe von Beiträgen, die sich mit der Entwicklung von Certainly</u>, der vertrauenswürdigen Certification Authority (CA) von Fastly, befassen. undefinedNeben architektonischen Überlegungen</u> sind wir bislang auf unsere Wahl eines traditionellen primären Replikatdatenbankdesigns</u> eingegangen. Heute wollen wir uns genauer ansehen, wie wir ein robustes, aber dennoch nachhaltiges Monitoring- und Benachrichtigungssystem umgesetzt haben.

Eine verlässliche Certification Authority sollte umfassende Logging- und Monitoring-Funktionen bieten, denn nur so können Serviceausfälle und verdächtige Aktivitäten innerhalb der Umgebung schnell erkannt werden. Die CA gewinnt damit nicht nur an Integrität, sondern liefert Operations-Teams auch die Daten, die sie brauchen, um auf Vorfälle zu reagieren.

Wir bei Fastly haben schon immer großen Wert auf gutes Echtzeit-Logging und Observability</u> sowie die Möglichkeit gelegt, Echtzeitdaten in andere Tools zu integrieren. Deshalb war uns von Anfang an klar, dass diese Funktionen auch bei unserer eigenen CA gegeben sein mussten.

Die redundante und zweckgerichtete Architektur von Certainly bedeutete, dass wir Protokolle und Metriken von vielen verschiedenen Systemen benötigten, darunter physische Hosts, Netzwerkgeräte und Kameras. Wir mussten diese Daten nicht nur sammeln, sondern sie auch zu einer aussagekräftigen Warnmeldung zusammenführen. Mit dem Begriff „Warnmeldung“ bezeichnen wir in diesem Beitrag Ereignisse, die eine dringende Push-Benachrichtigung an einen Entwickler im Bereitschaftsdienst auslösen. Nicht relevante und unübersichtliche Warnmeldungen lösen unnötige Weckrufe aus, ziehen Mitarbeiter von anderen wichtigen Aufgaben ab, stören sie in ihrer Freizeit, führen zu Burnout und beeinträchtigen schlussendlich die Zuverlässigkeit des Service. Deshalb möchten wir in diesem Blogpost auf die Bedeutung aussagekräftiger Warnmeldungen aufmerksam machen und den wirksamen Ansatz vorstellen, den Certainly verfolgt.

Bei der Festlegung von Warnmeldungen gilt es zunächst Logs und Metriken mit den richtigen Informationen zusammenzutragen. Certainly entschied sich für Splunk (mit PagerDuty Integration) als Monitoring-Plattform und standardisierte die beliebten Open-Source-Tools rsyslog und Telegraf für die Erfassung von Logs und Metriken. Nachdem diese Daten einmal erfasst und in Splunk verfügbar waren, war das Certainly Team in der Lage, Warnmeldungen zu erstellen, Vorfälle zu untersuchen und Störungsberichte zu verfassen. 

Zunächst legten wir circa 60 Warnmeldungen fest, die vorrangig Serviceausfälle oder Fehler im begleitenden Toolset betrafen. Als wir diese erstmals implementierten, wurden viele Fehlalarme ausgelöst, weil der Service oder der Host im Begriff war, neu angelegt zu werden, was Teil des ephemeren Designs von Certainly ist. Schon bald stellten wir fest, dass es nicht viele Fehlalarme brauchte, um unsere Support-Mitarbeiter zu überlasten und die Zuverlässigkeit des Supports aufs Spiel zu setzen.  Wir mussten eine bessere Lösung finden – und haben die folgenden korrigierenden Schritte unternommen.

Wir wägten die Notwendigkeit jeder einzelnen Warnmeldung sorgfältig ab. Hier einige Beispiele für Fragen, die wir uns dabei stellten:

• Müssen wir uns bei Backup-Fehlern wirklich benachrichtigen lassen, wenn wir bereits eine Warnmeldung für Wiederherstellungsfehler eingerichtet haben?

• Sollten wir uns auch dann benachrichtigen lassen, wenn nur einer von zwei redundanten (HA) Services ausfällt?

Wo möglich, fassten wir Warnmeldungen zusammen:

• Da die Cages unseres Rechenzentrums stets von vielen redundanten Bewegungssensoren überwacht werden, genügt es uns, nur dann eine Warnmeldung auszulösen, wenn zwei Sensoren aktiviert werden. Auf diese Weise können wir durch Vibrationen verursachte Fehlalarme ausschließen.

Wir passten die zeitlichen Schwellenwerte an, um häufigen Szenarien wie folgenden Rechnung zu tragen:

• Patching und Host-Rebuilds bedeuten, dass das Monitoring einzelner Instanzen eines Service im normalen Betrieb viele Warnmeldungen auslösen kann, weshalb wir die zeitlichen Schwellenwerte für jede Warnmeldung entsprechend anpassten.

Wenn nötig, deaktivierten wir Warnmeldungen vorübergehend:

• Bei autorisierten Seitenbesuchen ist es beispielsweise nicht zwingend notwendig, auf Verstöße gegen die physische Sicherheit hinzuweisen.  Dadurch entfällt auch der zur Bestätigung und Behebung der Warnmeldung erforderliche Aufwand.

All diese Verbesserungen resultierten in einem drastischen Rückgang der Warnmeldungen, wobei die ausgelösten Warnmeldungen zu 100 Prozent relevant waren. Die Arbeitsmoral und das Wohlbefinden unserer Support-Mitarbeiter verbesserten sich zusehends. Immer weniger Zeit musste für den Support bei Betriebsabläufen aufgewendet werden, wodurch mehr Zeit für die Verbesserung der Zuverlässigkeit des Service und der damit zusammenhängenden Infrastruktur blieb.

Unterm Strich hat sich der zur Optimierung unserer Warnmeldungen erforderliche Aufwand mehr als gelohnt. Certainly war noch nie besser aufgestellt, um die zusätzlichen Logging- und Monitoring-Anforderungen unseres wachsenden Kundenstamms zu erfüllen.