Definieer het VPN-object voordat u SNMP of API kiest

Drie beslissingen gaan aan het transport vooraf: welk object de melding beschrijft, welke richting en reikwijdte zij dekt, en hoe vers de meting moet zijn. SNMP, een HTTPS-API en een applicatieprobe kunnen allemaal iets over een VPN melden, en zij melden niet hetzelfde. Van protocol wisselen zonder die drie te beslechten verandert alleen waar de verwarring wordt verzameld. Het object en de betekenis van de melding zijn het ontwerp; het protocol is de bezorging.

Een dashboard dat vier verschillende waarnemingen in één groen pictogram verandert, heeft die beslissing al slecht genomen.

Wat moet de melding eigenlijk betekenen?

Zij kan betekenen dat een peer zich niet kan authenticeren, dat er geen beveiligde datatoestand bestaat, dat een route naar de verkeerde plek wijst, of dat een applicatie haar werk niet kan afmaken. Elk daarvan heeft een eigen eigenaar, een eigen eerste controle en een eigen fout-positieve ratio. Een peer die zich niet kan authenticeren is een identiteitsprobleem, een ontbrekende beveiligingsassociatie is een protocoltoestandsprobleem, een route is een configuratieprobleem, en een applicatiefout kan geen van die zijn. Bepaal waarvoor de melding is voordat u een collector kiest.

Schrijf haar als een zin waarop de dienstdoende ingenieur kan handelen. Als de zin twee objecten nodig heeft, zijn het twee meldingen, niet één die half klopt.

Een TCP-tabel beschrijft TCP

RFC 4022 specificeert tcpConnectionTable, waarvan de rijen gevestigde TCP-verbindingen beschrijven, gesleuteld op adrestype, adres en poort aan beide uiteinden. Rijen verdwijnen wanneer de verbinding sluit, en luisterende sockets verschijnen in een andere tabel. Een VPN op dezelfde machine draaien maakt van een TCP-tabel geen inventaris van IPsec-beveiligingsassociaties. Zij kan een beheersessie, een applicatiestroom of een tunnel over TCP beschrijven, en de rij zelf vertelt u niet welke.

Interfacetellers dragen dezelfde dubbelzinnigheid op een grover niveau: bytes op een interface bundelen elke peer en elke stroom die ervan gebruikmaakt.

Bouw een klein observatiecontract

Noteer voor elke metriek het ondersteunde object of API-veld, het eigenaarsapparaat en de softwareversie, de peer- of service-identificatie, de richting, het verzameltijdstip en het verwachte verversingsgedrag. Gebruik dan de gedocumenteerde associatie- of sessieweergave van de gateway voor de protocoltoestand, de routingtabel voor de padtoestand en een smal toegestaan verzoek voor de applicatietoestand. Een werkend beheer-eindpunt bewijst dat het beheer-eindpunt werkt, en niets over de applicatie erachter.

Als de geïnstalleerde agent de vereiste objecten mist, kies dan een andere expliciet ondersteunde alleen-lezen interface. Een OID verzinnen, een algemene TCP-telling als tunneltelling lezen of verwachten dat een oude leveranciers-API ongewijzigd overleeft in een zusterproduct, zijn allemaal doodlopende wegen.

Verouderde gegevens zijn geen tunnelfout

Een verzameltime-out, een verlopen referentie of een gewijzigd API-pad levert ontbrekende telemetrie op. Dat is een monitoringsfout en een ander incident dan een tunnel die wegviel. Noteer welke waarneming verouderde en wanneer, zodat de operator een zinvolle eerste controle krijgt in plaats van een tunnelreset. Elke time-out als VPN-storing behandelen leert mensen beide te negeren.

Houd ook de verzamelrechten nauw. Een interface die configuratie kan wijzigen of sessies kan wissen, draagt een privilegesgrens die een monitoringtaak niet zou moeten erven, en een alleen-lezen account is meestal voldoende.

Het nuttige ontwerp benoemt het object, de betekenis en de versheidseis. De protocolkeuze volgt daaruit, niet andersom.