Monitoramento Web, HTTP e APIs

ICMP responde infraestrutura; HTTP responde aplicação

Um servidor pode responder ping enquanto o site retorna HTTP 500, o certificado expirou ou o login deixou de funcionar. Monitoramento Web aproxima a observabilidade da experiência real consumida pelo usuário.

Web scenario executa uma sequência de passos

Um cenário pode representar uma página única ou uma sequência HTTP. Cada step possui URL, timeout, códigos esperados e conteúdo obrigatório. Isso permite validar uma jornada simples em vez de verificar apenas se a porta TCP está aberta.

HTTP agent é ideal para endpoints e APIs

Itens HTTP agent consultam recursos HTTP/HTTPS sem exigir agente instalado no alvo. Eles podem buscar JSON, texto, métricas e respostas de APIs e depois alimentar dependent items por preprocessing.

Escolha pelo problema

Web scenario é natural para uma sequência de páginas e disponibilidade sintética. HTTP agent é mais flexível para API, payload, headers, autenticação e coleta estruturada. Em muitos projetos ambos coexistem.

200 não significa necessariamente serviço saudável

Um endpoint pode responder 200 com uma página de erro funcional, mensagem de manutenção ou JSON indicando falha. Valide status HTTP e também conteúdo ou campos relevantes da resposta.

Conteúdo esperado confirma semântica mínima

Web steps podem exigir uma string ou padrão na resposta. Isso ajuda a detectar situações em que o servidor responde, mas entrega conteúdo incorreto. Evite textos frágeis que mudam frequentemente por razões cosméticas.

Tempo de resposta deve ser monitorado como série temporal

Disponibilidade binária não mostra degradação progressiva. Acompanhar tempo de resposta permite detectar aumento de latência antes da indisponibilidade total e criar baseline por aplicação.

Uma URL saudável depende de resolução

Falha de DNS pode tornar um serviço indisponível mesmo com aplicação e servidor intactos. Quando DNS é crítico, monitore resolução separadamente e mantenha o teste HTTP usando o mesmo caminho que o usuário utiliza.

HTTPS adiciona uma camada operacional crítica

Expiração de certificado, cadeia inválida, hostname incorreto e problemas de negociação TLS podem interromper o serviço. Certificados devem ser monitorados antes da data de expiração e não apenas quando o navegador começa a falhar.

Alerta antecipado evita incidentes previsíveis

Crie níveis de antecedência coerentes, por exemplo informativo em 60 dias, warning em 30 e high em 7, ajustando à política da organização. O objetivo é transformar expiração de certificado em tarefa planejada, não incidente.

Redirecionamentos fazem parte da jornada

HTTP 301 e 302 podem ser comportamento esperado ou sinal de erro de configuração. Defina se o monitoramento deve seguir redirects e valide o destino final quando ele for relevante.

Headers carregam estado operacional

Authorization, Content-Type, Accept e headers customizados são comuns em APIs. Também é possível validar informações de resposta indiretamente por conteúdo e comportamento. Credenciais nunca devem ser gravadas em texto aberto sem necessidade.

Teste autenticado mede uma camada mais real

Endpoints protegidos podem exigir Basic, token, bearer ou outros mecanismos suportados pelo desenho do item. Segredos devem ser centralizados em macros secretas/vault quando possível e com menor privilégio necessário.

Uma resposta JSON é matéria-prima para dependent items

Em vez de consultar uma API dez vezes para dez campos, faça uma coleta master e extraia múltiplos valores com JSONPath. Isso reduz requests, autenticações e carga sobre o sistema monitorado.

Transforme payload em métricas operacionais

JSONPath, regex, JavaScript, conversão e validação permitem transformar respostas em valores úteis. A lógica deve permanecer simples e testável; parsing excessivamente complexo pode se tornar gargalo e dificultar troubleshooting.

Uma chamada pode gerar dezenas de métricas

Dependent items permitem armazenar apenas os campos relevantes do payload. O master pode ter retenção mínima enquanto métricas derivadas possuem history e trends adequadas.

Health endpoint precisa representar dependências reais

Um /health que sempre retorna 200 porque apenas o processo está vivo não prova que banco, fila ou storage funcionam. Quando possível, diferencie liveness de readiness e monitore dependências críticas separadamente.

O teste simula um usuário mínimo

Monitoramento sintético executa requisições controladas em intervalos regulares. Ele não substitui Real User Monitoring, mas fornece uma referência repetível para disponibilidade e latência mesmo quando não há usuários ativos.

Onde o teste roda muda o que ele mede

Um teste executado no mesmo datacenter mede principalmente a aplicação. Um Proxy em filial mede também WAN, DNS e caminho regional. Para serviços externos, múltiplos pontos de observação podem separar falha local de indisponibilidade real.

Web scenarios podem ser executados por Proxy

Executar testes HTTP a partir de proxies distribuídos permite observar experiência por região ou filial. Isso é particularmente útil quando usuários de locais diferentes percorrem caminhos de rede distintos.

Latência precisa de contexto temporal

100 ms pode ser normal para um serviço externo e anormal para uma API local. Use histórico, percentis externos quando disponíveis e faixas por aplicação. Limites copiados entre sistemas geram ruído.

Timeout é uma política de experiência

Um timeout muito alto demora a detectar falha; muito baixo gera falso positivo em operações legítimas. Defina o limite com base no comportamento esperado e no impacto para o usuário.

Intervalo define resolução e custo

Testar a cada 10 segundos detecta mais rápido, mas multiplica requests e armazenamento. Serviços críticos podem justificar frequência alta; páginas institucionais talvez não. A frequência deve acompanhar o objetivo de detecção.

Uma amostra ruim nem sempre é incidente

Triggers podem exigir múltiplas falhas ou usar funções temporais para reduzir alertas por jitter transitório. Porém excesso de tolerância aumenta tempo de detecção. Ajuste sensibilidade conforme criticidade.

Recuperação também deve ser estável

Se a aplicação oscila entre sucesso e falha, recovery imediato pode causar flapping. Histerese e janelas adequadas podem exigir estabilidade antes de encerrar o incidente.

O teste sintético pode alimentar disponibilidade de serviço

Triggers derivadas de web monitoring podem ser associadas a Services por problem tags. Assim a indisponibilidade percebida pelo teste HTTP pode contribuir para cálculo de SLI/SLA.

Dependência SaaS também precisa ser observada

Aplicações modernas dependem de gateways, APIs de terceiros, autenticação e provedores externos. Monitore endpoints essenciais para separar falha interna de indisponibilidade de fornecedor.

Monitoramento não deve causar bloqueio

APIs podem impor rate limiting. Frequência excessiva, múltiplos proxies ou endpoints repetidos podem consumir quota. Prefira coleta master e respeite limites do provedor.

Não armazene respostas gigantes sem finalidade

HTML completo e JSON extenso podem aumentar banco e preprocessing. Extraia os campos necessários e mantenha history do payload master curta ou desabilitada quando o desenho permitir.

Resposta de API pode conter segredo ou PII

Antes de armazenar payload bruto, verifique se contém tokens, dados pessoais ou informações confidenciais. Observabilidade não deve criar uma nova base de dados sensíveis por acidente.

GET não é a única operação possível

HTTP agent pode trabalhar com diferentes métodos conforme necessidade. Testes que alteram estado exigem extremo cuidado. Em produção, prefira endpoints idempotentes e dedicados à observabilidade.

Nunca transforme monitoramento em transação destrutiva

Se uma jornada exige POST, use conta e dados de teste controlados. Não crie pedidos, pagamentos ou registros reais a cada execução. Synthetic monitoring precisa ser seguro e reversível.

Identifique tráfego de monitoramento

Um User-Agent próprio facilita separar requests do Zabbix em logs, WAF, CDN e analytics. Isso ajuda troubleshooting e evita interpretar tráfego sintético como usuário real.

O caminho externo pode incluir mais que o servidor

CDN, reverse proxy, WAF e load balancer podem responder antes da aplicação. Um teste externo mede o serviço entregue; um teste interno ajuda isolar backend. Os dois pontos respondem perguntas diferentes.

Teste a experiência e os componentes

Combine HTTP externo, endpoint interno, métricas do servidor, banco, fila e rede. Se o teste externo falha e o interno funciona, investigue DNS/CDN/WAF/rede. Se ambos falham, a causa provavelmente está mais próxima da aplicação.

Conteúdo pode detectar falha que infraestrutura não vê

Uma aplicação pode retornar “temporariamente indisponível” dentro de HTTP 200. Validação de conteúdo, JSONPath ou valor de campo permite detectar falhas sem depender exclusivamente do status code.

Mudança de contrato precisa aparecer no monitoramento

Se uma API muda de v1 para v2, itens e preprocessing podem quebrar mesmo com endpoint disponível. Monitore campos essenciais e trate unsupported como sinal de mudança de contrato.

Monitoramento Web deve ser testado contra falhas conhecidas

Simule DNS inválido, HTTP 500, timeout, certificado próximo da expiração, conteúdo ausente e token inválido em laboratório. Um monitor que nunca foi testado contra falha pode estar apenas confirmando o caminho feliz.

Um site é uma sequência de dependências

USUÁRIO / PROXY
      │
      ▼
     DNS
      │
      ▼
 TCP :443
      │
      ▼
     TLS
      │
      ▼
 CDN / WAF / LB
      │
      ▼
 APLICAÇÃO
      │
 ┌────┼─────┐
 ▼    ▼     ▼
DB   CACHE  FILA

HTTP 200 sozinho não valida toda essa cadeia.

Exemplo de jornada sintética

SCENARIO: Portal corporativo

Step 1 — Home
GET https://portal.exemplo.com/
Expected status: 200
Required content: "Portal"

Step 2 — Login page
GET https://portal.exemplo.com/login
Expected status: 200
Required content: "Entrar"

Step 3 — Health API
GET https://portal.exemplo.com/api/health
Expected status: 200
Required content: "ok"

Interval:
60s

Timeout:
definido conforme SLO da aplicação

Uma chamada, várias métricas

MASTER ITEM
GET /api/status

Resposta:
{
  "status": "ok",
  "db_ms": 12,
  "queue": 4,
  "workers": 8,
  "version": "3.7.2"
}

DEPENDENT ITEMS

app.status
JSONPath: $.status

app.db.latency
JSONPath: $.db_ms

app.queue
JSONPath: $.queue

app.workers
JSONPath: $.workers

app.version
JSONPath: $.version
+ discard unchanged with heartbeat

O que cada falha sugere?

Falha global ou falha regional?

               APLICAÇÃO
                   ▲
        ┌──────────┼──────────┐
        │          │          │
     PROXY RJ   PROXY SP   PROXY MG
        │          │          │
       FAIL        OK         OK

Leitura provável:
→ aplicação não está globalmente indisponível
→ investigar rota, DNS, CDN, ISP ou caminho do RJ

Se RJ/SP/MG falham simultaneamente:
→ aumenta a evidência de falha central/global

Expiração deve virar manutenção planejada

Limiares são exemplo operacional e devem seguir a política de renovação da organização.

Separe indisponibilidade de degradação

DISPONIBILIDADE
- cenário falhou repetidamente
- status HTTP inesperado
- conteúdo obrigatório ausente

PERFORMANCE
- response time acima do baseline
- DB latency da health API elevada

SEGURANÇA OPERACIONAL
- certificado próximo da expiração

CONTRATO
- trigger de indisponibilidade
  → problem tag service=portal
  → Service
  → SLA / SLI

“HTTP 200 = tudo certo” é um dos erros clássicos

Monitorar uma API de ponta a ponta

Prove que o monitor detecta cada classe de falha

Antes de confiar no monitoramento Web

Base factual

Conteúdo estruturado sobre recursos nativos do Zabbix 7.4 para Web monitoring, Web scenarios, HTTP agent, preprocessing, dependent items, proxies, triggers, Services e SLA. Os modelos de monitoramento sintético, observação multiponto, matrizes de diagnóstico, arquitetura em camadas, laboratórios e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Além de Web scenarios e HTTP agent, a linha atual oferece Browser items para monitoramento sintético em nível de navegador. Use o tipo mais simples que responda à pergunta operacional.