Skip to content

09 ‐ Observabilidade

Jump to bottom
inhogoes edited this page May 8, 2026 · 2 revisions

9.1 - O que é Observabilidade?

Observabilidade é a capacidade de entender o estado interno de um sistema a partir dos dados que ele produz. No contexto de TI, isso significa conseguir responder perguntas como: "por que a aplicação está lenta?", "qual componente causou o erro?", "o que mudou antes da falha?".

O Elastic Stack organiza a observabilidade em torno de três tipos de dados, que a comunidade chama de os três pilares da observabilidade:

Pilar O que é Exemplos
Logs Registros textuais de eventos gerados por sistemas e aplicações Erros de aplicação, eventos de sistema, logs de acesso web
Métricas Valores numéricos que representam o estado de um sistema ao longo do tempo CPU, memória, latência de requisições, número de erros por minuto
Traces Rastreamento do caminho percorrido por uma requisição dentro de um sistema distribuído Uma chamada HTTP que passa por API Gateway → serviço A → banco de dados → serviço B

A correlação entre os três pilares é o que diferencia observabilidade de simples monitoramento. No Elastic Stack, é possível partir de um spike de erros nos logs, identificar a transação específica no APM e correlacionar com um pico de CPU nas métricas — tudo na mesma interface.

9.2 - Componentes de Observabilidade no Kibana

9.2.1 - Logs

O módulo de Logs do Kibana oferece uma interface dedicada para explorar e analisar logs em tempo real. Diferentemente do Discover — que é uma ferramenta genérica — o módulo de Logs é otimizado para o fluxo de trabalho de análise de logs: navegação temporal, filtragem por campos comuns (host, serviço, nível de log) e correlação com outros dados de observabilidade.

Funcionalidades principais:

  • Streaming de logs em tempo real com atualização automática
  • Filtros rápidos por host.name, service.name, log.level e outros campos ECS (Elastic Common Schema)
  • Destacar palavras-chave específicas para facilitar a leitura
  • Navegar para o contexto de um log — ver os eventos antes e depois de um evento de interesse
  • Integração direta com APM: a partir de uma linha de log, é possível navegar para a transação correspondente

Caminho: Menu → Observability → Logs → Stream

9.2.2 - Infrastructure

O módulo de Infrastructure oferece uma visão unificada da saúde da infraestrutura — hosts, containers, pods Kubernetes e serviços — em um único lugar.

Funcionalidades principais:

  • Inventory view: lista todos os hosts e containers monitorados com seus indicadores de saúde (CPU, memória, tráfego de rede). Permite ordenar pelo recurso mais consumido e identificar gargalos rapidamente.
  • Metrics Explorer: cria gráficos ad-hoc de qualquer métrica disponível — sem precisar criar uma visualização no Kibana. Útil para investigações pontuais.
  • Host details: ao clicar em um host específico, exibe um painel completo com todas as métricas daquele host, incluindo séries temporais das últimas horas.
  • Alertas de infraestrutura: configura alertas quando uma métrica ultrapassa um threshold — como CPU acima de 90% por mais de 5 minutos.

Caminho: Menu → Observability → Infrastructure

9.2.3 - APM (Application Performance Monitoring)

O APM é o componente de observabilidade focado em aplicações. Ele coleta dados sobre o desempenho interno das aplicações — tempo de resposta, erros, dependências externas — e os exibe no Kibana de forma que seja fácil identificar onde está o gargalo.

O que o APM coleta:

  • Transactions: cada requisição HTTP, job em background ou operação que o agente rastreia. Exibe o tempo total, o breakdown por componente (banco de dados, chamadas externas, renderização de templates) e a taxa de erros.
  • Traces: o caminho completo de uma requisição em um sistema distribuído. Se a requisição passa por múltiplos serviços, o APM consolida o trace de todos eles em uma única visualização chamada de waterfall.
  • Errors: exceções capturadas pela aplicação com stack trace completo, agrupadas por tipo e frequência.
  • Metrics: métricas de runtime da aplicação — uso de heap da JVM, garbage collection, threads ativas.

Arquitetura do APM:

Aplicação + Agente APM
        ↓
    APM Server (porta 8200)
        ↓
   Elasticsearch
        ↓
     Kibana (APM UI)

O agente APM é uma biblioteca instalada dentro da aplicação. Ele coleta os dados automaticamente (sem necessidade de instrumentação manual na maioria dos casos) e os envia para o APM Server, que os processa e indexa no Elasticsearch.

Linguagens suportadas: Python, Java, Node.js, Go, Ruby, .NET, PHP, iOS, Android, JavaScript (RUM), e mais.

Caminho: Menu → Observability → APM

9.2.4 - Synthetics (Uptime)

O Synthetics monitora a disponibilidade e o desempenho de serviços e aplicações web de forma proativa — ou seja, sem esperar que um usuário real experiencie o problema.

Dois tipos de monitoramento:

  • Lightweight monitors (ping): verificações simples de disponibilidade via HTTP, TCP ou ICMP. Configura-se uma URL e um intervalo, e o Kibana verifica periodicamente se o serviço está respondendo e com qual tempo de resposta.
  • Browser monitors: scripts que simulam a navegação de um usuário real em um site — preenchendo formulários, clicando em botões, navegando entre páginas. Usa o Playwright por baixo. Captura screenshots e vídeos quando uma etapa falha.

Caminho: Menu → Observability → Synthetics

9.2.5 - User Experience (RUM)

O Real User Monitoring (RUM) captura dados de performance diretamente do navegador dos usuários reais que acessam sua aplicação web. Diferentemente do Synthetics — que simula usuários —, o RUM registra o que usuários reais estão experienciando.

Métricas coletadas:

  • Page load time: tempo total de carregamento da página
  • First Contentful Paint (FCP): quando o primeiro conteúdo visível aparece na tela
  • Largest Contentful Paint (LCP): quando o maior elemento visível termina de renderizar — um dos Core Web Vitals do Google
  • Transaction time: tempo de execução de ações do usuário na página (cliques, navegação SPA)
  • JS errors: exceções JavaScript capturadas no frontend, com stack trace

Caminho: Menu → Observability → User Experience

9.2.6 - Alertas

O sistema de alertas de observabilidade do Kibana permite configurar regras que monitoram métricas, logs e dados de APM, disparando notificações quando condições específicas são atendidas.

Tipos de regras disponíveis em Observability:

  • Metric threshold: alerta quando uma métrica (CPU, memória, tráfego) ultrapassa um limite por um período de tempo
  • Log threshold: alerta quando o volume de logs que correspondem a um padrão ultrapassa ou fica abaixo de um limite
  • APM anomaly: alerta quando o machine learning detecta comportamento anômalo em transações APM
  • Uptime/Synthetics: alerta quando um monitor de disponibilidade detecta falha

Canais de notificação: e-mail, Slack, Teams, PagerDuty, webhook HTTP, criação de caso no Elastic Security.

Caminho: Menu → Observability → Alerts → Manage Rules

9.2.7 - Cases

O módulo de Cases permite registrar e acompanhar incidentes e investigações diretamente no Kibana, sem precisar sair para uma ferramenta externa de ticketing.

Funcionalidades:

  • Criar um caso com título, descrição, severidade e tags
  • Adicionar comentários e evidências ao longo da investigação (logs, screenshots, links para dashboards)
  • Associar alertas disparados a um caso específico — criando um histórico da investigação
  • Integração com ferramentas externas: Jira, ServiceNow, Swimlane

Caminho: Menu → Observability → Cases

9.3 - Laboratório 1: instalando e configurando o APM Server

Neste laboratório vamos instalar o APM Server, configurá-lo para se conectar ao cluster Elasticsearch e verificar que ele está recebendo dados corretamente.

Instalando o APM Server 9.4.0

su - elastic
cd /opt/elastic

wget https://artifacts.elastic.co/downloads/apm-server/apm-server-9.4.0-linux-x86_64.tar.gz
tar xzvf apm-server-9.4.0-linux-x86_64.tar.gz
mv apm-server-9.4.0-linux-x86_64 apm-server
cd apm-server

Configurando o apm-server.yml

vi apm-server.yml

Substitua o conteúdo pelas configurações abaixo:

apm-server:
  host: "0.0.0.0:8200"

output.elasticsearch:
  hosts:
    - "https://localhost:9200"
    - "https://localhost:9201"
    - "https://localhost:9202"
  username: "elastic"
  password: "SUA_SENHA_AQUI"
  ssl.verification_mode: "none"

setup.kibana:
  host: "https://localhost:5601"
  ssl.verification_mode: "none"

Em produção, substitua a senha por uma referência ao keystore — o mesmo padrão usado nos Beats. No lab, usamos a senha diretamente para simplificar.

Iniciando o APM Server

cd /opt/elastic/apm-server
./apm-server -e &

O flag -e habilita logs no terminal. Aguarde até ver a mensagem indicando que o APM Server está conectado ao Elasticsearch e ouvindo na porta 8200:

[INFO] Starting apm-server...
[INFO] Listening on: 0.0.0.0:8200

Verificando que o APM Server está funcionando

curl http://localhost:8200/

A resposta deve ser um JSON com informações do servidor, incluindo a versão e o status ok.

9.4 - Laboratório 2: instrumentando uma aplicação Django com o agente APM

Neste laboratório vamos instrumentar uma aplicação Django existente com o agente Python do Elastic APM e verificar os dados chegando no Kibana.

Instalando a aplicação

cd /opt/elastic/
wget https://github.com/BktechBrazil/elasticstacktotal/raw/main/find_search.tar.gz
tar zxfv find_search.tar.gz
cd /opt/find_search/

Criando o ambiente virtual Python

sudo apt install python3-venv python3-pip -y
cd /opt/
python3 -m venv venv
source venv/bin/activate

Usamos python3-venv — compatível com Python 3.10+ (padrão no Ubuntu 22.04 e 24.04). A versão python3.8-venv da wiki anterior é específica para o Python 3.8, que não é mais a versão padrão nessas distribuições.

Instalando as dependências da aplicação

cd /opt/find_search/
pip install -r requirements.txt

Instalando o agente APM

pip install elastic-apm

Configurando o agente no settings.py

vi core/settings.py

Faça as seguintes alterações no arquivo:

1. Adicionar o agente em INSTALLED_APPS:

INSTALLED_APPS = [
    # ... apps existentes ...
    'elasticapm.contrib.django',
]

2. Adicionar o bloco de configuração do APM:

ELASTIC_APM = {
    'SERVICE_NAME': 'find-search-app',
    'SERVER_URL': 'http://localhost:8200',
    'ENVIRONMENT': 'lab',
    'DEBUG': True,  # Necessário para enviar dados com Django em modo debug
}

3. Adicionar o middleware de tracing:

Localize a variável MIDDLEWARE no settings.py e adicione o middleware do APM como primeiro item da lista:

MIDDLEWARE = [
    'elasticapm.contrib.django.middleware.TracingMiddleware',
    # ... middlewares existentes ...
]

O middleware precisa ser o primeiro da lista para capturar o tempo total de cada requisição corretamente.

Iniciando a aplicação

cd /opt/find_search/
python3 manage.py runserver 0.0.0.0:8000

Acesse a aplicação no navegador em http://<IP_DA_MAQUINA>:8000 e navegue por algumas páginas para gerar transações.

Verificando os dados no Kibana

  1. Acesse Menu → Observability → APM
  2. O serviço find-search-app deve aparecer na lista de serviços
  3. Clique no serviço para ver:
    • Transactions: lista das rotas da aplicação com tempo médio de resposta e taxa de erros
    • Dependencies: dependências externas detectadas automaticamente (banco de dados, chamadas HTTP)
    • Errors: exceções capturadas durante a execução
  4. Clique em uma transação específica para ver o trace waterfall — o detalhamento do tempo gasto em cada operação dentro da requisição

O que o agente captura automaticamente no Django

Sem nenhuma instrumentação manual no código, o agente APM captura:

  • Todas as requisições HTTP recebidas pela aplicação
  • Queries de banco de dados (SQLite, PostgreSQL, MySQL) com o tempo de execução
  • Chamadas HTTP externas feitas pela aplicação
  • Renderização de templates Django
  • Exceções não tratadas (status 500)

Clone this wiki locally