Definieren Sie das VPN-Objekt, bevor Sie SNMP oder API wählen

Vor dem Transport stehen drei Entscheidungen: welches Objekt der Alarm beschreibt, welche Richtung und welchen Umfang er abdeckt und wie frisch die Messung sein muss. SNMP, eine HTTPS-API und eine Anwendungssonde können alle etwas über ein VPN melden, und sie werden nicht dasselbe melden. Protokolle zu wechseln, ohne diese drei zu klären, ändert nur, wo die Verwirrung gesammelt wird. Das Objekt und die Bedeutung des Alarms sind das Design; das Protokoll ist die Zustellung.

Ein Dashboard, das vier verschiedene Beobachtungen in ein grünes Symbol verwandelt, hat diese Entscheidung bereits schlecht getroffen.

Was soll der Alarm eigentlich bedeuten?

Er kann bedeuten, dass ein Peer sich nicht authentifizieren kann, dass kein geschützter Datenzustand existiert, dass eine Route an die falsche Stelle zeigt oder dass eine Anwendung ihre Arbeit nicht beenden kann. Jedes davon hat seinen eigenen Verantwortlichen, seine eigene erste Prüfung und seine eigene Falsch-Positiv-Rate. Ein Peer, der sich nicht authentifizieren kann, ist ein Identitätsproblem, eine fehlende Security Association ein Protokollzustandsproblem, eine Route ein Konfigurationsproblem, und ein Anwendungsfehler kann keines davon sein. Entscheiden Sie, wofür der Alarm gilt, bevor Sie einen Collector wählen.

Schreiben Sie ihn als Satz, auf den der Bereitschaftsingenieur reagieren kann. Wenn der Satz zwei Objekte braucht, sind das zwei Alarme, nicht einer, der halb richtig ist.

Eine TCP-Tabelle beschreibt TCP

RFC 4022 spezifiziert tcpConnectionTable, dessen Zeilen etablierte TCP-Verbindungen beschreiben, mit Schlüssel nach Adresstyp, Adresse und Port an beiden Enden. Zeilen verschwinden, wenn die Verbindung schließt, und lauschende Sockets erscheinen in einer anderen Tabelle. Ein VPN auf derselben Maschine macht aus einer TCP-Tabelle kein Inventar von IPsec-Security-Assoziationen. Sie kann eine Managementsitzung, einen Anwendungsfluss oder einen über TCP transportierten Tunnel beschreiben, und die Zeile selbst sagt Ihnen nicht, welchen.

Schnittstellenzähler tragen dieselbe Mehrdeutigkeit auf gröberer Ebene: Bytes an einer Schnittstelle fassen jeden Peer und jeden Fluss zusammen, der sie nutzt.

Bauen Sie einen kleinen Beobachtungsvertrag

Erfassen Sie für jede Metrik das unterstützte Objekt oder API-Feld, das besitzende Gerät und die Softwareversion, die Peer- oder Dienstkennung, die Richtung, den Erfassungszeitpunkt und das erwartete Aktualisierungsverhalten. Verwenden Sie dann die dokumentierte Assoziations- oder Sitzungsansicht des Gateways für den Protokollzustand, die Routing-Tabelle für den Pfadzustand und eine eng begrenzte erlaubte Anfrage für den Anwendungszustand. Ein funktionierender Management-Endpunkt beweist, dass der Management-Endpunkt funktioniert, und nichts über die Anwendung dahinter.

Wenn dem installierten Agenten die erforderlichen Objekte fehlen, wählen Sie eine andere ausdrücklich unterstützte Nur-Lese-Schnittstelle. Eine OID zu erfinden, einen allgemeinen TCP-Zähler als Tunnelzähler zu lesen oder zu erwarten, dass eine alte Hersteller-API in einem Schwesterprodukt unverändert überlebt, sind alles Sackgassen.

Veraltete Daten sind kein Tunnelausfall

Ein Erfassungs-Timeout, ein abgelaufenes Credential oder ein geänderter API-Pfad erzeugen fehlende Telemetrie. Das ist ein Überwachungsfehler und ein anderer Vorfall als ein Tunnel, der ausgefallen ist. Halten Sie fest, welche Beobachtung wann veraltet ist, damit der Betreiber eine aussagekräftige erste Prüfung erhält statt eines Tunnel-Resets. Jeden Timeout als VPN-Ausfall zu behandeln, bringt Menschen dazu, beides zu ignorieren.

Halten Sie auch die Erfassungsberechtigungen eng. Eine Schnittstelle, die Konfiguration ändern oder Sitzungen löschen kann, trägt eine Privilegiengrenze, die ein Überwachungsjob nicht erben sollte, und ein Nur-Lese-Konto ist normalerweise ausreichend.

Das nützliche Design benennt das Objekt, die Bedeutung und die Frischeanforderung. Die Protokollwahl folgt daraus, nicht umgekehrt.