Defina o obxecto VPN antes de escoller SNMP ou unha API

Tres decisións preceden o transporte: que obxecto describe a alerta, que dirección e alcance cobre e con que frescura debe lerse. SNMP, unha API HTTPS e unha sonda de aplicación poden informar de algo sobre unha VPN, e non informarán do mesmo. Cambiar de protocolo sen resolver esas tres só cambia onde se acumula a confusión. O obxecto e o significado da alerta son o deseño; o protocolo é a entrega.

Un panel que converte catro observacións distintas nun único icono verde xa tomou esa decisión mal.

Que debería significar realmente a alerta?

Pode significar que un par non pode autenticarse, que non existe ningún estado de datos protexido, que unha ruta apunta ao lugar equivocado ou que unha aplicación non pode rematar o seu traballo. Cada un deses ten o seu propio dono, a súa propia primeira comprobación e a súa propia taxa de falsos positivos. Un par que non pode autenticarse é un problema de identidade, unha asociación de seguridade ausente é un problema de estado de protocolo, unha ruta é un problema de configuración e un fallo de aplicación pode non ser ningún deses. Decida para cal é a alerta antes de escoller un colector.

Escriba como unha frase sobre a que o enxeñeiro de garda poida actuar. Se a frase precisa dous obxectos, son dúas alertas, non unha que está medio ben.

Unha táboa TCP describe TCP

RFC 4022 especifica tcpConnectionTable, cuxas filas describen conexións TCP establecidas, con clave por tipo de enderezo, enderezo e porto nos dous extremos. As filas desaparecen cando se pecha a conexión, e os sockets en escoita aparecen noutra táboa. Executar unha VPN na mesma máquina non converte unha táboa TCP nun inventario de asociacións de seguridade IPsec. Pode describir unha sesión de xestión, un fluxo de aplicación ou un túnel transportado sobre TCP, e a propia fila non lle dirá cal.

Os contadores de interface levan a mesma ambigüidade nun nivel máis groso: os bytes dunha interface agregan cada par e cada fluxo que a usa.

Constrúa un contrato de observación pequeno

Para cada métrica, rexistre o obxecto ou campo de API admitido, o dispositivo e a versión de software propietarios, o identificador de par ou servizo, a dirección, o momento de recollida e o comportamento de actualización esperado. Despois use a vista documentada de asociacións ou sesións da pasarela para o estado do protocolo, a táboa de encamiñamento para o estado da ruta e unha solicitude estreita permitida para o estado da aplicación. Un punto de xestión que funciona demostra que o punto de xestión funciona e nada sobre a aplicación que hai detrás.

Se o axente instalado carece dos obxectos necesarios, escolla outra interface de só lectura explicitamente admitida. Inventar un OID, ler un reconto TCP xenérico como reconto de túneles ou esperar que unha API antiga de provedor sobreviva sen cambios nun produto irmán son todos camiños sen saída.

Os datos obsoletos non son un fallo do túnel

Un tempo de espera de recollida, unha credencial caducada ou unha ruta de API cambiada producen telemetría ausente. Iso é un fallo de monitorización e un incidente distinto dun túnel que caeu. Rexistre que observación quedou obsoleta e cando, para que o operador reciba unha primeira comprobación significativa en lugar dun reinicio do túnel. Tratar cada tempo de espera como unha caída de VPN ensina a xente a ignorar ambos.

Manteña tamén estreitos os permisos de recollida. Unha interface que pode cambiar a configuración ou borrar sesións leva unha fronteira de privilexios que unha tarefa de monitorización non debería herdar, e unha conta de só lectura adoita ser suficiente.

O deseño útil nomea o obxecto, o significado e o requisito de frescura. A elección de protocolo derívase deles, non ao revés.