Definer VPN-objektet, før du vælger SNMP eller API

Tre beslutninger kommer før transporten: hvilket objekt alarmen beskriver, hvilken retning og rækkevidde den dækker, og hvor frisk aflæsningen skal være. SNMP, en HTTPS-API og en applikationsprobe kan alle rapportere noget om en VPN, og de rapporterer ikke det samme. At skifte protokol uden at afklare de tre ændrer kun, hvor forvirringen samles. Objektet og alarmens betydning er designet; protokollen er leveringen.

Et dashboard, der forvandler fire forskellige observationer til ét grønt ikon, har allerede truffet den beslutning dårligt.

Hvad skal alarmen egentlig betyde?

Det kan betyde, at en peer ikke kan godkende, at der ikke findes nogen beskyttet datatilstand, at en rute peger det forkerte sted hen, eller at en applikation ikke kan fuldføre sit arbejde. Hver af disse har sin egen ejer, sin egen første kontrol og sin egen falsk-positive rate. En peer, der ikke kan godkende, er et identitetsproblem, en manglende sikkerhedsassociation er et protokolltilstandsproblem, en rute er et konfigurationsproblem, og en applikationsfejl er måske ingen af dem. Beslut, hvilken alarmen gælder, før du vælger en collector.

Skriv den som en sætning, som den vagthavende ingeniør kan handle på. Hvis sætningen kræver to objekter, er det to alarmer, ikke én der er halvt rigtig.

En TCP-tabel beskriver TCP

RFC 4022 specificerer tcpConnectionTable, hvis rækker beskriver etablerede TCP-forbindelser, nøglet på adressetype, adresse og port i begge ender. Rækker forsvinder, når forbindelsen lukkes, og lyttende sockets vises i en anden tabel. At køre en VPN på samme maskine gør ikke en TCP-tabel til en oversigt over IPsec-sikkerhedsassociationer. Den kan beskrive en administrationssession, en applikationsstrøm eller en tunnel båret over TCP, og rækken selv fortæller dig ikke hvilken.

Interface-tællere bærer den samme tvetydighed på et grovere niveau: bytes på et interface samler hver peer og hver strøm, der bruger det.

Byg en lille observationskontrakt

For hver metrik skal du registrere det understøttede objekt eller API-felt, den ejende enhed og softwareversion, peer- eller tjenesteidentifikatoren, retningen, indsamlingstiden og den forventede opdateringsadfærd. Brug derefter gatewayens dokumenterede associations- eller sessionsvisning til protokolltilstand, routingtabellen til stitilstand og en smal tilladt anmodning til applikationstilstand. Et fungerende administrationsendepunkt beviser, at administrationsendepunktet virker, og intet om applikationen bag det.

Hvis den installerede agent mangler de krævede objekter, skal du vælge en anden eksplicit understøttet skrivebeskyttet grænseflade. At opfinde en OID, læse et generisk TCP-tal som et tunneltal eller forvente, at en gammel leverandør-API overlever uændret i et søsterprodukt, er alle blindgyder.

Forældede data er ikke en tunnelfejl

En indsamlingstimeout, en udløbet legitimationsoplysning eller en ændret API-sti giver manglende telemetri. Det er en overvågningsfejl og en anden hændelse end en tunnel, der faldt. Registrer, hvilken observation der blev forældet og hvornår, så operatøren får en meningsfuld første kontrol i stedet for en tunnelnulstilling. At behandle hver timeout som et VPN-udfald lærer folk at ignorere begge.

Hold også indsamlingstilladelser snævre. En grænseflade, der kan ændre konfiguration eller rydde sessioner, bærer en privilegrænse, som et overvågningsjob ikke bør arve, og en skrivebeskyttet konto er normalt tilstrækkelig.

Det nyttige design navngiver objektet, betydningen og friskhedskravet. Protokolvalget følger af disse, ikke omvendt.