Você conhece aquela sensação de acordar às 3h da manhã com um alerta crítico de monitoramento, correr para o computador e descobrir que era um falso alarme? Se sua resposta é “sim, toda semana”, você não está sozinho.

Segundo dados da Gartner, equipes de TI perdem até 30% do tempo de trabalho investigando alertas que não representam problemas reais. Isso não é apenas frustrante — é caro, prejudica a produtividade e, pior ainda, cria a famosa “fadiga de alertas” que faz sua equipe ignorar notificações realmente críticas.

A boa notícia? O PRTG Network Monitor oferece recursos avançados de configuração de alertas que, quando bem implementados, eliminam praticamente todos os falsos positivos. Neste guia completo, vou mostrar exatamente como fazer isso.

Por Que Falsos Positivos Acontecem (e Por Que São Tão Perigosos)

Antes de mergulharmos na configuração, é importante entender por que falsos positivos acontecem:

Causas comuns:

• Thresholds (limites) configurados de forma muito sensível
• Falta de dependências entre sensores
• Ausência de períodos de confirmação antes do alerta
• Não considerar manutenções programadas
• Picos momentâneos normais interpretados como falhas

O perigo real: Quando sua equipe recebe dezenas de alertas falsos por semana, ela naturalmente começa a ignorar notificações. E quando o problema real acontece? Ninguém dá atenção até ser tarde demais.

Uma empresa de e-commerce que atendemos perdeu R$ 85 mil em vendas porque um servidor de pagamento caiu durante 4 horas. O alerta foi enviado, mas a equipe ignorou achando que era mais um falso positivo. Isso não pode acontecer com você.

Passo 1: Entendendo os Tipos de Alertas no PRTG

O PRTG trabalha com estados de sensores que disparam notificações. Vamos entender cada um:

Estados de Sensores:

• Up (Verde): Tudo funcionando normalmente
• Warning (Amarelo): Atenção necessária, mas não é crítico
• Down (Vermelho): Falha confirmada, ação imediata necessária
• Unusual (Laranja): Comportamento anormal detectado
• Paused (Cinza): Sensor pausado manualmente

A configuração inteligente depende de entender que:

1. Nem todo “Down” precisa acordar alguém às 3h da manhã
2. Alguns “Warning” são mais críticos que certos “Down”
3. Contexto é tudo: um servidor de backup pode ficar “Down” por 10 minutos sem problema, mas um servidor de e-commerce não aguenta 30 segundos

Passo 2: Configurando Thresholds Dinâmicos

A maioria dos profissionais de TI comete o mesmo erro: define um valor fixo como limite. Por exemplo: “alerta quando CPU passar de 80%”.

O problema: Em servidores reais, 80% de CPU pode ser normal às segundas-feiras às 9h (quando todo mundo volta do fim de semana), mas é crítico às 3h da madrugada.

A solução: Thresholds dinâmicos baseados em baseline.

Como Implementar:

1. Estabeleça uma baseline (linha de base):

1. No sensor desejado, clique em "Historic Data"
2. Analise 30 dias de dados
3. Identifique padrões: horários de pico, dias específicos
4. Anote os valores "normais" de pico

2. Configure limites inteligentes:

Para CPU, por exemplo:

• Warning: 15% acima da média histórica de pico
• Down: 35% acima da média histórica de pico
• Tempo de confirmação: 5 minutos consecutivos

Na prática, se seu servidor normalmente opera a 40-60% de CPU com picos de 75%, configure:

• Warning: 90% por 5 minutos
• Down: 95% por 10 minutos

3. Use limites diferentes por horário:

No PRTG, você pode usar schedules (agendamentos) para ter thresholds diferentes:

• Horário comercial (8h-18h): Limites mais tolerantes
• Fora do horário (18h-8h): Limites mais rigorosos (qualquer anomalia é suspeita)

Exemplo Prático de Configuração:

Sensor: Windows CPU Load
├── Configuração Padrão
│   ├── Warning: > 85% por 5 minutos
│   └── Down: > 95% por 10 minutos
├── Schedule "Horário Comercial" (Seg-Sex 8h-18h)
│   ├── Warning: > 90% por 10 minutos
│   └── Down: > 97% por 15 minutos
└── Schedule "Madrugada" (0h-6h)
    ├── Warning: > 70% por 3 minutos
    └── Down: > 85% por 5 minutos

Passo 3: Criando Dependências de Sensores (Game Changer)

Este é o recurso mais subestimado do PRTG e que elimina 70% dos falsos positivos.

O cenário: Você tem 50 sensores monitorando aplicações em 10 servidores conectados a um switch principal. O switch cai. O que acontece?

Sem dependências: 50 alertas simultâneos chegam. Sua equipe entra em pânico tentando entender o que está acontecendo.

Com dependências: 1 alerta informando que o switch principal caiu. Todos os outros sensores entram em modo “Paused by dependency”.

Como Configurar Dependências:

Conceito: Estabeleça uma hierarquia lógica de dependências. Se o elemento “pai” cai, os “filhos” não devem gerar alertas redundantes.

Hierarquia típica:

Internet
  └── Firewall
      └── Core Switch
          ├── Switch Piso 1
          │   ├── Servidor Web 1
          │   ├── Servidor Web 2
          │   └── Impressora 101
          └── Switch Piso 2
              ├── Servidor BD 1
              └── Servidor BD 2

Passo a passo:

1. Identifique sua estrutura de dependências
   • Desenhe um diagrama da sua rede
   • Identifique pontos únicos de falha
   • Estabeleça relações pai-filho
2. Configure no PRTG:

Para cada sensor:
1. Vá em Settings → Sensor Settings
2. Seção "Dependencies"
3. Marque "Use parent"
4. Ou selecione "Select a sensor" para dependência específica
5. Escolha "Pause sensor if dependency is not in Up status"

Exemplo prático:

Para o “Servidor Web 1”:

• Dependência master: Ping do Core Switch
• Configuração: Se Core Switch = Down → Pausar sensor por 5 minutos
• Resultado: Você recebe 1 alerta do switch, não 10 alertas dos servidores

Dependências Avançadas:

Você pode criar dependências mais complexas:

Dependência de múltiplos sensores: “Alerte apenas se servidor DOWN E link de internet UP” (Elimina alertas durante manutenções programadas de infraestrutura)

Dependência de horário + sensor: “Alerte sobre backup apenas se falhar E estiver dentro da janela de backup”

Passo 4: Agendamento de Notificações (Schedules)

Nem toda notificação precisa ser enviada imediatamente para todos. O PRTG permite criar políticas sofisticadas de notificação.

Estratégia de Escalonamento:

Nível 1 – Notificações Imediatas (Critical):

• Servidores de produção críticos
• Firewalls e segurança
• Sistemas de pagamento
• Links principais de internet

Nível 2 – Notificações em 15 minutos (High):

• Servidores de aplicações não-críticas
• Links de backup
• Serviços internos importantes

Nível 3 – Notificações apenas em horário comercial (Medium):

• Impressoras
• Dispositivos de usuário
• Serviços secundários

Como Configurar Schedules:

1. Criar Schedule personalizado:

Setup → Account Settings → Schedules → Add Schedule
Nome: "Alertas Somente Horário Comercial"
┌─────────────────────────────────────────┐
│ Segunda a Sexta: 08:00 - 18:00         │
│ Sábado: Desativado                      │
│ Domingo: Desativado                     │
│ Feriados: Usar lista "BR Holidays"     │
└─────────────────────────────────────────┘

2. Aplicar ao sensor:

Sensor → Settings → Notifications
┌──────────────────────────────────────────────┐
│ ☑ When sensor goes DOWN                     │
│   Notification: "Email to Team"              │
│   Schedule: "Alertas Somente Horário Comerc"│
│                                              │
│ ☑ When sensor goes DOWN for 30+ minutes     │
│   Notification: "SMS to Manager"             │
│   Schedule: "Always"                         │
└──────────────────────────────────────────────┘

Resultado: Impressoras com problema geram email apenas durante expediente, mas se ficarem 30min+ down, o gestor recebe SMS até nos fins de semana.

Passo 5: Templates de Alertas por Criticidade

Padronização é essencial. Crie templates para cada tipo de criticidade.

Template 1: Sensores Críticos (Produção 24/7)

Características:

• Tempo de confirmação: 2 minutos
• Escalonamento: Imediato → 5min → 15min
• Canais: Email + SMS + Teams
• Recuperação: Notificar imediato

Aplicar em:

• Servidores web/app de produção
• Bancos de dados principais
• Firewalls
• Links de internet principais

Template 2: Sensores Importantes (Horário Comercial)

Características:

• Tempo de confirmação: 5 minutos
• Escalonamento: 10min → 30min
• Canais: Email + Teams
• Schedule: Seg-Sex 7h-19h
• Recuperação: Resumo diário

Aplicar em:

• Servidores de aplicações internas
• Serviços de autenticação
• Storages de backup

Template 3: Sensores Monitorados (Informacional)

Características:

• Tempo de confirmação: 15 minutos
• Escalonamento: Apenas relatório semanal
• Canais: Email (resumo)
• Schedule: Sempre, mas sem urgência

Aplicar em:

• Dispositivos de usuário
• Impressoras
• Switches de acesso

Como Criar Templates:

Setup → Account Settings → Notification Templates

Template: "CRÍTICO - Produção 24/7"
├── Trigger: Down status
├── Delay: 2 minutes
├── Actions:
│   ├── 0min: Email "ti@empresa.com.br"
│   ├── 0min: Teams channel "Alertas Críticos"
│   ├── 5min: SMS "Coordenador TI"
│   └── 15min: SMS "Gerente TI"
├── Schedule: Always
└── Recovery: Notify immediately

Passo 6: Configuração Prática de Notificações

O PRTG suporta diversos canais de notificação. Vamos configurar os mais importantes.

Email Inteligente:

Configuração básica:

Setup → System Administration → Notification Delivery
┌────────────────────────────────────────────┐
│ Email Settings                             │
│ SMTP Server: smtp.office365.com           │
│ Port: 587                                  │
│ Encryption: TLS                            │
│ From: prtg@globaldata.com.br              │
│ Authentication: OAuth 2.0 (M365)           │
└────────────────────────────────────────────┘

Email template customizado:

Subject: [%sitename] %device %name %status desde %lastup

Prioridade: %priority
Sensor: %name
Device: %device
Status: %status
Desde: %lastup
Mensagem: %message

Valor atual: %value
Histórico: %linkchart

Ações:
- Ver sensor: %linkdevice
- Ver histórico: %linkhistory
- Pausar: %linksensorpause

---
Enviado por PRTG - Global Data

Integração Microsoft Teams:

Webhook configuration:

1. No Teams:

Channel → Connectors → Incoming Webhook
Nome: "PRTG Alertas Críticos"
Copiar URL do webhook

2. No PRTG:

Setup → Account Settings → Notifications → Add
Tipo: "Execute HTTP Action"
URL: [webhook do Teams]
Method: POST
Content Type: application/json
Body:
{
  "@type": "MessageCard",
  "@context": "http://schema.org/extensions",
  "summary": "PRTG Alert: %device - %name",
  "themeColor": "FF0000",
  "sections": [{
    "activityTitle": "🚨 **%device - %name**",
    "facts": [{
      "name": "Status:",
      "value": "%status"
    }, {
      "name": "Desde:",
      "value": "%lastup"
    }, {
      "name": "Valor:",
      "value": "%value"
    }],
    "markdown": true
  }],
  "potentialAction": [{
    "@type": "OpenUri",
    "name": "Ver no PRTG",
    "targets": [{
      "os": "default",
      "uri": "%linkdevice"
    }]
  }]
}

Dica Extra: Período de Manutenção

Antes de fazer manutenções, sempre pause os sensores relevantes:

Sensor → Pause
┌────────────────────────────────────┐
│ Pause Duration:                    │
│ ○ Indefinite                       │
│ ● Until: 2026-01-13 23:59          │
│                                    │
│ Message: "Manutenção servidor DB"  │
└────────────────────────────────────┘

Ou use Maintenance Windows automáticas para janelas recorrentes:

Setup → Schedules → Add Maintenance Window
Nome: "Backup Semanal"
┌────────────────────────────────────┐
│ Todos os domingos: 02:00 - 06:00  │
│ Aplicar aos grupos:                │
│   ☑ Servers/Backup                │
└────────────────────────────────────┘

Troubleshooting: Problemas Comuns

Problema 1: Ainda recebo muitos alertas

Diagnóstico:

Reports → Top Lists → Top 100 Sensors by Alarms

Identifique os sensores com mais alertas e ajuste thresholds.

Solução:

• Aumente tempo de confirmação de 2min para 5min
• Revise se o baseline está correto
• Verifique se há dependências faltando

Problema 2: Alertas não estão chegando

Checklist:

• Notification settings do sensor estão habilitadas?
• O schedule está ativo no horário atual?
• O servidor SMTP está configurado corretamente?
• Teste manual: “Send Test Notification”

Problema 3: Muitos alertas de recuperação

Se você recebe muitos “Sensor voltou ao normal”, pode ser flapping (oscilação).

Solução:

Sensor Settings → Scanning Interval
├── Interval: Aumentar para 5 minutos
└── If error, retry: 2 times antes de marcar Down

Conclusão: Da Fadiga de Alertas para Monitoramento Inteligente

Configurar alertas inteligentes no PRTG não é apenas uma questão técnica — é estratégica. Uma configuração bem feita:

✅ Reduz falsos positivos em até 90% ✅ Aumenta a confiança da equipe nas notificações ✅ Melhora o tempo de resposta a incidentes reais ✅ Diminui o stress e burnout da equipe de TI ✅ Proporciona visibilidade real do ambiente

A diferença entre um ambiente monitorado e um ambiente inteligentemente monitorado pode ser a diferença entre dormir tranquilo ou acordar às 3h da manhã com um problema que poderia ter sido prevenido.

Precisa de Ajuda para Implementar PRTG com Configuração Otimizada?

A Global Data é revenda autorizada Paessler PRTG e parceira certificada. Nossa equipe implementa PRTG em ambientes de médio e grande porte há mais de 10 anos, com configurações otimizadas, integradas e prontas para uso.

Nossos serviços incluem:

• Implementação completa do PRTG
• Configuração de alertas inteligentes sem falsos positivos
• Integração com Microsoft Teams, Slack, sistemas de tickets
• Criação de dashboards executivos
• Treinamento da equipe técnica
• Suporte contínuo e otimização

Fale com nossos especialistas certificados →

---

Links Relacionados:

• PRTG Network Monitor – Revenda Autorizada Paessler
• Serviços de Monitoramento NOC 24/7
• Consultoria e Estratégia de TI
• 5 Métricas de Rede que Toda Empresa Deveria Monitorar