Defina o objeto VPN antes de escolher SNMP ou API

Três decisões precedem o transporte: que objeto o alerta descreve, que direção e âmbito cobre e com que frescura a leitura deve ser feita. SNMP, uma API HTTPS e uma sonda de aplicação podem todos relatar algo sobre uma VPN, e não relatarão a mesma coisa. Trocar de protocolo sem resolver esses três apenas muda onde a confusão se acumula. O objeto e o significado do alerta são o desenho; o protocolo é a entrega.

Um painel que transforma quatro observações diferentes num único ícone verde já tomou essa decisão mal.

O que o alerta deveria realmente significar?

Pode significar que um par não consegue autenticar-se, que não existe qualquer estado de dados protegido, que uma rota aponta para o lugar errado ou que uma aplicação não consegue terminar o seu trabalho. Cada um desses tem o seu próprio responsável, a sua própria primeira verificação e a sua própria taxa de falsos positivos. Um par que não consegue autenticar-se é um problema de identidade, uma associação de segurança em falta é um problema de estado de protocolo, uma rota é um problema de configuração, e uma falha de aplicação pode não ser nenhum desses. Decida para qual é o alerta antes de escolher um coletor.

Escreva-o como uma frase sobre a qual o engenheiro de turno possa agir. Se a frase precisa de dois objetos, são dois alertas, não um que está meio certo.

Uma tabela TCP descreve TCP

A RFC 4022 especifica tcpConnectionTable, cujas linhas descrevem conexões TCP estabelecidas, com chave por tipo de endereço, endereço e porta nas duas extremidades. As linhas desaparecem quando a conexão fecha, e os sockets à escuta aparecem noutra tabela. Executar uma VPN na mesma máquina não transforma uma tabela TCP num inventário de associações de segurança IPsec. Pode descrever uma sessão de gestão, um fluxo de aplicação ou um túnel transportado sobre TCP, e a própria linha não lhe dirá qual.

Os contadores de interface carregam a mesma ambiguidade a um nível mais grosseiro: os bytes numa interface agregam cada par e cada fluxo que a utiliza.

Construa um pequeno contrato de observação

Para cada métrica, registe o objeto ou campo de API suportado, o dispositivo e a versão de software proprietários, o identificador de par ou serviço, a direção, o momento de recolha e o comportamento de atualização esperado. Depois use a vista documentada de associações ou sessões do gateway para o estado do protocolo, a tabela de encaminhamento para o estado do caminho e um pedido estreito permitido para o estado da aplicação. Um ponto de gestão a funcionar prova que o ponto de gestão funciona e nada sobre a aplicação por trás.

Se o agente instalado não tiver os objetos necessários, escolha outra interface apenas de leitura explicitamente suportada. Inventar um OID, ler uma contagem TCP genérica como contagem de túneis ou esperar que uma API antiga de fornecedor sobreviva sem alterações num produto irmão são todos becos sem saída.

Dados desatualizados não são uma falha do túnel

Um tempo limite de recolha, uma credencial expirada ou um caminho de API alterado produzem telemetria em falta. Isso é uma falha de monitorização e um incidente diferente de um túnel que caiu. Registe que observação ficou desatualizada e quando, para que o operador receba uma primeira verificação significativa em vez de um reinício do túnel. Tratar cada tempo limite como uma falha de VPN ensina as pessoas a ignorar ambos.

Mantenha também estreitas as permissões de recolha. Uma interface que pode alterar a configuração ou limpar sessões carrega uma fronteira de privilégios que uma tarefa de monitorização não deve herdar, e uma conta apenas de leitura costuma ser suficiente.

O desenho útil nomeia o objeto, o significado e o requisito de frescura. A escolha do protocolo decorre desses, não o contrário.