Definite l’oggetto VPN prima di scegliere SNMP o un’API

Tre decisioni precedono il trasporto: quale oggetto descrive l’avviso, quale direzione e ambito copre e quanto fresca deve essere la lettura. SNMP, un’API HTTPS e una sonda applicativa possono tutti segnalare qualcosa su una VPN, e non segnaleranno la stessa cosa. Cambiare protocollo senza risolvere quei tre punti sposta solo il luogo in cui si accumula la confusione. L’oggetto e il significato dell’avviso sono il progetto; il protocollo è la consegna.

Un cruscotto che trasforma quattro osservazioni diverse in un’unica icona verde ha già preso male quella decisione.

Che cosa dovrebbe significare davvero l’avviso?

Potrebbe significare che un peer non riesce ad autenticarsi, che non esiste alcuno stato dei dati protetto, che una rotta punta nel posto sbagliato o che un’applicazione non riesce a concludere il proprio lavoro. Ognuno di questi ha un proprio responsabile, un proprio primo controllo e un proprio tasso di falsi positivi. Un peer che non riesce ad autenticarsi è un problema di identità, un’associazione di sicurezza mancante è un problema di stato del protocollo, una rotta è un problema di configurazione, e un guasto applicativo potrebbe non essere nessuno di questi. Decidete a quale serve l’avviso prima di scegliere un collector.

Scrivetelo come una frase su cui l’ingegnere di turno possa agire. Se la frase richiede due oggetti, sono due avvisi, non uno mezzo giusto.

Una tabella TCP descrive TCP

La RFC 4022 specifica tcpConnectionTable, le cui righe descrivono connessioni TCP stabilite, indicizzate per tipo di indirizzo, indirizzo e porta alle due estremità. Le righe scompaiono quando la connessione si chiude, e i socket in ascolto compaiono in un’altra tabella. Eseguire una VPN sulla stessa macchina non trasforma una tabella TCP in un inventario di associazioni di sicurezza IPsec. Può descrivere una sessione di gestione, un flusso applicativo o un tunnel trasportato su TCP, e la riga stessa non vi dirà quale.

I contatori di interfaccia portano la stessa ambiguità a un livello più grossolano: i byte su un’interfaccia aggregano ogni peer e ogni flusso che la usa.

Costruite un piccolo contratto di osservazione

Per ogni metrica, registrate l’oggetto o il campo API supportato, il dispositivo e la versione software proprietari, l’identificatore del peer o del servizio, la direzione, il momento della raccolta e il comportamento di aggiornamento atteso. Poi usate la vista documentata delle associazioni o sessioni del gateway per lo stato del protocollo, la tabella di routing per lo stato del percorso e una richiesta ristretta consentita per lo stato dell’applicazione. Un endpoint di gestione funzionante dimostra che l’endpoint di gestione funziona, e nulla sull’applicazione che sta dietro.

Se l’agente installato non dispone degli oggetti richiesti, scegliete un’altra interfaccia in sola lettura esplicitamente supportata. Inventare un OID, leggere un conteggio TCP generico come conteggio di tunnel o aspettarsi che una vecchia API del fornitore sopravviva invariata in un prodotto gemello sono tutti vicoli ciechi.

I dati obsoleti non sono un guasto del tunnel

Un timeout di raccolta, una credenziale scaduta o un percorso API modificato producono telemetria mancante. È un guasto di monitoraggio e un incidente diverso da un tunnel caduto. Registrate quale osservazione è diventata obsoleta e quando, così l’operatore riceve un primo controllo significativo invece di un riavvio del tunnel. Trattare ogni timeout come un’interruzione VPN insegna alle persone a ignorare entrambi.

Tenete strette anche le autorizzazioni di raccolta. Un’interfaccia che può cambiare la configurazione o cancellare sessioni porta un confine di privilegi che un’attività di monitoraggio non dovrebbe ereditare, e un account in sola lettura di solito è sufficiente.

Il progetto utile nomina l’oggetto, il significato e il requisito di freschezza. La scelta del protocollo ne deriva, non il contrario.