Dokumentation

Monitore

Ein Monitor ist eine Sache, die überwacht werden soll, plus die Regel, nach der entschieden wird, ob sie gesund ist. Es gibt dreißig Arten. Die meisten stellen eine Anfrage aus unserem Netz und beurteilen die Antwort; zwei warten darauf, dass etwas aus Ihrem eintrifft, und vier sammeln, was Ihre Router an Ihre eigene private Sonde exportieren.

Die Arten

Web und Netzwerk

Zertifikate und Domains

E-Mail

Infrastrukturprotokolle

Diese gibt es, weil eine tcp-Prüfung auf dem Port fast nichts über sie aussagt. Ein SMSC nimmt TCP noch lange an, nachdem es niemanden mehr anmeldet; ein SIP-Stack kann bei offenem Socket festhängen; ein XMPP-Server mit abgelaufenem Zertifikat schließt den TCP-Handshake weiterhin ab.

Datenbanken

Pro und höher. Eine tcp-Prüfung auf 5432 belegt, dass irgendetwas einen Socket angenommen hat — und jeder interessante Datenbankfehler lässt den Socket offen: Postgres in der Wiederherstellung, ein von einer undichten Anwendung ausgeschöpftes Verbindungslimit, eine Rolle mit abgelaufenem Passwort, eine umbenannte Datenbank, ein Datenverzeichnis, das nicht eingebunden wurde. Diese Prüfungen öffnen daher eine Verbindung, melden sich an und stellen dem Server eine triviale Frage.

Keine davon liest oder schreibt irgendetwas. Das ist eine Verfügbarkeitsprüfung, keine synthetische Transaktion: Geben Sie ihr ein Konto, das nichts kann außer sich zu verbinden.

Die Anmeldedaten werden unverschlüsselt gespeichert, weil die Sonde, die die Prüfung ausführt, die Konfiguration so bekommt, wie sie ist. Deshalb laufen diese fünf nur auf einer für personenbezogene Daten freigegebenen Sonde — dieselbe Einschränkung, diesnmp und smpp tragen.

Das bedeutet einen von zwei Orten. Ihre eigene private Sonde, auf die diese Prüfungen ausgelegt sind: sie läuft auf Ihrer Hardware in Ihrem Netz, die Konfiguration verlässt also Ihre Infrastruktur nie — und sie ist meist das Einzige, was eine überwachungswürdige Datenbank überhaupt erreicht, denn eine Datenbank hinter einer VPC, einem privaten Link oder einer Allowlist ist aus keinem fremden Netz erreichbar, auch nicht aus unserem. Andernfalls unsere eigenen EU-Standorte, für eine Datenbank, die tatsächlich öffentlich erreichbar ist.

Container

Pro und höher. Eine Prüfung auf den veröffentlichten Port eines Containers antwortet für den Proxy davor. Ein Container in einer Absturzschleife hinter einer Restart-Policy ist jeweils ein paar Sekunden lang erreichbar, ein fehlschlagender HEALTHCHECK lässt den Port offen, und ein OOM-Kill mit anschließendem Neustart sieht aus wie eine einzelne langsame Anfrage. Die Docker-Engine weiß von allen dreien.

Zugriff auf die Engine-API ist Root auf diesem Host, deshalb sind der Endpunkt und seine Client-Zertifikate Zugangsdaten, und diese Art läuft nur von einer Sonde, die für personenbezogene Daten freigegeben ist. Einen Unix-Socket öffnet nur eine Sonde, die mit DOCKER_SOCKET_ENABLED=true gestartet wurde – das setzen Sie auf Ihrer eigenen privaten Sonde neben Ihrer eigenen Engine, und wir setzen es auf unseren nie; überall sonst enthält sich die Prüfung, statt Ihren Container als ausgefallen zu melden. Ein tcp://- oder https://-Endpunkt mit Client-Zertifikaten funktioniert von beiden aus.

Netzwerkverkehr

Business und höher. Eine Verfügbarkeitsprüfung sagt Ihnen, dass eine Leitung antwortet; sie kann nicht sagen, dass die Leitung ausgelastet ist, dass ein Backup-Job sie mittags flutet oder dass der Verkehr zu Ihrer Web-Schicht still auf null gefallen ist. Ihre Router und Switches zählen all das bereits und können es exportieren. Diese Arten sammeln diesen Export und machen daraus Raten, eine Aufschlüsselung nach Protokoll und die aktivsten Ports und Adressen.

Jeder Schwellwert ist optional – eine maximale Bitrate, eine minimale Bitrate, eine maximale Paketrate. Darüber oder darunter ist beeinträchtigt. Ohne Schwellwert zeichnet der Monitor den Verkehr auf und stellt ihn dar, ohne bei einem Wert zu alarmieren. Ein Exporter, der länger schweigt, als Sie erlauben, ist ausgefallen, und einer, der das falsche Protokoll sendet – sFlow an einen NetFlow-Monitor –, ist ausgefallen, mit einer Meldung, die genau das sagt.

Diese Arten laufen nur auf Ihrer eigenen privaten Sonde. Flow-Export ist UDP und trägt keine Authentifizierung: Ein Kollektor in unserem gemeinsamen Netz müsste der Absenderadresse vertrauen, und die kann jeder fälschen oder für sich beanspruchen. Auf einer Sonde in Ihrem Netz können sie nur Ihre eigenen Router erreichen. Außerdem bleiben Ihre Verkehrsdaten bei Ihnen – sie nennen die Adressen der Menschen in Ihrem Netz, deshalb fasst die Sonde sie dort zusammen, wo sie ankommen, und schickt uns nur die Raten und die Top-10-Tabellen. Starten Sie die Sonde mit FLOW_COLLECTOR_ENABLED=true, veröffentlichen Sie die UDP-Ports, richten Sie Ihre Router darauf und wählen Sie diese Sonde, wenn Sie den Monitor anlegen.

Dinge, die sich bei uns melden

Wie oft geprüft wird

Sie wählen ein Intervall; Ihr Tarif setzt die Untergrenze. Free prüft jede Minute, Starter alle 45 Sekunden, Pro alle 30, Business alle 15, Enterprise alle 5.

Vier Arten haben unabhängig vom Tarif ihre eigene Untergrenze, weil sich die Antwort nicht von Minute zu Minute ändert und häufigeres Fragen nur Rauschen und Last auf dem Server eines anderen wäre:

E-Mail-Authentifizierung — und tatsächlich E-Mails senden

Ein mail_posture-Monitor liest SPF, DKIM, DMARC, MTA-STS und TLS-RPT aus dem DNS und sagt Ihnen, was kaputt ist. Das findet einen verrotteten Eintrag und genau das nicht, worüber diese Einträge eine Vorhersage sind: eine Domain kann ein makelloses SPF veröffentlichen und von einem Server senden, den dieser Eintrag verleugnet, einen DKIM-Schlüssel veröffentlichen und mit einem rotierten signieren, oder ein Gateway dazwischen schreibt einen Header um und zerstört eine Signatur, die beim Verlassen gültig war.

Geben Sie dem Monitor ein Postfach — eine Adresse sowie SMTP- und IMAP-Zugangsdaten — und er misst, statt vorherzusagen. Stündlich übergibt er eine Nachricht an Ihren eigenen Postausgangsserver, adressiert an unseren Listener, der SPF und DKIM des tatsächlich Angekommenen prüft und dann ins Postfach antwortet, damit der nächste Durchlauf per IMAP bestätigen kann, dass Ihre Domain E-Mails auch empfängt. Beide Wege müssen gelingen. Eine Domain, die einwandfrei sendet und still nichts mehr annimmt, ist ein echter Ausfall — und einer, den jede reine Sendeprüfung als gesund meldet.

Zwei Dinge sollten Sie vorher wissen. Die Zugangsdaten werden unverschlüsselt gespeichert und an die Sonde übergeben, die die Prüfung ausführt — das gilt für die Konfiguration jedes Monitors, weil die Sonde die Anfrage stellt — deshalb läuft ein Monitor mit Postfach nur innerhalb der Europäischen Union und nie auf unseren Sonden anderswo. Nutzen Sie ein App-Passwort, wenn Ihr Anbieter eines anbietet. Und unsere Antwort wird aus dem Postfach gelöscht, sobald sie gelesen wurde, damit der Ordner nicht volläuft.

Ein Intervall ist nicht, wie schnell Sie von einem Ausfall erfahren

Das ist der Teil, der zweimal gelesen gehört. Eine einzelne fehlgeschlagene Prüfung eröffnet keinen Vorfall. Ein Monitor muss dreimal hintereinander fehlschlagen — das ist die Einstellung confirmations, und drei ist die Vorgabe —, bevor jemand benachrichtigt wird.

Es ist aber nicht das Dreifache des Intervalls. Schlägt eine Prüfung fehl, wird die nächste vorgezogen, statt das volle Intervall abzuwarten, sodass ein Fünf-Minuten-Monitor einen Ausfall deutlich unter fünfzehn Minuten bestätigt. Ein Ergebnis kann die nächste Prüfung immer nur früher machen, nie später.

Senken Sie confirmations, wenn Sie lieber früh und gelegentlich umsonst geweckt werden. Erhöhen Sie es für etwas, von dem Sie wissen, dass es flattert.

Prüfungen wechseln zwischen Standorten

Wir prüfen von mehreren Orten aus, einer pro Intervall, im Wechsel. Drei Aussichtspunkte bei einem Fünf-Minuten-Monitor heißt, dass jeder ihn alle fünfzehn Minuten sieht, während der Monitor weiterhin alle fünf geprüft wird.

Genau das macht die Bestätigung aussagekräftig: drei Fehlschläge hintereinander sind drei Fehlschläge von drei verschiedenen Orten, also ist eine Sonde, die Ihren Server schlicht nicht erreicht, harmlos — die nächste Region kommt durch und die Serie beginnt von vorn.

Ein Fehlschlag, während ein anderer Standort in Ordnung ist, ist beeinträchtigt und nicht ausgefallen. Ausgefallen soll heißen, dass Ihre Seite nicht erreichbar ist, und nicht, dass ein Aussichtspunkt sie nicht sieht. Es zählt trotzdem als Fehlschlag, und ein Vorfall wird trotzdem eröffnet, mit beeinträchtigter Schwere.

Eine Firewall ist kein Ausfall

Eine an einem Standort gesperrte Seite schlägt dort bei jeder Prüfung fehl und funktioniert überall sonst. Das als Ausfallzeit zu zählen würde Ihre Verfügbarkeitszahl zu einer Aussage über unser Routing machen statt über Ihren Dienst.

Deshalb wird eine Region, die einen Monitor nie erreicht hat, nach drei Fehlschlägen von ihm ausgeschlossen. Eine Region, die ihn früher erreicht hat und es nicht mehr tut, zählt dauerhaft weiter — denn von dort ist das ein echter Ausfall, und ihn zu verbergen wäre schlimmer.

Wenn sich die Welt um eine Seite herum geändert hat — eine staatliche Sperre, eine weggefallene Route, eine nachträglich eingebaute Geo-Sperre —, können Sie einen Monitor auf seiner Seite neu kalibrieren. Das verwirft die Historie jeder Region für diesen einen Monitor, sodass das aktuelle Verhalten die neue Grundlinie wird. Es gilt pro Monitor und bewusst nur auf Zuruf, weil Messung allein eine dauerhafte Sperre nicht von einem dauerhaften Ausfall unterscheiden kann.

Wo Prüfungen laufen und was wir dorthin schicken

Einige Aussichtspunkte liegen außerhalb des EWR. Eine Prüfung, deren Konfiguration personenbezogene Daten enthalten könnte — ein Anfrage-Header, ein Anfragetext —, läuft ausschließlich innerhalb davon. Das erzwingt der Scheduler und nicht eine Richtlinie, und es wird bei jedem Build gegen eine echte Datenbank getestet. snmp, smpp und die fünf Datenbankarten sind genauso eingegrenzt, weil bei beiden das Anmeldegeheimnis das Protokoll ist.

Ungeprüft ist kein Bestanden

Bei tls_audit hat jede Prüfung drei Ausgänge statt zwei: unterstützt, abgelehnt oder ungeprüft. Das OpenSSL 3 von Node kompiliert weder RC4 noch 3DES ein, diese beiden Familien können aus unserer Flotte also nie angeboten werden — und Schweigen unter diesen Überschriften läse sich als „wir haben nachgesehen, und sie sind aus“, was eine falsche Entwarnung bei genau den Befunden wäre, für die ein TLS-Audit geöffnet wird.

Abhängigkeiten

Sagen Sie einem Monitor, wovon er abhängt — eine Datenbank, ein Gateway, eine vorgelagerte API —, und wenn die Abhängigkeit ausfällt, werden die Dinge dahinter als Folge markiert, statt eigene Vorfälle zu eröffnen. Ein Vorfall statt vierzig, und die Seite nennt die Ursache statt der Symptome.

Wartungsfenster

Planen Sie ein Fenster, und solange es offen ist, alarmiert nichts jemanden. Nehmen Sie das für ein Deployment, von dem Sie wissen, dass es die Sache offline nimmt. Standardmäßig laufen die Prüfungen weiter und zeichnen weiter auf, diese Minuten zählen also wie alle anderen in die Verfügbarkeitszahl — das Fenster nimmt den Alarm weg, nicht die Historie. Schalten Sie „weiter prüfen“ ab, wird während des Fensters gar nicht geprüft, was in der Historie eine Lücke hinterlässt statt einer Delle. Ein Fenster kann sich täglich, wöchentlich oder monatlich wiederholen, und jede Wiederholung hält Alarme zurück, nicht nur die erste.

Pausieren

Ein pausierter Monitor wird nicht geprüft und zählt gegen nichts. Er behält seine Historie, Pausieren und Fortsetzen verliert die Aufzeichnung also nicht.