Než zvolíte SNMP nebo API, definujte objekt VPN

Před přenosem stojí tři rozhodnutí: jaký objekt alarm popisuje, který směr a rozsah pokrývá a jak čerstvé má být čtení. SNMP, HTTPS API a aplikační sonda mohou všechny hlásit něco o VPN a nebudou hlásit totéž. Výměna protokolů bez vyřešení těchto tří věcí mění jen to, kde se zmatek shromažďuje. Objekt a význam alarmu jsou návrh; protokol je doručení.

Panel, který převádí čtyři různá pozorování na jednu zelenou ikonu, toto rozhodnutí už udělal špatně.

Co má alarm vlastně znamenat?

Může znamenat, že peer se nemůže ověřit, že neexistuje chráněný stav dat, že trasa vede někam špatně nebo že aplikace nemůže dokončit svou práci. Každé z toho má svého vlastníka, svou první kontrolu a svou míru falešných poplachů. Peer, který se nemůže ověřit, je problém identity, chybějící bezpečnostní asociace je problém stavu protokolu, trasa je problém konfigurace a selhání aplikace nemusí být nic z toho. Rozhodněte, pro které z nich alarm je, než zvolíte kolektor.

Napište ho jako větu, podle níž může pohotovostní inženýr jednat. Pokud věta potřebuje dva objekty, jsou to dva alarmy, ne jeden napůl správný.

Tabulka TCP popisuje TCP

RFC 4022 specifikuje tcpConnectionTable, jehož řádky popisují navázaná TCP spojení, klíčovaná typem adresy, adresou a portem na obou koncích. Řádky mizí, když se spojení uzavře, a naslouchající sockety se objevují v jiné tabulce. Provoz VPN na stejném stroji nepromění tabulku TCP v inventář bezpečnostních asociací IPsec. Může popisovat řídicí relaci, tok aplikace nebo tunel přenášený přes TCP a řádek sám vám neřekne který.

Počítadla rozhraní nesou stejnou dvojznačnost na hrubší úrovni: bajty na rozhraní agregují každého peera a každý tok, který ho používá.

Postavte malý pozorovací kontrakt

Pro každou metriku zaznamenejte podporovaný objekt nebo pole API, vlastnící zařízení a verzi softwaru, identifikátor peera nebo služby, směr, čas sběru a očekávané chování obnovy. Poté použijte dokumentovaný pohled brány na asociace nebo relace pro stav protokolu, směrovací tabulku pro stav cesty a úzký povolený požadavek pro stav aplikace. Fungující koncový bod správy dokazuje, že koncový bod správy funguje, a nic o aplikaci za ním.

Pokud instalovaný agent postrádá požadované objekty, zvolte jiné výslovně podporované rozhraní pouze pro čtení. Vymýšlet OID, číst obecný počet TCP jako počet tunelů nebo očekávat, že staré API dodavatele přežije beze změny v sourozeneckém produktu, jsou všechny slepé uličky.

Zastaralá data nejsou selhání tunelu

Časový limit sběru, vypršelý akreditiv nebo změněná cesta API produkují chybějící telemetrii. To je selhání monitorování a jiný incident než tunel, který spadl. Zaznamenejte, které pozorování zastaralo a kdy, aby operátor dostal smysluplnou první kontrolu místo resetu tunelu. Považovat každý časový limit za výpadek VPN učí lidi ignorovat obojí.

Držte také oprávnění ke sběru úzká. Rozhraní, které může měnit konfiguraci nebo mazat relace, nese hranici oprávnění, kterou by monitorovací úloha neměla dědit, a účet pouze pro čtení obvykle stačí.

Užitečný návrh pojmenovává objekt, význam a požadavek na čerstvost. Volba protokolu z toho vyplývá, ne naopak.