Monitorização SNMP no Odoo 19: limite excedido, ticket aberto
Servidores, switches, UPS, sensores de temperatura na sala de servidores: quase tudo o que está ligado a uma rede fala SNMP e pode informar sobre o seu estado. A questão é apenas quem está a ouvir – e o que acontece quando um valor sai fora de controlo.
Para a infraestrutura que acompanhamos para os nossos clientes, reunimos agora esta cadeia num só local: o nosso Odoo 19 consulta os dispositivos, compara os valores com limites e, quando um limite é atingido, abre um ticket no helpdesk – no cliente a quem o dispositivo pertence. Sem um sistema de monitorização separado que escreve por e-mail no helpdesk, mas o mesmo sistema em que cliente, dispositivo e ticket já estão, de qualquer modo, ligados.
Desenvolvemos o módulo para a nossa própria operação. Não é uma publicação para a comunidade como os nossos módulos de extratos bancários ou de faturas eletrónicas, mas parte da nossa plataforma interna de assistência – tal como a localização, sobre a qual informámos recentemente.
Do valor medido ao ticket
O processo é deliberadamente simples:
- Um dispositivo é criado com endereço e credenciais de acesso (SNMP v1, v2c ou v3 com autenticação e encriptação). Ao guardar, o Odoo obtém a descrição do sistema, o nome do sistema e o uptime – a confirmação mais honesta de que o endereço e as credenciais de acesso estão corretos.
- No dispositivo, são definidos pontos de dados: um OID, uma unidade, uma atribuição a um cliente.
- Um agendamento consulta todos os pontos de dados ativos. Liga-se uma vez por dispositivo, e não por ponto de dados – com vinte OIDs num switch, é a diferença entre uma e vinte sessões.
- Cada ponto de dados pode monitorizar limites: um limite superior, um limite inferior ou ambos.
- Se um limite for excedido, é criado um ticket de helpdesk.
Um ticket por incidente, não por medição
O ponto mais importante na lógica de alarme: só conta a mudança de estado. Quem cria um ticket a cada medição tem, após uma noite com um sensor encravado ou instável, trezentos tickets – isso não é alarmística, é nevoeiro.
Por isso, o módulo memoriza, para cada ponto de dados, se este se encontra no estado “Normal” ou “Alarme”. Ao exceder o limite pela primeira vez, o estado muda, uma mensagem fica no chatter do dispositivo e é aberto um ticket – com o cliente em causa como parceiro, com ponto de dados, dispositivo, valor medido e limite violado no texto. Enquanto o valor permanecer fora do limite, nada mais acontece: o ticket está aberto, os nossos técnicos sabem.
Quando o valor regressa ao intervalo normal, o módulo escreve um aviso de normalização no mesmo ticket e desfaz a ligação. Se o ticket é depois fechado continua a ser decidido por uma pessoa – um valor que desce brevemente abaixo do limite não significa ainda que a causa foi resolvida.
Os limites são verificados em cada medição, independentemente de o valor ser guardado. Um valor constantemente demasiado alto continua a ser um alarme. E um alarme nunca pode falhar por não ser possível criar um ticket – se a criação falhar, o registo e a mensagem no dispositivo permanecem na mesma.
Guardar apenas o que muda
Um ponto de dados consultado de cinco em cinco minutos produz 105 000 valores por ano. Com cem pontos de dados, são mais de dez milhões de linhas – para valores que, na maioria, nem sequer mudaram.
Por isso, só é guardado o que difere do último valor guardado em mais do que um limiar definido – por ponto de dados, como diferença absoluta (por exemplo, 0,5 °C), como desvio percentual ou a cada alteração. O valor atual e o momento da última consulta estão, mesmo assim, sempre no ponto de dados; só o histórico é reduzido.
O destino onde os valores são escritos também é configurável: na base de dados do Odoo, numa MongoDB ou como ficheiros CSV no filestore do Odoo. Assim, mantemos os valores medidos fora da base de dados do ERP – o mesmo princípio que nos dados de posição da localização. O histórico pode, em qualquer caso, ser apresentado como gráfico; na agregação por hora, como média, não como soma.
Nível de enchimento em percentagem em vez de bytes
Algumas grandezas não existem como tal no dispositivo. O nível de enchimento de uma partição tem de ser calculado a partir da memória ocupada e do tamanho total; os sensores de temperatura fornecem frequentemente inteiros escalados – 235 para 23,5 graus.
Por isso, um ponto de dados pode adotar o valor tal como comunicado, multiplicá-lo por um fator ou calculá-lo como percentagem de um segundo OID. Para os limites, isto é decisivo: um limite de 90 % aplica-se a qualquer tamanho de disco. Um limite em gigabytes teria de ser mantido para cada unidade.
Ninguém precisa de saber OIDs de cor
Em servidores Windows e Linux, a HOST-RESOURCES-MIB é normalizada: unidades e memória principal encontram-se num local conhecido. Uma deteção de dispositivos lê a tabela, converte os níveis de enchimento em percentagem e cria os pontos de dados, com limite de alarme, com um clique.
Para tudo o resto, existe um navegador SNMP que percorre a árvore de OIDs e mostra cada OID encontrado com o seu valor atual – e, se conhecido no catálogo, com nome, descrição e unidade da MIB do fabricante importada. Basta assinalar.
O que os nossos clientes ganham com isto
Os dispositivos e pontos de dados estão atribuídos a clientes. No portal de clientes, encontra em Os meus valores SNMP os valores medidos atuais dos seus dispositivos e o histórico das últimas 24 horas, 7 dias, 30 dias ou 12 meses como gráfico – os mesmos valores que nós também vemos. É visível exclusivamente o que está atribuído à sua empresa.
E, quando um limite é excedido, não tem de fazer nada: o ticket já está connosco, com dispositivo, valor e hora, antes de o notar.
O que o módulo deliberadamente não é
Não substitui uma monitorização completa com verificações de disponibilidade, cadeias de escalonamento e árvores de dependências. Não recebe traps SNMP, mas consulta ativamente. E não fecha nenhum ticket automaticamente – o aviso de normalização é uma mensagem, não uma alteração de estado.
Trata-se exatamente de um percurso: do valor medido, passando pelo limite, até ao técnico que trata do assunto. Esse percurso é agora o mais curto possível.
Se quiser incluir os seus servidores, dispositivos de rede ou sensores nesta monitorização, fale connosco.