APRENDER. PRATICAR. EVOLUIR.Uma fila compra margem limitada
No caso fictício Maré, uma fila tem 200 pedidos e capacidade de 600. Entram 120 pedidos por minuto e saem oitenta. Num modelo constante, sem perdas nem retries, o crescimento líquido é quarenta e a capacidade é atingida em (600−200)/40=10 minutos. Esta é uma projeção de ocupação, não uma promessa de dez minutos sem perda. O tempo máximo de retry pode expirar antes, os pedidos podem ter tamanhos diferentes e as taxas podem mudar. Regista a unidade configurada: pedidos, itens e bytes não são intercambiáveis. A ocupação 240/600=40% em pedidos não informa o número de spans nem a memória consumida. No sistema real, observa também idades, recursos e respostas do destino. Aumentar queue_size pode dar margem, mas não remove uma saída continuamente inferior à entrada. Decide a mitigação com os responsáveis e com o impacto na cobertura de observabilidade explícito.
Persistência e pressão têm fronteiras
Uma fila apenas em memória pode perder dados pendentes num reinício abrupto. file_storage permite persistir a fila, mas depende de capacidade, permissões e ciclo de vida do armazenamento. Um diretório num volume efémero não garante recuperação após substituir a instância. O WAL da gateway também não recupera spans perdidos no agente antes de chegarem. Desenha o percurso e identifica a proteção de cada salto. Persistência não estabelece entrega exatamente uma vez nem elimina retry timeout, fila cheia ou falha de disco. O memory_limiter tem outro papel: recusa dados sob pressão e depende da reação dos componentes anteriores. Não é uma fila persistente nem uma garantia absoluta contra OOM. Para cada hipótese de falha, escreve que dados podem ficar em memória, em disco, em trânsito ou fora de qualquer fonte recuperável. A arquitetura deve declarar a perda tolerada ou a proteção necessária com base na finalidade e nas decisões autorizadas.
Observar a recuperação sem apagar lacunas
O destino voltar a responder não significa que a fila esteja drenada. Com 600 pedidos pendentes, entrada de cem por minuto e saída possível de 160, a drenagem líquida é sessenta: no modelo, são precisos dez minutos. A conta 600/160 só serviria se a entrada parasse. Confirma comportamento real e delimita as lacunas do período afetado. Aumentar max_elapsed_time depois de um descarte não reconstrói os dados perdidos. Durante atualizações, compara a configuração de métricas internas e os nomes realmente expostos; nomes, sufixos e níveis podem mudar. Uma série ausente convertida em zero pode produzir uma falsa indicação saudável. O Collector recuperado também não demonstra que o pagamento ou batch observado concluiu. Fecha a investigação com evidência de fluxo novo, backlog, perdas conhecidas e resultado útil do serviço, atribuindo as questões em aberto aos responsáveis adequados. Não elimines métricas inconvenientes para tornar o relatório verde.
Ensaio de decisão Maré
Usa quarenta minutos com L3, responsável da pipeline, representante do destino e observador. Dedica dez ao desenho dos saltos e à unidade dos indicadores, dez ao cálculo de margem e limites de retry, dez às opções de mitigação e dez à aceitação da recuperação. Introduz durante a discussão duas informações: o agente tem apenas memória e o disco da gateway é efémero. Pede ao grupo que reveja as garantias inicialmente anunciadas. O entregável inclui factos, hipóteses, capacidade, idade desconhecida, risco de perda, ação autorizada, responsável e evidência de fecho. O observador regista se foram distinguidos modelo e medição, disponibilidade e drenagem, telemetria e resultado do negócio. Este é um guião de prática com dados fictícios, ainda não executado com participantes. As contas foram verificadas localmente; persistência, saturação, retry e failover continuam a precisar de ensaios próprios num ambiente autorizado. Não atribuas ao laboratório anterior cobertura que ele não tem.
GUIÃO MARÉ | 40 min: 10 + 10 + 10 + 10
Percurso e responsáveis por salto:
Unidade da fila / capacidade / ocupação / janela:
Entrada / saída / crescimento líquido:
Idade e limite de retry / informação em falta:
Memória / disco / ciclo de vida do volume:
Dados descartados / possível fonte de recuperação:
Mitigação / autoridade / efeito na cobertura:
Evidência de drenagem e novas entradas:
Resultado de negócio a verificar:
Questões pendentes / responsável / revisão:
Observação: não observado | com ajuda | no ensaio sem ajudaCapacidade: (600−200)/(120−80)=10 min. Drenagem: 600/(160−100)=10 min. Os dois resultados dependem de pressupostos diferentes.
Armadilhas comuns
Fila como garantia sem perda; WAL num salto como durabilidade total; reinício como cura; destino disponível como backlog drenado; zero construído de ausência.
Tópicos relacionados: Capacidade e backpressure · Persistência e retry · Passagem para APS
A recuperação exige compreender o percurso e verificar o que chegou, o que espera e o que já não pode ser recuperado.
Referência: Collector resiliency · Observability 2026-09; selected OpenTelemetry, Prometheus and Dynatrace Classic concepts