Definiu l’objecte VPN abans de triar SNMP o una API

Tres decisions vénen abans del transport: quin objecte descriu l’alerta, quina direcció i abast cobreix i com de fresca ha de ser la lectura. SNMP, una API HTTPS i una sonda d’aplicació poden informar d’alguna cosa sobre una VPN, i no informaran del mateix. Canviar de protocol sense resoldre aquestes tres només canvia on s’acumula la confusió. L’objecte i el significat de l’alerta són el disseny; el protocol és el lliurament.

Un quadre de comandament que converteix quatre observacions diferents en una sola icona verda ja ha pres aquesta decisió malament.

Què hauria de significar realment l’alerta?

Pot significar que un parell no pot autenticar-se, que no existeix cap estat de dades protegit, que una ruta apunta a un lloc equivocat o que una aplicació no pot acabar la seva feina. Cadascun d’aquests té el seu propi propietari, la seva primera comprovació i la seva pròpia taxa de falsos positius. Un parell que no pot autenticar-se és un problema d’identitat, una associació de seguretat absent és un problema d’estat de protocol, una ruta és un problema de configuració, i una fallada d’aplicació pot no ser cap d’aquests. Decidiu per a quin és l’alerta abans de triar un col·lector.

Escriviu-la com una frase sobre la qual l’enginyer de guàrdia pugui actuar. Si la frase necessita dos objectes, són dues alertes, no una que és mig correcta.

Una taula TCP descriu TCP

RFC 4022 especifica tcpConnectionTable, les files del qual descriuen connexions TCP establertes, amb clau per tipus d’adreça, adreça i port als dos extrems. Les files desapareixen quan es tanca la connexió, i els sockets d’escolta apareixen en una altra taula. Executar una VPN a la mateixa màquina no converteix una taula TCP en un inventari d’associacions de seguretat IPsec. Pot descriure una sessió de gestió, un flux d’aplicació o un túnel portat sobre TCP, i la fila mateixa no us dirà quin.

Els comptadors d’interfície porten la mateixa ambigüitat a un nivell més gruixut: els bytes d’una interfície agreguen cada parell i cada flux que la utilitza.

Construïu un contracte d’observació petit

Per a cada mètrica, registreu l’objecte o camp d’API suportat, el dispositiu i la versió de programari propietaris, l’identificador de parell o servei, la direcció, el moment de recollida i el comportament d’actualització esperat. Després utilitzeu la vista documentada d’associacions o sessions de la passarel·la per a l’estat del protocol, la taula d’encaminament per a l’estat del camí i una petició estreta permesa per a l’estat de l’aplicació. Un punt de gestió que funciona demostra que el punt de gestió funciona i res sobre l’aplicació que hi ha darrere.

Si l’agent instal·lat no té els objectes necessaris, trieu una altra interfície de només lectura explícitament suportada. Inventar un OID, llegir un recompte TCP genèric com a recompte de túnels o esperar que una API antiga de proveïdor sobrevisqui sense canvis en un producte germà són tots carrers sense sortida.

Les dades obsoletes no són una fallada del túnel

Un temps d’espera de recollida, una credencial caducada o un camí d’API canviat produeixen telemetria absent. Això és una fallada de monitoratge i un incident diferent d’un túnel que ha caigut. Registreu quina observació ha quedat obsoleta i quan, perquè l’operador rebi una primera comprovació significativa en lloc d’un reinici del túnel. Tractar cada temps d’espera com una caiguda de VPN ensenya la gent a ignorar tots dos.

Manteniu també estrets els permisos de recollida. Una interfície que pot canviar la configuració o netejar sessions porta una frontera de privilegis que una tasca de monitoratge no hauria d’heretar, i un compte de només lectura sol ser suficient.

El disseny útil anomena l’objecte, el significat i el requisit de frescor. L’elecció de protocol se’n deriva, no a l’inrevés.