Monitorización de VPN de Azure Site: emparelle o estado do túnel cunha sonda real

Todos os paneis están verdes, o túnel leva once días activo e a sucursal non pode cargar a aplicación interna. Ese é o síntoma para o que existe este deseño, e non é un fallo de monitorización. O estado do túnel responde a unha pregunta sobre a negociación, mentres que o usuario pregunta por unha petición que cruza catro decisións de encamiñamento e unha capa de políticas. Necesita ambas as sinais, por separado, e unha forma de distinguilas de madrugada.

Comece polo síntoma que falla, non polo túnel

Unha asociación de seguridade establecida significa que os pares acordaron unha proposta e instalaron claves. Non significa que os selectores cubran a subrede que necesita o usuario, que o lado remoto teña unha ruta de retorno ou que un cortalumes acepte o porto tras o descifrado. O tráfico tamén pode fallar no lado da sucursal do túnel, e entón Azure non ve nada e informa dunha saúde perfecta. A métrica do túnel é necesaria e nunca é suficiente.

Hai que poder distinguir tres estados: o túnel está caído, o túnel está activo e o servizo falla, e a propia fonte de monitorización non está dispoñible.

Coloque a sonda onde están os usuarios

Para unha aplicación de sucursal a Azure, execute a proba sintética desde un host na rede de carga de traballo da sucursal e apúntea ao punto de entrada HTTPS privado que os usuarios realmente usan. Unha sonda lanzada desde a pasarela usa outro enderezo de orixe e a miúdo outra ruta de política, así que pode pasar mentres todos os usuarios fallan. Azure Connection Monitor admite comprobacións TCP, ICMP e HTTP con grupos de proba e limiares, e as súas fontes locais teñen requisitos de axente distintos dos do lado de Azure. Comprobe a disposición admitida actualmente en lugar de copiar unha receita clásica de monitorización retirada dun blog.

Manteña a sonda estreita e aburrida: un destino, un porto, unha frecuencia que coincida co requisito operativo e unha regra de permiso explícita para esa fonte.

Escolla unha comprobación que encaixe co servizo

Unha conexión TCP ao porto do servizo demostra alcanzabilidade de transporte polo túnel e non di nada sobre TLS nin sobre a aplicación. Unha comprobación HTTP engade unha expectativa de estado e detecta un escoitador que acepta conexións pero non pode servir, que é o fallo máis habitual tras un cambio de certificado ou de backend. Ningunha das dúas é unha transacción de negocio autenticada se a proba non autentica de verdade, así que non a etiquete como tal no panel. Escolla a comprobación que falla cando ocorre a queixa do usuario.

ICMP é a opción máis feble das tres, xa que moitas pilas o descartan por política e un ping fallido demostra moi pouco.

Leve ambas as sinais a Elastic sen inventalas

A pasarela VPN emite métricas de plataforma como bytes de saída e entrada do túnel e contadores de paquetes descartados, e pode enviar rexistros de diagnóstico en categorías que inclúen eventos de túnel e IKE. Os resultados de Connection Monitor chegan por Azure Monitor como métricas e por un espazo de traballo de Log Analytics como rexistros. Nada deso aparece por si só nun índice de Elastic. Escolla unha canalización admitida para as métricas e outra para os rexistros, normalmente a entrada de Azure Event Hub ou a integración de Azure Monitor, e verifique que inxire realmente a integración instalada antes de confiar no patrón de índice.

Conserve as etiquetas que permiten a un operador unir os dous conxuntos de datos: punto final de orixe, destino, protocolo e porto para a sonda, e identidade do túnel máis enderezo do par para a pasarela.

Valide a canalización cun evento controlado, despois búsqueo en Elastic e comprobe a súa marca de tempo e as súas etiquetas de recursos. Un documento coa marca de tempo incorrecta é peor ca un ausente, porque fai que os datos vellos parezan actuais.

Alerte sobre a diferenza, non sobre a cor

O sentido de manter dúas sinais son as combinacións. Túnel caído debería avisar o responsable de rede; túnel activo cunha sonda que falla o responsable da aplicación; un resultado de sonda ausente a quen sexa dono do axente de monitorización. Fundir as tres nun só panel vermello garante que a alerta quede silenciada nun mes. Alerte sobre un fallo sostido cunha xanela de persistencia en lugar dunha soa mostra, e engada unha comprobación aparte para a saúde da propia canalización de inxestión.

Un panel cheo de mostras correctas de onte non debería lerse como unha ruta san hoxe.

Escrito, o contrato é pequeno: a métrica do túnel di que a pasarela negociou, a sonda di que a ruta funciona desde onde sentan os usuarios, e a saúde da canalización di se calquera das dúas respostas está ao día. Todo o demais no panel é comentario.