Definiera VPN-objektet innan du väljer SNMP eller API

Tre beslut kommer före transporten: vilket objekt larmet beskriver, vilken riktning och omfattning det täcker, och hur färsk avläsningen måste vara. SNMP, ett HTTPS-API och en applikationsprob kan alla rapportera något om en VPN, och de rapporterar inte samma sak. Att byta protokoll utan att avgöra dessa tre ändrar bara var förvirringen samlas. Objektet och larmets betydelse är designen; protokollet är leveransen.

En instrumentpanel som förvandlar fyra olika observationer till en enda grön ikon har redan fattat det beslutet dåligt.

Vad ska larmet egentligen betyda?

Det kan betyda att en peer inte kan autentisera sig, att ingen skyddad datatillstånd finns, att en rutt pekar på fel ställe, eller att en applikation inte kan slutföra sitt arbete. Var och en av dessa har sin egen ägare, sin egen första kontroll och sin egen falsk-positiva frekvens. En peer som inte kan autentisera sig är ett identitetsproblem, en saknad säkerhetsassociation är ett protokolltillståndsproblem, en rutt är ett konfigurationsproblem, och ett applikationsfel kan vara inget av dem. Bestäm vilken larmet gäller innan du väljer en insamlare.

Skriv det som en mening som jourhavande ingenjör kan agera på. Om meningen behöver två objekt är det två larm, inte ett som är halvt rätt.

En TCP-tabell beskriver TCP

RFC 4022 specificerar tcpConnectionTable, vars rader beskriver etablerade TCP-anslutningar, nycklade på adresstyp, adress och port i båda ändar. Raderna försvinner när anslutningen stängs, och lyssnande sockets dyker upp i en annan tabell. Att köra en VPN på samma maskin gör inte en TCP-tabell till en inventering av IPsec-säkerhetsassociationer. Den kan beskriva en administrationssession, ett applikationsflöde eller en tunnel som bärs över TCP, och raden själv berättar inte vilken.

Gränssnittsräknare bär samma tvetydighet på en grövre nivå: byte på ett gränssnitt samlar varje peer och varje flöde som använder det.

Bygg ett litet observationskontrakt

För varje mätvärde, registrera det stödda objektet eller API-fältet, den ägande enheten och programvaruversionen, peer- eller tjänsteidentifieraren, riktningen, insamlingstiden och det förväntade uppdateringsbeteendet. Använd sedan gatewayens dokumenterade associations- eller sessionsvy för protokolltillstånd, routingtabellen för sökvägstillstånd och en smal tillåten begäran för applikationstillstånd. En fungerande hanteringsändpunkt bevisar att hanteringsändpunkten fungerar, och ingenting om applikationen bakom den.

Om den installerade agenten saknar de nödvändiga objekten, välj ett annat uttryckligen stött skrivskyddat gränssnitt. Att hitta på en OID, läsa ett allmänt TCP-antal som ett tunnelantal eller förvänta sig att ett gammalt leverantörs-API överlever oförändrat i en systerprodukt är alla återvändsgränder.

Föråldrade data är inte ett tunnelfel

En insamlingstimeout, en utgången autentiseringsuppgift eller en ändrad API-sökväg ger saknad telemetri. Det är ett övervakningsfel och en annan incident än en tunnel som föll. Registrera vilken observation som blev föråldrad och när, så att operatören får en meningsfull första kontroll i stället för en tunnelåterställning. Att behandla varje timeout som ett VPN-avbrott lär människor att ignorera båda.

Håll också insamlingsbehörigheterna snäva. Ett gränssnitt som kan ändra konfigurationen eller rensa sessioner bär en privilegiegäns som ett övervakningsjobb inte bör ärva, och ett skrivskyddat konto räcker oftast.

Den användbara designen namnger objektet, betydelsen och färskhetskravet. Protokollvalet följer av dessa, inte tvärtom.