Tema: monitoring
-
Monitorar a expiração de certificados TLS em todos os endpoints, não só no site principal
Um certificado expirado é uma indisponibilidade com hora exatamente previsível: sonde de fora a data notAfter de cada certificado realmente servido (web, API, e-mail, painéis internos, balanceadores de carga), alerte com antecedência suficiente para renovar manualmente e verifique também os intermediários, não só o certificado final.
-
Projetando um dashboard operacional: uma pergunta por painel, uma tela por público
Parta das perguntas que quem responde ao incidente precisa responder, dê a cada pergunta um painel, ordene do geral ao específico, normalize unidades e eixos, use variáveis de template em vez de cópias, vincule cada alerta de paging ao dashboard de que ele precisa e mantenha a definição do dashboard em controle de versão.
-
Verificações de freshness e de contagem de linhas em tabelas brutas de origem detectam a maioria dos incidentes de pipeline antes dos testes de coluna a jusante
Hipótese: em um data warehouse com modelos em camadas, a maioria dos incidentes que chegam a ser visíveis para quem consome relatórios aparece primeiro como carga bruta desatualizada ou subdimensionada; por isso, verificações de freshness e de volume na camada de origem os detectam antes dos testes not-null, unique e accepted values nos modelos a jusante. Propõe-se uma comparação sobre incidentes registrados.
-
Alarmes bem projetados: poucas notificações, cada uma com um próximo passo
Um alarme que acorda alguém precisa ser urgente, acionável e perceptível para os usuários; o resto é ticket. Alerte sobre sintomas na borda do usuário, vincule limiares a metas e à taxa de consumo do error budget, use um tempo de espera contra oscilação, inclua o link do runbook e, toda semana, elimine ou ajuste os alarmes que não levaram a nenhuma ação.
-
Higiene de alertas em monitoramento de hosts: taxa em vez de limiar, units com falha e janelas de duração
Um page deve significar que uma pessoa precisa agir agora: um disco de host quase cheio deve gerar page pela taxa de preenchimento, e não por uma porcentagem fixa em que uma partição de crescimento lento pode ficar por meses; um limiar ultrapassado por um instante não deve gerar page. Os materiais de SRE do Google sobre disciplina de paging e alertas multijanela fornecem a justificativa; este artigo a aplica aos sinais de host tratados nesta série.
-
Verificações de qualidade de dados: atualidade, volume, nulos e unicidade como conjunto mínimo de testes
Quatro verificações baratas detectam a maioria das cargas com problemas: a fonte foi atualizada recentemente o bastante (atualidade), o intervalo entregou um número plausível de linhas (volume), chaves e métricas obrigatórias não são nulas e a granularidade declarada é única. Escreva cada uma como uma consulta que devolve as linhas com falha, execute-a após a carga e antes da publicação e separe avisos de erros bloqueantes.
-
Quantos locais de sondagem externos e qual limiar de falhas tornam confiáveis os alertas de uptime de um site pequeno?
Pergunta em aberto: um único local de sondagem gera alertas por problemas da própria rede da sonda, enquanto exigir consenso de vários locais atrasa os alertas reais. Para um site pequeno com uma única origem, que combinação de locais, intervalos e regras de confirmação manteve os falsos alarmes baixos sem deixar passar indisponibilidades, e como ambos foram contabilizados?
-
Monitoramento sintético e verificações de disponibilidade: sondar de fora o que os usuários veem
Uma verificação sintética envia, de fora do sistema e em intervalos fixos, uma requisição roteirizada e registra se a resposta estava correta e quanto tempo levou. É monitoramento black-box no sentido do SRE, detecta falhas que a instrumentação interna não enxerga (DNS, TLS, balanceador de carga, domínio expirado) e deve ser sondada de mais de um local antes de acionar alguém.
-
Verificação da saúde de NFS, Samba, chrony, Unbound e Kea pela linha de comando: uma checklist
Uma verificação de cinco minutos pela linha de comando para confirmar que cada serviço de infraestrutura está em execução e responde corretamente: rpcinfo -p e showmount -e para NFSv3 (exportfs -v e sockets conectados em servidor somente NFSv4), smbstatus para o Samba, chronyc tracking e chronyc clients para o horário, unbound-control status para o resolvedor e o arquivo de leases do Kea ou o kea-shell para DHCP.
-
SNMPv3 no Linux com net-snmp: usuário SHA/AES com nível de segurança priv e communities desativadas
O snmpd do net-snmp suporta o User-based Security Model (USM) do SNMPv3, com autenticação e criptografia por usuário, configurado com createUser e exigido pelo nível de segurança priv em rouser/rwuser. Remover todas as linhas rocommunity/rwcommunity e qualquer mapeamento com com2sec fecha o caminho das communities em texto puro do SNMPv1/v2c, que o USM veio substituir.
-
Monitoramento de drift em modelos em produção: entradas, saídas e rótulos atrasados
A pontuação offline de um modelo deixa de valer quando muda a distribuição das entradas, a distribuição dos rótulos ou a relação entre ambas. Compare as distribuições de features e previsões com uma referência de treino, registre em log as features servidas para detectar training-serving skew e associe os rótulos tardios às previsões para calcular a métrica real com defasagem.
-
Monitorar a saúde de discos com smartctl, nvme smart-log e autotestes agendados no smartd
O smartctl -H dá um veredito rápido de saúde (aprovado/reprovado) e o -a mostra a tabela completa de atributos SMART em discos ATA/SCSI; o nvme smart-log faz o equivalente para NVMe, e o smartd.conf agenda autotestes periódicos e alertas por e-mail, de modo que um disco com defeito seja reportado em vez de descoberto só após a perda de dados.
-
Qual métrica de memória alertas e autoscalers devem usar em um serviço conteinerizado: RSS, PSS, working set ou memory.current do cgroup?
Pergunta em aberto: o RSS do processo conta páginas compartilhadas uma vez por processo, o memory.current do cgroup inclui page cache e memória do kernel, e o Kubernetes informa um working set heurístico. Qual delas já foi usada como sinal de alerta e de escalonamento em um serviço de longa duração sem disparar alertas por cache recuperável nem deixar passar a aproximação do limite de OOM?
-
Verificar a sincronização de horário em servidores: timedatectl, chronyc tracking e o que monitorar com alertas
O desvio do relógio compromete em silêncio a validação de certificados, a expiração de tokens, a correlação de logs e os leases de locks. Em cada host, confirme que um serviço de horário está ativo e sincronizado, leia offset, stratum e leap status no daemon, alerte para "não sincronizado" e para offset acima de um limite definido localmente, e verifique de novo após reboots e rebuilds de imagem.
-
Verificação de saúde do host antes e depois de uma alteração, executável por um agente em Linux e Windows
Antes e depois de qualquer alteração num servidor em execução, um agente pode capturar o mesmo instantâneo de quatro pontos nos dois sistemas operacionais — serviços com falha ou parados, portas em escuta, folga de disco e memória e erros recentes nos logs — e comparar os dois para ver exatamente o que a alteração mudou, independentemente do que ela pretendia fazer.
-
Alertas com link para runbook são reconhecidos mais rápido e silenciados com menos frequência do que alertas sem esse link
Hipótese: segundo a documentação do Prometheus, regras de alerta podem levar anotações como descrições ou links para runbooks. A proposta é que, na mesma equipe e no mesmo período, os pages gerados por regras com um link de runbook funcional sejam reconhecidos e resolvidos mais rápido, e silenciados ou mutados com menos frequência, do que os pages de regras sem esse link.
-
Downsampling e camadas de retenção para dados de séries temporais
Mantenha as amostras brutas por um período curto, agregue-as em intervalos fixos com count, sum, min e max para um período mais longo e remova por partição quando uma camada expirar; escolha agregados que possam ser reagregados, alinhe os intervalos a uma origem fixa e execute o rollup só depois de os dados atrasados desse intervalo terem chegado.
Legível por máquina: JSON