Monitoramento de tempo de resposta

Porque é que o tempo de resposta merece um alerta próprio

Os alertas de uptime standard baseiam-se num sinal binário: up ou down. A zona cinzenta no meio – up, mas lento – é onde realmente vive a maioria das falhas modernas. Uma consulta mal configurada à base de dados passa a demorar 4 segundos em vez de 50ms. Uma fuga de memória causa picos de garbage collection. Uma API externa chamada pelo backend começa a oscilar. Nenhum destes casos quebra totalmente o site, mas torna-o inutilizável – e são sinais precoces de uma interrupção que pode ocorrer dentro de uma ou duas horas.

A monitorização do tempo de resposta apanha a lentidão antes de se tornar uma falha. Configuras o limiar por monitor e, quando o tempo de resposta o ultrapassa em vários testes seguidos, recebes um alerta. Antes de o alerta ser disparado, ainda tens margem para investigar, escalar recursos, limitar a chamada problemática ou reverter o deploy que o provocou.

Como funcionam os limites no DiagnoSEO Uptime Monitoring

Cada monitor pode ser configurado com dois parâmetros: rt_threshold_ms e rt_threshold_breaches. O primeiro é o tempo de resposta em milissegundos que consideras aceitável. O segundo indica quantos testes consecutivos têm de o ultrapassar para disparar um alerta. Por defeito, o limite está desligado e o número de ultrapassagens é três.

O design com dois parâmetros protege contra falsos positivos. Jitter de rede acontece. Pausas da garbage collection acontecem. Um pico isolado de 1 segundo quando o normal são 200ms não justifica um pager às 3 da manhã. Mas três respostas seguidas de 1 segundo já sim – é uma degradação persistente, não um piscar de olhos. Escolhe o limite com base no comportamento normal observado mais uma margem confortável: se o p95 é normalmente 400ms, escolhe 1000ms. Se o p95 é 50ms (API interna), escolhe 200ms.

Com o que combina bem

Os alertas de tempo de resposta funcionam melhor combinados com outros sinais do monitor. Uma visão completa: o limite de tempo de resposta indica que o sistema está a degradar-se; o código HTTP revela quando está realmente a falhar; alertas de SSL/domínio referem-se a falhas por relógio; alertas de alteração de DNS apontam para drift de configuração. Juntos, os quatro sinais num só monitor transformam um "funciona ou não funciona" binário numa observabilidade total.

O dashboard também ajuda nisto. Cada monitor exibe um sparkline dos tempos de resposta mais recentes – um indicador visual rápido de padrões de degradação. A vista detalhada mostra médias dos últimos 24h, 7d e 30d. Se veres a média a subir pouco a pouco semana após semana – é um sinal antecipado que merece ser investigado antes de ultrapassar o limite de alerta.

Limites práticos por tipo de site

• Páginas de destino de marketing: 1500ms é razoável. São pesadas em imagens e scripts de tracking; a velocidade absoluta importa menos do que a estabilidade.
• Páginas de produto/categorias de e-commerce: 800-1200ms. Um site e-commerce lento mata conversões; limites mais apertados detetam problemas mais rápido.
• Dashboards de aplicações: 500-800ms. Os utilizadores esperam rapidez. Dashboards lentos fazem o produto parecer avariado.
• APIs públicas: 200-400ms para endpoints simples, mais para cálculos intensivos. Separa-os em tiers.
• Health checks internos de microserviços: 50-100ms. Devem ser quase instantâneos; lentidão quase sempre indica um problema real.

Seja o que for que escolhas, não o faças uma vez e esqueças. Reavalia trimestralmente tendo em conta as tendências que realmente observas. Se continuares a receber alertas que não correspondem a problemas reais – o limite está demasiado apertado. Se houver uma falha sem alerta prévio de limite – estava demasiado largo.

Roteamento de alertas

Os alertas de ultrapassagem de limite seguem pelos mesmos canais dos alertas de down/recover: Email, Telegram, Slack, Discord, SMS. Respeitam o mesmo período de silêncio nocturno. São registados na mesma tabela de alertas. A única diferença é o tipo de evento ("threshold" em vez de "down") e o texto da mensagem – indica o tempo de resposta actual e o limite configurado, por isso vês logo o grau da ultrapassagem.

Configuração

Edita qualquer monitor. No formulário, define "Limite de tempo de resposta (ms)" para o valor pretendido. Opcionalmente ajusta as "ultrapassagens consecutivas" se o valor padrão de 3 não corresponder à tua tolerância. Guarda. A partir do próximo ciclo, cada verificação compara o tempo de resposta com o limite e, após o número definido de ultrapassagens consecutivas, recebes uma notificação.

Perguntas frequentes

• Que métrica de tempo de resposta é registada?

  Time To First Byte (TTFB) — milissegundos entre o envio do pedido e a recepção do primeiro byte da resposta. Mais o tempo total de download da resposta completa. O TTFB é a métrica individual mais útil para a saúde do servidor.

• Qual é um "bom" tempo de resposta?

  Depende da localização e do conteúdo. Para um site estático com CDN: abaixo de 100ms é excelente, abaixo de 300ms é aceitável. Para aplicações dinâmicas: abaixo de 500ms é bom, abaixo de 1000ms aceitável, acima de 2000ms parece lento. Compara com a tua base histórica em vez de números absolutos.

• Posso receber um alerta quando o tempo de resposta ultrapassar o limite?

  Sim. Cada monitor tem um limite opcional de tempo de resposta. Se 3 verificações consecutivas ultrapassarem o limite, recebes um alerta de "resposta lenta". O requisito de 3 verificações evita falsos alarmes causados por falhas de rede pontuais.

• De onde é medido o tempo de resposta?

  A partir dos nossos 13 pontos geográficos de verificação (Europa, América do Norte, Ásia, América do Sul, Oceânia). Para monitorização single-region, os tempos vêm da região mais próxima. Para multi-region, cada região é medida independentemente — útil para detetar problemas de CDN regionais.

• O dashboard mostra tendências do tempo de resposta?

  Sim — média móvel de 30 dias, máximos/mínimos diários e percentis (p50, p95). Útil para planeamento de capacidade: se o p95 subir de 800ms para 1500ms num mês, os teus servidores estão sobrecarregados mesmo que o uptime % se mantenha nos 100%.