Definujte objekt VPN pred voľbou SNMP alebo API

Pred transportom stoja tri rozhodnutia: aký objekt upozornenie opisuje, ktorý smer a rozsah pokrýva a ako čerstvé má byť čítanie. SNMP, HTTPS API a aplikačná sonda môžu všetky hlásiť niečo o VPN a nebudú hlásiť to isté. Výmena protokolov bez vyriešenia týchto troch mení len to, kde sa zhromažďuje zmätok. Objekt a význam upozornenia sú návrh; protokol je doručenie.

Panel, ktorý premieňa štyri rôzne pozorovania na jednu zelenú ikonu, toto rozhodnutie už urobil zle.

Čo má upozornenie vlastne znamenať?

Môže znamenať, že partner sa nedokáže overiť, že neexistuje chránený stav údajov, že trasa vedie na nesprávne miesto alebo že aplikácia nedokáže dokončiť svoju prácu. Každé z toho má svojho vlastníka, svoju prvú kontrolu a svoju mieru falošných poplachov. Partner, ktorý sa nedokáže overiť, je problém identity, chýbajúca bezpečnostná asociácia je problém stavu protokolu, trasa je problém konfigurácie a zlyhanie aplikácie nemusí byť nič z toho. Rozhodnite, pre ktoré z nich je upozornenie, skôr než vyberiete zberač.

Napíšte ho ako vetu, podľa ktorej môže pohotovostný inžinier konať. Ak veta potrebuje dva objekty, sú to dve upozornenia, nie jedno napoly správne.

Tabuľka TCP opisuje TCP

RFC 4022 špecifikuje tcpConnectionTable, ktorého riadky opisujú nadviazané TCP spojenia, kľúčované podľa typu adresy, adresy a portu na oboch koncoch. Riadky miznú, keď sa spojenie uzavrie, a počúvajúce sockety sa objavujú v inej tabuľke. Prevádzka VPN na tom istom stroji nepremení tabuľku TCP na inventár bezpečnostných asociácií IPsec. Môže opisovať riadiacu reláciu, tok aplikácie alebo tunel prenášaný cez TCP a samotný riadok vám nepovie, ktorý.

Počítadlá rozhraní nesú rovnakú dvojznačnosť na hrubšej úrovni: bajty na rozhraní agregujú každého partnera a každý tok, ktorý ho používa.

Postavte malý pozorovací kontrakt

Pre každú metriku zaznamenajte podporovaný objekt alebo pole API, vlastnícke zariadenie a verziu softvéru, identifikátor partnera alebo služby, smer, čas zberu a očakávané správanie obnovy. Potom použite dokumentovaný pohľad brány na asociácie alebo relácie pre stav protokolu, smerovaciu tabuľku pre stav cesty a úzku povolenú požiadavku pre stav aplikácie. Fungujúci koncový bod správy dokazuje, že koncový bod správy funguje, a nič o aplikácii za ním.

Ak nainštalovaný agent nemá požadované objekty, vyberte iné výslovne podporované rozhranie iba na čítanie. Vymýšľanie OID, čítanie všeobecného počtu TCP ako počtu tunelov alebo očakávanie, že staré API dodávateľa prežije bez zmeny v sesterskom produkte, sú všetky slepé uličky.

Zastarané údaje nie sú zlyhanie tunela

Časový limit zberu, vypršaná akreditácia alebo zmenená cesta API vytvárajú chýbajúcu telemetriu. To je zlyhanie monitorovania a iný incident ako tunel, ktorý spadol. Zaznamenajte, ktoré pozorovanie zostarlo a kedy, aby operátor dostal zmysluplnú prvú kontrolu namiesto resetu tunela. Považovať každý časový limit za výpadok VPN učí ľudí ignorovať oboje.

Držte úzke aj oprávnenia na zber. Rozhranie, ktoré môže meniť konfiguráciu alebo mazať relácie, nesie hranicu oprávnení, ktorú by monitorovacia úloha nemala dediť, a účet iba na čítanie zvyčajne stačí.

Užitočný návrh pomenúva objekt, význam a požiadavku na čerstvosť. Voľba protokolu z toho vyplýva, nie naopak.