Em um ambiente de produção, nem todo evento tem a mesma importância. Um backend em manutenção, todos os backends down, o cluster IP migrando para outro node, um certificado prestes a expirar em 30 dias ou o limiar de request rate ultrapassado exigem respostas operacionais diferentes. Se tudo isso virar um único tipo de alarme por e-mail, a equipe rapidamente sofre fadiga de alarmes.
Nas abordagens clássicas, a notificação geralmente se limita a e-mail e syslog. No entanto, as equipes de operação querem receber eventos diferentes por canais diferentes: failover crítico por SMS, aviso de rotina pela UI, evento de segurança por SNMP ou Syslog, resumo gerencial por e-mail. Sem separação de canais, ou todos recebem tudo, ou os eventos críticos passam despercebidos.
O gerenciamento de horário silencioso também é importante. Acordar toda a equipe às 03:00 por um aviso de baixa importância é desnecessário; mas uma interrupção real ou uma troca de cluster IP ainda devem ficar visíveis. O horário silencioso deve significar não que o evento desaparece totalmente, mas que é tratado no canal certo e no momento certo.
Relatar eventos como pool down, backend down, cluster IP swap e fechamento de zona com o mesmo texto dificulta a análise de causa raiz. O operador primeiro tenta decifrar o que o alarme significa, depois age. Esse atraso reflete diretamente na qualidade do serviço, especialmente em plataformas de alto tráfego.
O Sistema de Notificações do TR7 distingue os eventos com ciclo de vida de alarmes, 30+ chaves de status prontas, múltiplos canais, múltiplos idiomas, horário silencioso e gerenciamento de limiar por pool; entrega à pessoa certa, pelo canal certo, com o contexto certo.
O TR7 gerencia as notificações não como mensagens pontuais, mas como objetos de alarme com ciclo de vida e ações por canal.
Os alarmes ativos são mantidos por alarmKey, atualizados com updateAlarm e encerrados com endAlarm. Assim, o mesmo evento não é gerado repetidamente como um novo alarme; o início, a atualização e o encerramento do evento são acompanhados.
O estado de alarme e notificação pode ser transmitido aos demais nodes do cluster. Assim, a equipe de operação pode ver não apenas os eventos do node ao qual está conectada, mas também a situação crítica em todo o cluster.
O status de pool é classificado pelos valores UNKNOWN, OK, WARN, DISABLED, ERR e EVALUATING. Esse modelo não reduz os estados de manutenção, aviso, erro e avaliação ao mesmo texto plano de alarme.
Os estados de cluster IP são avaliados com sinais distintos como acessibilidade de interface, conflito de IP, migração de IP e comportamento de dois nodes. Os eventos de failover são entregues à equipe de operação com um contexto mais claro.
O Sistema de Notificações oferece ciclo de vida de alarmes, limiares de pool, múltiplos canais, múltiplos idiomas, horário silencioso, aviso de certificado e histórico de eventos arquivável.
O fluxo updateAlarm, endAlarm e getAlarms acompanha os alarmes ativos com seu ciclo de vida. Quando o mesmo alarmKey chega novamente, o evento é atualizado; não é replicado como um alarme totalmente novo. Campos como staticPayload, ifAbsent e dontNotify permitem gerenciar o comportamento do evento de forma mais controlada. Essa estrutura reduz o ruído de alarmes e torna o histórico de eventos mais significativo.
Para cada pool podem ser definidos limiares de serviceStatus, poolStatus, bandwidth, request rate, current session e new connection. Dentro da mesma estrutura podem ser determinadas as preferências de canal e-mail, SMS, WhatsApp, BiP, SNMP e UI. Assim, um serviço crítico pode ser monitorado com uma política de alarme mais agressiva e um serviço de baixa importância com uma política mais silenciosa. O comportamento de notificação não é aplicado de forma uniforme a toda a plataforma.
O TR7 oferece um modelo de notificação que suporta múltiplos canais como e-mail, SMS, WhatsApp, BiP, SNMP, Syslog e UI. Eventos críticos de infraestrutura podem ser entregues por SMS ou SNMP aos sistemas de gerenciamento de rede, resumos gerenciais por e-mail e situações de rotina pela UI. O mesmo evento pode ser enviado a diferentes canais com prioridades distintas. Essa flexibilidade reduz a dependência de um gerenciador de alarmes externo.
O NotificationTranslator pode gerar os textos de notificação em diferentes idiomas com uma lógica de tradução baseada em dictionary. Uma equipe de operação local pode receber notificações em um idioma e uma equipe internacional em inglês. É possível entregar o mesmo evento a diferentes usuários em idiomas diferentes. Isso reduz o risco de interpretação equivocada em operações multinacionais.
Podem ser usadas 30+ chaves de status como poolDisabled, allBeDown, noBeGiven, beDown, beStateUnknown, beMaint, poolDown, poolInterfaceAbsent, zoneClosed, clusterIpBoth, clusterIpPossibleCollide, clusterIpSwitched e clusterIpNone. Essas chaves tornam o texto do alarme mais explicativo. O operador não recebe apenas a mensagem "serviço com problema"; também vê o tipo do problema. O tempo de intervenção encurta.
Com silentAtNight, certas notificações podem ser silenciadas durante a noite. Isso não significa que o evento desaparece totalmente; ele pode continuar visível na UI ou ser incluído no resumo da manhã. Aplicando uma política de canal separada para eventos críticos, os alarmes realmente importantes ainda podem ser entregues. A fadiga de alarmes é reduzida enquanto a visibilidade operacional é preservada.
Com o campo notifyDaysBeforeCertificateExpiry pode ser gerado um aviso um determinado número de dias antes da data de expiração do certificado. Por exemplo, faltando 30 dias, pode ser enviada uma notificação por e-mail ou UI. Assim, a operação de renovação de certificado não fica para o último dia. Esquecimentos que poderiam causar interrupção de TLS são detectados em fase inicial.
Os membros de um contact group podem ser definidos com endereços de e-mail, números de SMS e informações de tipo de usuário. As notificações podem ser direcionadas a um usuário individual, a um grupo de equipe ou a um tipo de usuário. Esse modelo facilita direcionar separadamente grupos de equipe de plantão, SOC, SRE ou gerência. Mudanças de pessoas podem ser gerenciadas sem quebrar a política de canais.
Podem ser configurados host SMTP, porta, authentication, username, password, segurança TLS, validação de certificado, sender name, sender address, cc, bcc, attachment e mensagens HTML. O valor de timeout de conexão de e-mail pode ser mantido no nível de 10 segundos. Essa estrutura facilita a integração com o mail relay ou a infraestrutura SMTP existente da organização. As notificações por e-mail podem ser adaptadas às políticas de marca e segurança.
Os logs de alarme e notificação podem ser arquivados com nomes separados. Com compressão zip e nível de compressão elevado, os eventos passados podem ser armazenados para auditoria e investigação. Em processos de PCI, gerenciamento de mudanças ou análise pós-incidente, o histórico de notificações pode ser usado como evidência. Pode operar junto com processos de arquivamento externo sem perder a visibilidade local.
O campo NotificationType faz a distinção entre alarme, notification e info com classes como A, N e I. Essa distinção é importante para a criticidade do evento e a forma como ele é apresentado ao usuário. Nem toda mensagem de informação se comporta como um alarme; nem todo alarme se perde como uma notificação comum. O comportamento na UI e nos canais externos pode se alimentar dessa classificação.
O campo pairId do BasicNotification pode ser usado para relacionar as notificações pertencentes ao mesmo grupo de eventos. Por exemplo, a abertura, a atualização e o encerramento de um alarme podem ser acompanhados dentro da mesma família de eventos. Isso facilita ver junta a cadeia de eventos no lado do SIEM ou da auditoria. Em vez de mensagens isoladas, todo o processo do evento pode ser analisado.
O Sistema de Notificações opera em conjunto com valores de status, nomes de log, compressão, segurança SMTP e a state machine de cluster IP.
Os valores de status de pool são classificados como UNKNOWN=-1, OK=0, WARN=1, DISABLED=2, ERR=3 e EVALUATING=4. Esse modelo numérico fornece uma base consistente para a avaliação de alarmes e a exibição na UI. Os estados são tratados não apenas como texto, mas como valores sobre os quais se pode decidir.
Os logs de alarme podem ser mantidos com o nome basic-alarms e os de notificação com basic-notifications. Essa separação permite investigar separadamente o ciclo de vida do evento e as notificações entregues ao usuário. Os processos de operação e auditoria podem ler diferentes tipos de log conforme sua própria necessidade.
Os arquivos de alarme e notificação podem ser mantidos em formato zip e com nível de compressão elevado. Isso reduz o custo de armazenamento de longo prazo. Para auditoria, fornece acesso mais fácil aos registros de notificação passados.
Sob `_lb.*` há 30+ chaves de status prontas. Essas chaves são usadas para descrever de forma mais granular os comportamentos de pool, backend, interface, zona e cluster IP. O texto da notificação e a lógica de decisão se enriquecem com essas chaves.
No envio de e-mail, o valor de timeout de conexão pode ser configurado como 10000 ms. O comportamento de segurança TLS e validação de certificado é controlado pelo usuário. Isso permite fazer a integração com o mail relay conforme os requisitos de segurança da organização.
Os estados de cluster IP são interpretados por uma state machine separada. Situações como inacessibilidade de IP, status de interface, possível conflito ou migração de node podem ser convertidas em valores combinados de estado de cluster IP. Os alarmes de failover são gerados de forma mais precisa com esse contexto.
Quando um evento de backend down de baixa importância ocorre às 02:00, o silentAtNight pode interromper o envio de e-mail. O evento permanece ativo na UI e pode ser incluído no resumo da manhã. Assim, os alarmes noturnos desnecessários são reduzidos sem que o evento desapareça por completo.
A equipe de operação pode definir o valor de notifyDaysBeforeCertificateExpiry como 30 dias. Quando a validade do certificado se aproxima, o sistema gera uma notificação por e-mail ou UI. Os riscos de renovação de última hora que poderiam causar interrupção de TLS diminuem.
Quando o cluster IP migra para outro node, pode ser gerado o evento clusterIpSwitched. Esse evento pode ser entregue à equipe de operação por SMS, SNMP ou UI. Quando o failover ocorre, a equipe fica sabendo no momento do evento, não depois dele.
Quando o limiar de request rate, bandwidth, session ou nova conexão é ultrapassado, pode ser gerada uma notificação SNMP. O sistema de gerenciamento de rede recebe esse evento em seu próprio painel de alarmes. As equipes de segurança e operação de rede veem o mesmo limiar em um fluxo de monitoramento comum.
Os logs de alarme e notificação podem ser armazenados como arquivo comprimido. Durante uma auditoria, é possível mostrar qual evento ocorreu quando, qual canal foi usado e se o alarme foi encerrado. O histórico de notificações se transforma em evidência operacional.
Enquanto uma equipe recebe o mesmo alarme por e-mail em um idioma, a equipe de operação internacional pode receber a mensagem em inglês. O NotificationTranslator gera o texto do evento conforme o idioma do usuário. Em operações multinacionais, o risco de o alarme ser mal interpretado diminui.
Ciclo de vida de alarmes, 30+ chaves de status, múltiplos canais e horário silencioso. Vamos mostrar em uma configuração ao vivo no seu próprio ambiente.