Definiți obiectul VPN înainte de a alege SNMP sau API

Trei decizii preced transportul: ce obiect descrie alerta, ce direcție și amploare acoperă și cât de proaspătă trebuie să fie citirea. SNMP, un API HTTPS și o sondă de aplicație pot raporta toate ceva despre un VPN și nu vor raporta același lucru. Schimbarea protocoalelor fără a rezolva aceste trei mută doar locul unde se adună confuzia. Obiectul și semnificația alertei sunt proiectarea; protocolul este livrarea.

Un tablou de bord care transformă patru observații diferite într-o singură pictogramă verde a luat deja acea decizie prost.

Ce ar trebui să însemne de fapt alerta?

Poate însemna că un partener nu se poate autentifica, că nu există nicio stare protejată a datelor, că o rută indică locul greșit sau că o aplicație nu își poate termina lucrul. Fiecare dintre acestea are propriul proprietar, propria primă verificare și propria rată de fals pozitive. Un partener care nu se poate autentifica este o problemă de identitate, o asociere de securitate lipsă este o problemă de stare a protocolului, o rută este o problemă de configurare, iar o defecțiune a aplicației poate să nu fie niciuna dintre ele. Decideți pentru care este alerta înainte de a alege un colector.

Scrieți-o ca o propoziție pe care inginerul de gardă poate acționa. Dacă propoziția are nevoie de două obiecte, sunt două alerte, nu una care este pe jumătate corectă.

Un tabel TCP descrie TCP

RFC 4022 specifică tcpConnectionTable, ale cărui rânduri descriu conexiuni TCP stabilite, indexate după tipul adresei, adresă și port la ambele capete. Rândurile dispar când conexiunea se închide, iar socketurile în ascultare apar într-un alt tabel. Rularea unui VPN pe aceeași mașină nu transformă un tabel TCP într-un inventar de asocieri de securitate IPsec. Poate descrie o sesiune de administrare, un flux de aplicație sau un tunel transportat prin TCP, iar rândul în sine nu vă va spune care.

Contoarele de interfață poartă aceeași ambiguitate la un nivel mai grosier: octeții de pe o interfață agregă fiecare partener și fiecare flux care o folosește.

Construiți un mic contract de observare

Pentru fiecare metrică, înregistrați obiectul sau câmpul API acceptat, dispozitivul și versiunea de software proprietare, identificatorul partenerului sau serviciului, direcția, momentul colectării și comportamentul de reîmprospătare așteptat. Apoi folosiți vizualizarea documentată a asocierilor sau sesiunilor gateway-ului pentru starea protocolului, tabelul de rutare pentru starea căii și o cerere îngustă permisă pentru starea aplicației. Un punct de administrare funcțional dovedește că punctul de administrare funcționează și nimic despre aplicația din spatele lui.

Dacă agentul instalat nu are obiectele necesare, alegeți o altă interfață doar pentru citire, acceptată explicit. Inventarea unui OID, citirea unui contor TCP generic ca contor de tuneluri sau așteptarea ca un API vechi de furnizor să supraviețuiască neschimbat într-un produs frate sunt toate fundături.

Datele învechite nu sunt o defecțiune a tunelului

Un timp de colectare expirat, o acreditare expirată sau o cale de API modificată produc telemetrie lipsă. Aceasta este o defecțiune de monitorizare și un incident diferit de un tunel care a căzut. Înregistrați care observație a devenit învechită și când, pentru ca operatorul să primească o primă verificare semnificativă în loc de o resetare a tunelului. Tratarea fiecărui timp expirat ca o întrerupere VPN îi învață pe oameni să le ignore pe amândouă.

Păstrați înguste și permisiunile de colectare. O interfață care poate schimba configurația sau șterge sesiuni poartă o frontieră de privilegii pe care un job de monitorizare nu ar trebui să o moștenească, iar un cont doar pentru citire este de obicei suficient.

Proiectarea utilă numește obiectul, semnificația și cerința de prospețime. Alegerea protocolului decurge din acestea, nu invers.