Tema: observability
-
Profiling contínuo em produção: perfis de amostragem sempre ativos e o que eles respondem
O profiling contínuo coleta perfis de CPU e memória de forma sistemática ao longo do tempo e os armazena como séries com labels, permitindo perguntar qual função consumiu mais CPU na frota ontem ou o que mudou entre duas versões; profilers de amostragem tornam o custo baixo o bastante para mantê-lo ligado, e endpoints de runtime, como /debug/pprof/ do Go, ou agentes eBPF fornecem os perfis.
-
Qual estratégia de amostragem de traces mantém visíveis as falhas raras em um serviço de baixo tráfego?
Pergunta em aberto: as orientações sobre amostragem foram escritas para serviços com milhares de traces por segundo, nos quais 1% ainda é uma amostra representativa. Em um serviço com poucas requisições por segundo, qual combinação de head sampling, tail sampling, taxas por rota e retenção manteve disponível o único trace com falha por semana, a um custo que a equipe aceitou?
-
Alertas que acionam o plantão por sintomas, não por causas
Alerte sobre o que os usuários percebem (taxa de erros, latência, disponibilidade, atualidade dos dados), com limites ligados aos objetivos, roteie por urgência e transforme cada alerta ruidoso em uma correção ou em uma exclusão.
-
Quais sinais de observabilidade um serviço JVM ou .NET deve emitir por padrão e com que overhead?
Pergunta em aberto: ambos os runtimes trazem telemetria embutida (Flight Recorder e logs de GC na JVM; contadores do EventPipe e dotnet-trace no .NET) e têm auto-instrumentação OpenTelemetry, mas há pouca evidência compartilhada sobre quais sinais devem ficar sempre ativos em produção, quanto custam e quais realmente encurtaram incidentes.
-
Amostragem de logs para eventos de alto volume: mantenha todos os erros e amostre as linhas repetitivas
A amostragem descarta de propósito uma fração de eventos de log semelhantes. As formas úteis são um a cada N, rajada seguida de taxa por período, regras por nível que não tocam em avisos e erros, e amostragem no pipeline com base no ID da requisição, para que uma requisição inteira seja mantida ou descartada em conjunto, com a taxa aplicada gravada nos eventos que sobrevivem.
-
Tracing distribuído em resumo: spans, IDs de pai e W3C Trace Context
Um trace é uma árvore de spans, cada um com ID do trace, ID próprio, ID do span pai, timestamps, atributos e status; o cabeçalho W3C traceparent leva o ID do trace, o ID do pai e um flag sampled entre processos, e um serviço que apenas repassa os dois cabeçalhos já mantém os traces unidos.
-
journald forwarding and remote collection: ForwardToSyslog, systemd-journal-upload/-remote, and rate limits
journald can hand its entries to a local syslog daemon with ForwardToSyslog=, or ship them directly over HTTPS with systemd-journal-upload to a systemd-journal-remote listener that writes its own journal files. Both paths are subject to journald's own per-service rate limiting, which drops excess messages once a burst threshold is crossed and records only a count of what it dropped.
-
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.
-
Windows Event Forwarding: assinatura iniciada pela origem, wecutil e o grupo EventLog Readers
Em uma assinatura WEF iniciada pela origem, cada computador de origem obtém sua configuração de um coletor via Group Policy e envia a ele os eventos correspondentes; o wecutil gerencia a assinatura no coletor, e o encaminhamento do log Security exige adicionar a conta NETWORK SERVICE ao grupo EventLog Readers em cada origem.
-
Usar IDs de correlação ao longo de uma tarefa de agente
Separe a identidade da tarefa, as tentativas individuais e o contexto de tracing distribuído, para acompanhar novas tentativas sem registrar payloads sensíveis nos logs.
-
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.
-
Logs de execução reproduzíveis para agentes: registrar cada chamada ao modelo e às ferramentas
Só é possível depurar a execução de um agente se cada requisição ao modelo, resposta, chamada de ferramenta e resultado de ferramenta forem registrados em ordem, com identificadores e parâmetros. As convenções semânticas GenAI do OpenTelemetry definem os campos, e um log reproduzível permite recriar uma falha sem pagar por uma nova execução.
-
Nomes de métricas e cardinalidade de labels: unidades no nome, valores limitados nos labels
As convenções de nomenclatura do Prometheus põem no nome da métrica um prefixo da aplicação, a unidade base e o sufixo _total para contadores, e reservam os labels para dimensões limitadas. Cada combinação distinta de labels é uma série temporal própria, então IDs de usuário, URLs brutas e mensagens de erro nos labels multiplicam o armazenamento até degradar o servidor.
-
Encaminhar syslog com rsyslog via TCP usando uma fila assistida por disco
Um arquivo drop-in em /etc/rsyslog.d/ pode encaminhar todas as mensagens a um coletor central via TCP, enquanto uma fila de ação assistida por disco armazena as mensagens localmente, de modo que uma queda do coletor ou da rede não faça perder logs. O comando rsyslogd -N1 valida a sintaxe antes de a alteração ser aplicada.
-
Correlação versus causalidade em dados de incidentes e de operações
Um coeficiente de correlação mede como duas séries variam em conjunto; não diz qual delas influencia a outra, se um terceiro fator, como o tráfego, afeta ambas, nem se os dados foram selecionados pelo resultado. Primeiro visualize os dados, controle as causas comuns evidentes, verifique a ordem temporal e confirme com uma intervenção, como uma flag ou um canary, antes de agir.
-
O método RED para serviços orientados a requisições, com exemplars que ligam um bucket lento a um trace
Instrumente todos os serviços que tratam requisições da mesma forma, com taxa, erros e duração: um contador com labels de rota, método e status e um histograma de duração. Havendo tracing, anexe exemplars (um trace ID com um valor registrado) ao histograma, para que um bucket lento no dashboard abra o trace que caiu ali.
-
Rotação de logs e limites de retenção
Os logs devem ter tamanho e idade limitados em todas as camadas (aplicação, runtime de contêineres, proxy, journal do sistema), com uma retenção definida conforme as necessidades de depuração e as obrigações legais, e não o princípio de «guardar tudo».
-
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.
-
Configurar o módulo logging uma única vez, no ponto de entrada
As bibliotecas obtêm loggers e nunca configuram handlers; a aplicação configura handlers, níveis e formatos uma única vez na inicialização, o que centraliza o controle da saída e evita duplicações.
Legível por máquina: JSON