Title: Redes e Segurança / Observabilidade Ferramentas de Gerenciamento e Monitoramento de Redes
Tags: Redes_e_Segurança Resumo

front: CEBRASPE, 2024 - SEBRAE-NACIONAL (TI) O Grafana pode consultar diferentes data sources, aplicar transformations e apresentar dashboards.
response: Correto
comment: Item correto. Grafana faz query/alert/explore para métricas, logs e traces em múltiplas fontes.
tldr: - Contexto de prova/editais
- O termo pode aparecer como “ferramentas de gerenciamento e monitoramento” (genérico) ou como listas específicas (nem sempre exaustivas).
- Estratégia sugerida: aprofundar as ferramentas citadas no edital, mas conhecer as demais “por cima” para não ser surpreendido.
- Avaliar risco x tempo (aula curta): foco no que tem maior chance de cair.
- Tendências e convergências
- Observabilidade: capacidade de “observar” e, portanto, dominar o ambiente (engloba gerenciamento, monitoração, visualização, automação etc.).
- SECOPS: convergência entre operações e segurança integrada; ferramentas de observabilidade/ops podem ter recursos de segurança e vice-versa.
- Tríade de Telemetria (bases da observabilidade moderna)
- Métricas: séries temporais e metas de confiabilidade (SLIs/SLOs), bom para detectar tendências e anomalias.
- Logs: narrativa detalhada (causa/efeito), úteis para investigação.
- Traces (distributed tracing): jornada de uma requisição entre serviços, revelando gargalos e dependências.
- OpenTelemetry (OTel)
- Padroniza instrumentação e coleta de telemetria (múltiplas linguagens/plataformas).
- OTel Collector como hub: recebe, processa/transforma e exporta para backends (ex.: Prometheus para métricas; soluções de tracing para traces).
- Boas práticas de observabilidade
- Identidade do serviço: definir service, version e environment (produção/homologação) na telemetria.
- Propagação de contexto: trace context fim-a-fim com trace_id/span_id para correlacionar microsserviços.
- Cardinalidade: evitar rótulos/labels muito dinâmicos (IDs únicos, paths com hash), pois explode séries e dificulta análise/custo.
- APM x Tracing (conceito de banca)
- APM: visão ampla do desempenho do serviço (métricas de app/DB, sintético/real, profiling).
  - Memorizar: APM = “como está meu serviço”.
- Tracing distribuído: correlação ponta-a-ponta entre serviços.
  - Memorizar: Tracing = “como os serviços trabalham juntos”.
- SRE e agentes
- Métricas e confiabilidade frequentemente aparecem sob SRE (Site Reliability Engineering).
- Surgem SRE Agents (com IA) para monitorar/operar com base nessas métricas.
- SLI / SLO / SLA (definições e exemplo)
- SLI: medida (disponibilidade, taxa de erro, latência p95/p99).
- SLO: meta do SLI (ex.: 99,9% em 30 dias).
- SLA: compromisso contratual/externalizado.
- Orçamento de Erro (Error Budget) — não omitir cálculo
- Conceito: SLO define uma margem de falha aceitável no período.
- Fórmula: Orçamento de erro = 1 − SLO.
- Exemplo (30 dias):
  - SLO: 99,9% ⇒ orçamento = 1 − 0,999 = 0,001 = 0,1%
  - 30 dias = 43.200 min ⇒ 0,1% = 43 min e 12 s
  - Logo, até 43m12s de indisponibilidade (ou equivalente em erros/latência acima do alvo) sem violar o SLO.
- Dica cobrada: 99,9% ≈ 43 min/mês e 99,99% ≈ 4 min/mês (30 dias).
- Alertas orientados a SLO (burn-rate)
- Fórmula: Burn rate = (erro observado na janela) / (orçamento de erro permitido na janela)
- Interpretação:
  - Burn rate = 1: consumo “normal”
  - Burn rate > 1: consumindo mais rápido (risco)
- Exemplo (SLO mensal 99,9% ⇒ orçamento 0,1%):
  - Janela 5 min ⇒ orçamento na janela = 0,1% de 5 min = 0,3 s
  - Se houver erro equivalente a 6 s: burn rate (5m) = 6 / 0,3 = 20
- Duas janelas (ex.: 5m e 1h) para reduzir ruído:
  - Curta detecta regressões rápidas; longa evita falso positivo por pico passageiro.
  - Se curta e longa elevadas, ação típica: alerta crítico e possível congelamento de mudanças até estabilizar.
- Stack/fluxo típico citado (Grafana + Prometheus + Alertmanager)
- Grafana: frontend de observabilidade (visualização/correlação).
- Prometheus: coleta e consulta de métricas.
- Alertmanager: gestão/roteamento de alertas.
- Integração moderna: correlacionar métricas (Prometheus), logs (Loki/Elastic) e traces (Tempo/Jaeger) para navegar do painel SLO → latência p95/p99 → traces do período e achar dependência degradada.
- Métricas de telemetria + continuidade de negócios + gestão de incidentes (muito cobrado junto)
- 1) Métricas de tempo do ciclo do incidente (detectar → agir → restaurar)
  - MTTD: início → detecção (ex.: 96 min/12 = 8 min)
  - MTTA: alerta → acknowledgment (ex.: 36/12 = 3 min)
  - MTTI: ack → identificação/hipótese (ex.: 180/12 = 15 min)
  - MTTResponse: alerta/ack → primeira ação efetiva (ex.: 60/12 = 5 min)
  - MTTM: até mitigar impacto (ex.: 10 incidentes somam 200 min ⇒ 20 min)
  - MTTR/MTRS: início → serviço restaurado aceitável (ex.: 320/8 = 40 min)
  - MTTRepair: correção permanente em produção (ex.: 900/6 = 150 min)
  - MTTResolve: encerramento formal (ex.: 720/8 = 90 min)
  - MTBF: tempo entre falhas (ex.: 720h/12 = 60h)
  - MTBSI: entre incidentes que afetaram cliente/SLO (ex.: 720h/8 = 90h)
- 2) Métricas percebidas pelo usuário (SLO/SLI)
  - Disponibilidade: ex. 9.990.000/10.000.000 = 99,90%
  - Taxa de erro: ex. 2.500/500.000 = 0,5%
  - SLO compliance: ex. 27/30 dias = 90%
  - Apdex: ex. (800 + 150/2)/1000 = 0,875 (com T=300ms)
- 3) Golden Signals + RED/USE
  - RED (serviços): Rate (req/s), Errors, Duration (latência p95/p99).
  - USE (recursos): Utilization (CPU/Mem), Saturation (fila/limite), Errors (ex.: pool DB esgotado).
- 4) Qualidade de alertas (reduzir “barulho”)
  - FPR: ex. 70/200 = 35%
  - FNR: ex. 2/10 = 20%
  - Precision/Recall: ex. precision 65% (130/200), recall 80% (8/10)
  - Alert noise ratio: ex. 600/12 = 50 alertas/incidente
  - Page rate: ex. 42 pages/semana para 1 on-call
- 5) Métricas do pipeline de telemetria (logs/métricas/traces)
  - Ingest rate: ex. logs 15.000 eventos/s, traces 2.000 spans/s
  - Drop rate: ex. 9.200/10.000 ⇒ 8% drop
  - Ingestion lag/indexing latency: ex. logs 45s, métricas 10s
  - Cardinality: ex. 1,2M séries em 1h por label user_id
  - Query latency: ex. p95 6,5s
- 6) Mudança, confiabilidade e entrega (associadas a observabilidade)
  - Deployment frequency: ex. 30 deploys/semana
  - Change Failure Rate (CFR): ex. 9/120 = 7,5%
  - Lead time for changes: ex. mediana 6h, p90 24h
  - Rollback rate: ex. 12/120 = 10%
link: https://documentacao.online/estudos/zhca.html
title: Observabilidade Ferramentas de Gerenciamento e Monitoramento de Redes
Other fields (not shown on cards):
back: Correto - Item correto. Grafana faz query/alert/explore para métricas, logs e traces em múltiplas fontes.