Betrieb und Monitoring: So merken wir, wenn Ihre Anwendung nicht rund läuft

Mit dem Go-live fängt die eigentliche Arbeit an. Ab dann soll die Anwendung jeden Tag funktionieren, auch nach jeder neuen Auslieferung und auch dann, wenn ein angebundener Dienst gerade Probleme hat. Dass eine Seite erreichbar ist, heißt dabei noch nicht viel. Sie kann antworten und trotzdem leer sein. Der Warenkorb kann funktionieren und der Bezahlschritt nicht. Wir überwachen deshalb nicht nur Server, sondern auch das, worauf es Ihnen ankommt: dass Ihre Kunden bestellen, anfragen und sich anmelden können.

Kurz gesagt

• Wir prüfen von außen, ob Ihre Seite antwortet, ob sie den erwarteten Inhalt zeigt, ob sie schnell genug ist und ob ihr Zertifikat gültig ist.
• Fehler, die nur im Browser Ihrer Kunden auftreten, landen gesammelt bei uns, mit Seite, Browser und Häufigkeit.
• Fachliche Alarme melden, wenn das Geschäft stockt, zum Beispiel wenn in einem Onlineshop keine Bestellungen mehr eingehen.
• Alarme kommen gebündelt und abgestuft an. Jeden Morgen fasst ein Tagesbericht zusammen, was ansteht.
• Backups laufen alle vier Stunden, und wir spielen sie regelmäßig testweise zurück.
• Alle Werkzeuge sind Open Source und laufen auf unserer eigenen Infrastruktur.

„Läuft“ hat vier Ebenen

Wenn wir sagen, eine Anwendung läuft, meinen wir vier Dinge:

• Erreichbar: Die Seite antwortet.
• Richtig: Sie zeigt den erwarteten Inhalt, schnell genug und mit gültigem Zertifikat.
• Fehlerfrei: Abläufe laufen ohne Fehler durch, auf dem Server und im Browser.
• Wirksam: Es passiert, wofür es die Anwendung gibt. Bestellungen gehen ein, Anfragen kommen an.

Viele Überwachungen hören nach der ersten Ebene auf. Die teuren Störungen stecken aber oft in den letzten beiden: Die Seite ist da, aber niemand kann kaufen.

Von außen geprüft: Erreichbarkeit und Inhalt

Ein Prüfdienst ruft Ihre wichtigsten Seiten rund um die Uhr regelmäßig über ihre öffentliche Adresse auf, so wie es ein Kunde tun würde. Er prüft dabei mehr als die Antwort:

• Antwortet die Seite? Sonst ist sie nicht erreichbar.
• Steht der erwartete Inhalt darauf? Eine Seite kann technisch einwandfrei antworten und trotzdem leer sein, etwa wenn nach einer Auslieferung die Inhalte nicht nachgeladen werden. Wir prüfen deshalb, ob zum Beispiel die Hauptüberschrift vorhanden ist.
• Ist sie schnell genug? Braucht eine Seite länger als fünf Sekunden, schlagen wir an.
• Läuft das Zertifikat bald ab? Eine Woche vorher meldet sich der Prüfdienst. Erneuert wird automatisch, die Meldung fängt den Fall ab, in dem das einmal nicht klappt.

Dashboards: der Zustand auf einen Blick

Alle Messwerte laufen in Prometheus zusammen und werden in Grafana dargestellt. Zu jeder Anwendung sehen wir Antwortzeiten, Fehlerquoten, Auslastung, Speicherplatz, Datenbanken und Zwischenspeicher. Für den täglichen Blick gibt es eine Übersicht, die zeigt, ob alles im grünen Bereich ist und wo es sich lohnt, genauer hinzusehen.

Dashboards helfen bei der Fehlersuche und bei der Planung, zum Beispiel wenn der Speicherplatz einer Datenbank stetig wächst. Bemerkt wird eine Störung aber nicht dadurch, dass jemand auf ein Dashboard schaut. Dafür sind die Alarme da.

Fachliche Alarme: wenn keine Bestellungen mehr kommen

Die wichtigste Frage für einen Onlineshop ist nicht, ob der Server läuft, sondern ob verkauft wird. Es gibt Störungen, bei denen technisch alles in Ordnung aussieht. Ein Zahlungsanbieter ändert seine Schnittstelle, ein eingebundenes Skript blockiert den Bestellknopf, eine Versandart ist plötzlich nicht mehr wählbar. Die Seite antwortet, die Server sind ruhig, und trotzdem geht keine Bestellung ein.

Solche Fälle erkennt nur eine fachliche Kennzahl. Bei einem Onlineshop, den wir betreuen, zählen wir deshalb die Bestellungen der letzten Stunde. Fällt die Zahl tagsüber eine Stunde lang auf null, geht ein kritischer Alarm raus. Nachts ist der Alarm aus, weil dann auch in einem gesunden Shop eine Stunde ohne Bestellung vorkommt.

Welche Kennzahl passt, hängt von Ihrem Geschäft ab. Das können Bestellungen sein, Anfragen über ein Formular, neue Anmeldungen oder ein nächtlicher Datenabgleich, der jeden Morgen fertig sein muss. Wir legen die Kennzahl und die Schwelle gemeinsam mit Ihnen fest, so dass ein Alarm etwas bedeutet und nicht bei jeder ruhigen Stunde anschlägt.

Fehler im Browser: was Ihre Kunden sehen

Viele Fehler entstehen nicht auf dem Server, sondern im Browser Ihrer Kunden. Ein bestimmter Browser kommt mit einer Funktion nicht zurecht, ein Teil der Seite lädt nach einer Auslieferung nicht nach, eine Schaltfläche reagiert nicht. In den Serverprotokollen taucht davon nichts auf. Ohne eigene Fehlererfassung erfahren Sie davon erst, wenn sich jemand beschwert. Die meisten Kunden beschweren sich nicht, sie gehen.

Unsere Anwendungen melden solche Fehler deshalb automatisch an GlitchTip, eine quelloffene Fehlererfassung, die wir selbst betreiben. Gleiche Fehler werden zusammengefasst. Wir sehen, wie oft ein Fehler auftritt, auf welcher Seite, in welchem Browser und seit wann, also auch, ob er mit einer neuen Auslieferung aufgetaucht ist.

Zu jedem Fehler gibt es die Stelle im Code, an der er aufgetreten ist, und die Umstände: Browser, Betriebssystem, Seite. Das spart bei der Suche nach der Ursache viel Zeit.

Protokolle: was im Hintergrund passiert

Die Protokolle aller Anwendungen landen an einer zentralen Stelle, in Grafana Loki. Wir müssen also nicht auf einzelnen Servern suchen, sondern können alle Teile einer Anwendung gemeinsam durchsuchen. In unseren Anwendungen bekommt jede Anfrage eine Kennung. Damit lässt sich eine einzelne Anfrage durch die beteiligten Teile verfolgen.

Auch auf die Protokolle achten Alarme. Tauchen dort Fehler auf, wissen wir es innerhalb weniger Minuten, auch dann, wenn nach außen noch alles gut aussieht.

Alarme: wer wann was erfährt

Ein Alarm ist nur nützlich, wenn er gelesen wird. Wer bei jeder Kleinigkeit benachrichtigt wird, hört irgendwann nicht mehr hin. Wir halten uns deshalb an ein paar Regeln:

• Gebündelt: Fällt ein Dienst aus, kommt eine Nachricht, nicht hundert.
• Abgestuft: Wir unterscheiden zwischen „bitte bald ansehen“ und „jetzt handeln“. Läuft ein kritischer Alarm, werden die zugehörigen Warnungen zurückgehalten, damit die Ursache nicht im Rauschen untergeht.
• Hartnäckig: Solange ein Problem besteht, erinnert der Alarm alle vier Stunden daran.
• Getrennt: Sicherheitsmeldungen laufen in einem eigenen Kanal.
• Eskalierend: Dauert eine Störung länger, kommen zusätzlich E-Mail und SMS. Auf Wunsch informieren wir dann auch Ihr Team direkt.

Die Regeln selbst liegen als Text in unserem Repository. Jede Änderung ist dort nachvollziehbar.

Jeden Morgen ein Tagesbericht

Nicht alles ist ein Alarm. Ein Zertifikat, das in drei Wochen abläuft, ein Fehler, der zweimal am Tag auftritt, ein Rückgang der Besucherzahlen: Das muss niemand nachts wissen, aber es darf auch nicht untergehen.

Deshalb gibt es jeden Morgen vor Arbeitsbeginn einen Tagesbericht. Er sammelt offene Alarme, neue Fehler, den Zustand der Backups, ablaufende Zertifikate, Sicherheitsbefunde und die Entwicklung der Besucherzahlen. Sortiert ist er danach, was heute erledigt werden sollte, was bald dran ist und was warten kann.

Backups, die auch zurückgespielt werden

Alle vier Stunden sichern wir Datenbanken und Dateien auf einen getrennten Speicher außerhalb der Anwendung. Bleibt eine Sicherung aus, meldet sich ein eigener Alarm. Ein Backup, das nie zurückgespielt wurde, ist allerdings nur eine Hoffnung. Deshalb spielt ein automatischer Test die Sicherungen jedes Quartal testweise zurück. Scheitert der Test oder ist er überfällig, gibt es ebenfalls einen Alarm.

Sicherheit im laufenden Betrieb

Software altert, auch wenn niemand sie ändert. Es werden laufend neue Schwachstellen in Bausteinen bekannt, die in fast jeder Anwendung stecken. Wir prüfen deshalb alle laufenden Anwendungen fortlaufend gegen bekannte Schwachstellen (Trivy). Für das Beheben gelten feste Fristen, je nach Schwere. Am Eingang unserer Infrastruktur erkennt und sperrt CrowdSec typische Angriffsmuster automatisch.

Nutzung verstehen, ohne Cookies

Ob eine Anwendung ihren Zweck erfüllt, zeigt sich auch an der Nutzung. Für Besucherzahlen, Quellen und beliebte Seiten setzen wir Plausible ein, selbst betrieben und ohne Cookies. Zusätzlich messen wir, was fachlich zählt, etwa wie viele Anfragen abgeschickt oder Produkte in den Warenkorb gelegt werden. Die Besucherzahlen stehen auch im Tagesbericht, so fällt ein Einbruch schnell auf.

Für tiefere Auswertungen in Anwendungen, etwa welche Wege Nutzer durch einen Ablauf nehmen und wo sie abbrechen, erproben wir derzeit Rybbit, ebenfalls selbst betrieben.

Fragen, die Sie Ihrem Dienstleister stellen können

Wenn Sie den Betrieb Ihrer Anwendung prüfen oder neu vergeben wollen, helfen diese Fragen:

• Woran merken Sie, dass unser Shop keine Bestellungen mehr annimmt, obwohl die Seite erreichbar ist?
• Sehen Sie Fehler, die nur im Browser unserer Kunden auftreten?
• Wer erfährt von einer Störung am Wochenende, und was passiert dann?
• Wann wurde unser Backup zuletzt testweise zurückgespielt?
• Wo liegen Protokolle, Fehlerberichte und Nutzungsdaten, und wer hat Zugriff?

Fazit

Gute Überwachung misst nicht möglichst viel, sondern das Richtige: ob Ihre Anwendung erreichbar ist, ob sie das Richtige zeigt, ob sie fehlerfrei arbeitet und ob sie ihren Zweck erfüllt. Für die ersten drei Ebenen bringen wir ein erprobtes Grundgerüst mit. Die vierte Ebene richten wir gemeinsam mit Ihnen ein, denn nur Sie wissen, welche Zahl in Ihrem Geschäft nicht auf null fallen darf.

Auf welchen Bausteinen unsere Anwendungen aufbauen, lesen Sie in unserer Referenzarchitektur für den Mittelstand. Was wir im Betrieb übernehmen, auch für Anwendungen, die jemand anderes gebaut hat, steht unter Betrieb und Wartung. Sie möchten wissen, wie gut Ihre Anwendung heute überwacht wird? Sprechen Sie uns an.

Werkzeuge

• Prometheus: Messwerte und Alarmregeln
• Grafana: Dashboards
• Grafana Loki: zentrale Protokolle
• GlitchTip: Fehlererfassung in Browser und Server
• Plausible: Besucherstatistik ohne Cookies
• Rybbit: Produktanalyse, in Erprobung
• Trivy: Prüfung auf bekannte Schwachstellen
• CrowdSec: Erkennung von Angriffsmustern
• restic: verschlüsselte Backups