Határozza meg a VPN-objektumot, mielőtt SNMP-t vagy API-t választ

A szállítás előtt három döntés áll: milyen objektumot ír le a riasztás, milyen irányt és hatókört fed le, és mennyire frissnek kell lennie az olvasásnak. Az SNMP, egy HTTPS API és egy alkalmazáspróba mind jelenthet valamit egy VPN-ről, és nem ugyanazt fogják jelenteni. A protokollok cseréje e három tisztázása nélkül csak azt változtatja meg, hol gyűlik a zavar. Az objektum és a riasztás jelentése a tervezés; a protokoll a kézbesítés.

Egy irányítópult, amely négy különböző megfigyelést egyetlen zöld ikonná alakít, már rosszul hozta meg ezt a döntést.

Mit kellene a riasztásnak valójában jelentenie?

Jelentheti, hogy egy partner nem tud hitelesíteni, hogy nincs védett adatállapot, hogy egy útvonal rossz helyre mutat, vagy hogy egy alkalmazás nem tudja befejezni a munkáját. Mindegyiknek megvan a saját tulajdonosa, a saját első ellenőrzése és a saját téves-pozitív aránya. Az a partner, amelyik nem tud hitelesíteni, identitásprobléma, a hiányzó biztonsági társítás protokollállapot-probléma, az útvonal konfigurációs probléma, és egy alkalmazáshiba egyik sem lehet. Döntse el, melyikhez szól a riasztás, mielőtt gyűjtőt választ.

Írja le olyan mondatként, amelyre az ügyeletes mérnök cselekedni tud. Ha a mondathoz két objektum kell, az két riasztás, nem egy, amely félig helyes.

A TCP-tábla a TCP-t írja le

Az RFC 4022 meghatározza a tcpConnectionTable-t, amelynek sorai a létrejött TCP-kapcsolatokat írják le, kulcsként a cím típusa, a cím és a port mindkét végponton. A sorok eltűnnek, amikor a kapcsolat bezárul, és a figyelő socketek egy másik táblában jelennek meg. Egy VPN futtatása ugyanazon a gépen nem alakítja a TCP-táblát IPsec biztonsági társítások leltárává. Leírhat egy kezelési munkamenetet, egy alkalmazásfolyamot vagy egy TCP fölött szállított alagutat, és maga a sor nem fogja megmondani, melyiket.

Az interfész-számlálók ugyanezt a kétértelműséget hordozzák durvább szinten: egy interfész bájtjai minden partnert és minden folyamot összevonnak, amely használja.

Építsen egy kis megfigyelési szerződést

Minden metrikához rögzítse a támogatott objektumot vagy API-mezőt, a tulajdonos eszközt és szoftververziót, a partner- vagy szolgáltatásazonosítót, az irányt, a gyűjtés idejét és a várt frissítési viselkedést. Ezután használja az átjáró dokumentált társítás- vagy munkamenet-nézetét a protokollállapothoz, az útválasztási táblát az útvonal állapotához, és egy szűk engedélyezett kérést az alkalmazásállapothoz. Egy működő kezelési végpont bizonyítja, hogy a kezelési végpont működik, és semmit a mögötte lévő alkalmazásról.

Ha a telepített ügynökből hiányoznak a szükséges objektumok, válasszon egy másik, kifejezetten támogatott csak olvasható interfészt. OID kitalálása, egy általános TCP-szám alagútszámként való olvasása vagy annak várása, hogy egy régi szállítói API változatlanul túlél egy testvértermékben, mind zsákutcák.

Az elavult adat nem alagúthiba

Egy gyűjtési időtúllépés, egy lejárt hitelesítő adat vagy egy megváltozott API-útvonal hiányzó telemetriát eredményez. Ez monitorozási hiba, és más incidens, mint egy leesett alagút. Rögzítse, melyik megfigyelés avult el és mikor, hogy az operátor értelmes első ellenőrzést kapjon az alagút visszaállítása helyett. Ha minden időtúllépést VPN-kiesésként kezelünk, az emberek mindkettőt figyelmen kívül hagyják.

A gyűjtési engedélyeket is tartsa szűken. Egy interfész, amely konfigurációt változtathat vagy munkameneteket törölhet, olyan jogosultsági határt hordoz, amelyet egy monitorozási feladatnak nem kellene örökölnie, és egy csak olvasható fiók általában elegendő.

A hasznos tervezés megnevezi az objektumot, a jelentést és a frissességi követelményt. A protokollválasztás ezekből következik, nem pedig fordítva.