Lógica do Sistema
O TraceLog opera com base na relação entre e .
Sondas (Sensores)
Pontos de origem dos testes. Podem ser o próprio servidor da aplicação ou Sondas Remotas instaladas em infraestruturas externas.
Alvos
Destinos monitorados (ex: domínios, endereços IP). O TraceLog mapeia o caminho exato até eles.
Eventos
Notificações geradas automaticamente quando o sistema detecta mudanças de roteamento (hops) ou desvios inesperados.
Fluxo de Operação
Registrar Alvos
Adicione os destinos que você deseja monitorar. Use nosso banco de dados de "Alvos Conhecidos" para importar rapidamente serviços populares.
Gerenciar AlvosGerar SENSOR_KEY
Cada sonda remota precisa de uma chave única para autenticação. Gere-as no menu Rede > Sondas.
Gerenciar SondasImportação em Lote
Economize tempo utilizando a ferramenta de importação em lote. Você pode colar uma lista de IPs/Hosts ou selecionar serviços populares (Google, Cloudflare, etc.) para monitoramento imediato.
Ir para Alvos e ImportaçãoImplantação de Sondas
Use o container Docker para servidores Linux e, se sua operação já utiliza o Agente NOC, consuma a telemetria do TraceLog pela compatibilidade opcional entre os produtos.
Guia TécnicoGestão de Equipes
O TraceLog é nativamente multi-equipes, permitindo organizar sua estrutura em diferentes Equipes para isolamento de dados e colaboração.
Isolamento Total
Sondas e Alvos registrados em uma equipe não são visíveis para outras equipes, garantindo privacidade entre projetos ou clientes.
Atribuição de Membros
Convide colaboradores para sua equipe via e-mail. Defina quem pode apenas visualizar ou quem pode gerenciar a infraestrutura.
Gatilhos Inteligentes
Evite "falsos positivos" configurando gatilhos baseados em ocorrências consecutivas e janelas de confirmação — cada alvo responde a três perguntas: chega? chega bem? chega por onde?
Detecção Offline
Defina quantas falhas consecutivas de Ping (100% de perda) devem ocorrer antes de acionar um Alerta Offline.
Recuperação Online
Determine quantos sucessos consecutivos são necessários para considerar o alvo estável e gerar um evento de recuperação.
Degradação de Desempenho
Defina o limiar de latência (ms), o limite de perda (%) e a janela (minutos). A primeira amostra acima de um dos limiares cria um evento suspeito; a janela inteira violando (ou duas sondas concordando) confirma; o evento é marcado como recuperado depois do período de estabilidade sem violação.
Profundidade do traçado (TTL máximo)
Limita quantos saltos a sonda percorre (até 255). É um parâmetro de medição, não um gatilho: o número de saltos passou a ser atributo da Mudança de Rota e o excesso de saltos vira observação, sem alerta.
Janelas de Manutenção
Agende períodos de manutenção para silenciar notificações durante atualizações planejadas. Diferente de desativar um alvo, a janela de manutenção continua coletando telemetria, permitindo analisar o comportamento da rede durante a intervenção, mas sem acionar alertas da equipe.
Como funciona
- As notificações por E-mail/Telegram ficam suspensas.
- Webhooks não são acionados.
- Coleta de telemetria (latência/rota) permanece ativa.
Webhooks Nativos
Integre o TraceLog com qualquer sistema externo. Enviamos um JSON via POST para a URL configurada sempre que um evento relevante ocorre. O campo "event" só emite os 6 tipos vigentes (target_offline, target_online, route_change, final_host_change, routing_loop, performance_degradation).
Segurança HMAC
Cada requisição inclui um cabeçalho "X-Tracelog-Signature" contendo o hash HMAC-SHA256 do payload, assinado com seu Segredo.
{ "event": "performance_degradation", "target": "8.8.8.8", "details": { "metric": "loss", "status": "confirmed" } }Compatibilidade com nomes antigos
Assinaturas com os nomes antigos continuam aceitas e são normalizadas ao salvar: packet_loss e high_latency viram performance_degradation; hop_count_exceeded vira route_change. load_balancing deixou de ser entregável — é observação, não evento — e uma assinatura que só tinha esse tipo é rejeitada com aviso.
Análise e Inteligência
Painel Estratégico
Ganhe visibilidade macro de toda a rede. Uma visão unificada das tendências de performance permite respostas proativas antes que os clientes percebam degradação do serviço.
Diferencial de Saltos
Identifique mudanças silenciosas nos fornecedores de trânsito através do histórico de ASN em cada salto da rota.
Evidências em PDF
Exporte relatórios completos diretamente do Painel. Ideal para abrir chamados com fornecedores de trânsito. O PDF inclui gráficos periódicos, matriz de saltos e o ASN consolidado de cada salto para provar onde a falha ocorreu.
Foco em Troubleshooting
Reduza o MTTR (Tempo Médio de Reparo). Identifique se o problema é local, no fornecedor de trânsito ou no datacenter de destino analisando visualmente a quebra da rota.
Análise Comparativa
A Análise Comparativa mostra o mesmo alvo visto por várias sondas ao mesmo tempo. Como cada sonda observa o destino a partir de uma rede diferente, comparar as curvas revela se a degradação está no destino, no trânsito compartilhado ou dentro da rede de uma única sonda.
1. Selecione o alvo
Escolha o destino no seletor de Alvo. Enquanto nenhum alvo for escolhido, a página exibe apenas a Matriz de Conectividade.
2. Escolha as sondas
Ative ou desative os chips de sonda para controlar quais séries aparecem. Cada sonda mantém uma cor fixa no gráfico, nos cartões de estatísticas e na legenda. Sem nenhum chip selecionado, todas as sondas são exibidas.
3. Escolha a métrica e os filtros
Alterne entre Latência, Jitter, Perda de Pacotes e Saltos. Refine os dados por Versão IP (IPv4/IPv6), Transporte (ICMP/TCP/UDP) e período. O modo Ao Vivo recarrega as séries a cada 30 segundos.
Cartões de estatísticas por sonda
Cada sonda comparada recebe um cartão com a média, o P95 e o pico da métrica selecionada no período, na mesma cor da sua linha no gráfico.
Eventos na linha do tempo
Traços verticais marcam eventos no gráfico. Os chips de resumo contam eventos por tipo — clique em um chip para filtrar a lista e clique em um item em "Últimos eventos" para destacar aquele momento exato no gráfico.
Como interpretar a comparação
- Todas as sondas degradam ao mesmo tempo: o problema está no destino ou em um trecho de trânsito compartilhado por todos os caminhos — escale para o destino ou para a operadora em comum.
- Apenas uma sonda degrada: o problema é local à rede daquela sonda (uplink, peering ou última milha). O destino permanece saudável para todas as outras.
- Sondas diferem em valores absolutos mas se movem juntas: isso é geografia, não um incidente — compare tendências, não milissegundos brutos.
A matriz como porta de entrada
A Matriz de Conectividade lista o score de saúde de cada par alvo e sonda, com os piores pares primeiro. Clique em uma célula para abrir a comparação daquele par exato — o ponto de partida mais rápido quando você não sabe onde procurar.
Abrir Análise ComparativaScore de Saúde
Cada par alvo e sonda recebe um score de saúde de 0 a 100, recalculado sempre que uma nova medição ou verificação de protocolo chega. O score começa em 100 e cada fator abaixo subtrai pontos. Os scores são mantidos separadamente por versão IP e protocolo de transporte, então um problema em IPv6 nunca se esconde atrás de um caminho IPv4 saudável.
Penalidade por perda de pacotes
Cada 1% de perda de pacotes na amostra mais recente remove 1 ponto, com teto de 50 pontos.
Latência acima da linha de base
Quando a latência fica acima da linha de base aprendida, o score perde pontos proporcionalmente ao excesso — o dobro da linha de base remove cerca de 20 pontos, com teto de 25. As linhas de base são aprendidas com as últimas 100 amostras do par (mínimo de 5).
Verificação de protocolo com falha
Uma verificação de saúde com falha (ICMP, TCP connect, HTTP, TLS, DNS ou UDP) remove 35 pontos. Uma verificação bem-sucedida não remove nada.
Normal 71-100
O par opera dentro do seu comportamento habitual.
Degradado 41-70
Degradação mensurável — inspecione o par na Análise Comparativa.
Crítico 0-40
Perda severa, latência sustentada ou verificações falhando — aja agora.
O score reflete o estado mais recente do par, não uma média histórica. As mesmas faixas alimentam a Matriz de Conectividade e a faixa "Críticos agora" do Painel NOC.
Recursos Avançados e Métricas
Cálculo de Jitter Preciso
O TraceLog calcula o Jitter usando o padrão RFC 3550, que representa a diferença média absoluta entre atrasos consecutivos. Isso é crítico para aplicações em tempo real, como VoIP e Streaming de Vídeo, onde a variação importa mais do que a latência absoluta.
Profundidade do traçado e contagem de saltos
A profundidade do traçado (TTL máximo, até 255) define até onde a sonda vai. O número de saltos deixou de ser alerta: viaja como atributo da Mudança de Rota (antes/depois/diferença) e, quando passa da profundidade configurada, fica registrado como observação hop_count_exceeded.
Limites Condicionais
Defina critérios avançados: receba alertas apenas se a latência exceder 200 ms OU a perda de pacotes for maior que 10% por toda a janela configurada, como 5 minutos contínuos. Isso elimina ruído de oscilações transitórias.
Paridade Multi-Protocolo (v4/v6)
Monitore o mesmo alvo via IPv4 e IPv6 simultaneamente a partir da mesma Sonda. Analise diferenças de caminho e compare o desempenho entre protocolos em tempo real.
Inteligência de roteamento (loops vs balanceamento de carga)
O TraceLog distingue automaticamente comportamento de balanceamento de anomalias críticas de roteamento. Repetições consecutivas, padrões em diamante e rotação do salto final no mesmo ASN são observações de balanceamento de carga (ECMP é normal). Só sequências repetidas (A->B->A->B->A->B) são sinalizadas como Loop de Roteamento; o mesmo IP respondendo 10+ vezes é um roteador respondendo pelos TTLs restantes e vira observação repeated_hop.
Hierarquia e coexistência de eventos
Um único traceroute pode gerar mais de um evento quando causas distintas acontecem juntas. Exemplo: se saltos intermediários mudaram e o destino final também mudou, o TraceLog pode emitir Mudança de Rota e Mudança de Host Final. Se apenas o salto final mudou, isso não vira uma Mudança de Rota genérica.
Glossário de Eventos e Critérios de Inteligência
O TraceLog classifica incidentes de rede em seis tipos, organizados em três famílias: disponibilidade (chega?), qualidade (chega bem?) e caminho (chega por onde?). Cada evento é disparado por critérios técnicos específicos e carrega status, confiança e evidência para separar incidentes confirmados de comportamentos suspeitos ou apenas observados.
Disponibilidade — chega?
Perda de 100% (ou o retorno abaixo disso) em N amostras consecutivas, avaliada por sonda e por protocolo. O alvo só aparece offline no mapa quando qualquer par sonda/protocolo está offline.
- Alvo Offline
- Alvo Online
Qualidade — chega bem?
Um único evento de qualidade: latência e/ou perda acima dos limites do alvo. A métrica violada fica em details.metric (latency, loss ou both) e o evento evolui de suspeito para confirmado e recuperado.
- Degradação de Desempenho
Caminho — chega por onde?
Mudança na sequência de ASNs dos saltos intermediários, troca do host final para outro ASN e loop de roteamento por sequência repetida. Balanceamento de carga e excesso de saltos ficam como observações.
- Mudança de Rota
- Mudança de Host Final
- Loop de Roteamento
Confiança, Status e Evidência
Todo evento mantém seu tipo técnico, mas details_json também inclui status, confidence, confidence_level e evidence. Confirmed significa que o sinal foi validado por persistência, critério forte de topologia ou amostras consecutivas. Suspected significa que o sinal é real na amostra, mas ainda precisa de persistência ou outra sonda para ser tratado como definitivo. Recovered marca uma degradação que passou o período de estabilidade sem violar. Observed é comportamento informativo, como balanceamento de carga, que explica a rota sem ser tratado sozinho como incidente.
Alvo Offline
Critério: Detectada perda de 100% de pacotes.
Lógica: O sistema aguarda uma certa quantidade de verificações falhas consecutivas (definidas nos gatilhos) antes de sinalizar o host como inativo. Isso evita alertas de "flap" durante breves instabilidades de rede.
Alvo Online (Recuperação)
Critério: Perda de pacotes cai abaixo de 100% (restauração de conectividade).
Lógica: Acionado quando o host retorna a um estado responsivo. Assim como na detecção offline, respeita um limite de "estabilidade" de verificações bem-sucedidas consecutivas.
Degradação de Desempenho
Critério: latência E/OU perda de pacotes acima dos limites definidos no alvo — o único evento de qualidade (substitui Latência Alta e Perda de Pacotes).
Lógica: A métrica violada fica em details.metric (latency, loss ou both), com os valores medidos, os limiares e os saltos afetados. A perda de 100% não é degradação — é disponibilidade (Alvo Offline). O evento tem ciclo de vida próprio:
- Suspeito: primeira amostra acima do limiar (o que antes era Latência Alta ou Perda de Pacotes). Notificado só se "Também notificar eventos suspeitos" estiver ligado.
- Confirmado: a janela inteira (condition_duration_minutes) viola o limiar — com pelo menos duas amostras e um intervalo real entre elas — ou uma segunda sonda vê a mesma degradação na janela de confirmação. Repetição na mesma sonda não confirma.
- Recuperado: após recovery_stability_minutes sem nenhuma violação.
Mudança de Rota
Critério: a sequência de ASNs (trânsito) dos saltos intermediários mudou — ou IPs intermediários mudaram sem evidência de ASN de que ficaram na mesma operadora. Carrega old_hop_count, new_hop_count e hop_count_delta.
Lógica: Detecta instabilidades de roteamento ou "flapping" quando o trânsito mudou de fato. Severidade info por padrão; sobe para aviso quando existe Degradação de Desempenho ou Alvo Offline do mesmo alvo dentro da janela de confirmação (nos dois sentidos), com o evento correlacionado em details.correlated_event_id. Saltos que trocam de IP dentro do mesmo ASN — mesmo com um salto a mais ou a menos, como em ECMP — são observação de balanceamento, nunca Mudança de Rota; salto privado nunca conta como trânsito e um salto em timeout (???) não é diferença. Se apenas o salto final mudou, é Mudança de Host Final. Se o IP mudou mas o ASN do salto é desconhecido, a Mudança de Rota ainda é registrada, porém só como suspeita. Um destino que para de responder não gera Mudança de Rota; isso é disponibilidade.
Mudanças de Host Final
Critério: mudança no último salto válido com alteração real de destino final/ASN.
Lógica: Usado quando o último salto válido muda para outro ASN (ou ASN desconhecido). Uma única amostra é marcada como suspeita porque traceroute/MTR clássico nem sempre prova que o host final da aplicação mudou; persistência, múltiplas sondas ou concordância de protocolo fortalecem o diagnóstico. Se o destino apenas rotaciona dentro do mesmo ASN, o TraceLog registra uma observação de balanceamento em vez de Mudança de Host Final.
Loop de Roteamento
Prioridade Crítica
Loop de Sequência: O único detector de loop: um padrão de IPs (ex.: A->B->A->B) que se repete 2 ou mais vezes (A-B A-B A-B).
Salto repetido (observação): Um único IP respondendo 10 ou mais vezes no mesmo traçado NÃO é loop — é um roteador respondendo por todos os TTLs restantes (MPLS/NAT). Vira a observação repeated_hop, sem alerta.
Lógica Anti-FP: Faixas de IP privado e repetições consecutivas curtas são suprimidas para evitar falsos positivos de balanceadores internos ou comportamento ECMP.
Observações vs Incidentes
O TraceLog armazena observações técnicas (network_observations) separadas dos eventos acionáveis. Observação nunca gera e-mail, Telegram ou webhook — ela explica o caminho no detalhe da medição. Um sinal vira incidente quando persiste, chega ao destino, afeta checks reais por protocolo ou aparece em múltiplas sondas. Hoje são observações:
- load_balancing — ECMP é normal: padrões diamante, repetições consecutivas, rotação de destino ou de saltos internos dentro do mesmo ASN. Registrado quando "Registrar observações de balanceamento de carga" está ligado no alvo.
- hop_count_exceeded — o destino foi alcançado com mais saltos do que a profundidade do traçado configurada. O número de saltos é atributo da Mudança de Rota; sozinho, não tem ação para o NOC.
- repeated_hop — o mesmo IP respondendo 10 ou mais vezes (o antigo critério de "loop distribuído").
- intermediate_hop_loss — um salto intermediário que descarta ICMP enquanto os saltos seguintes respondem (rate-limit, não perda real).
Resumo da hierarquia de eventos
- Só o último salto mudou: mesmo ASN = observação de balanceamento de carga; ASN/destino final diferente = Mudança de Host Final suspeita até persistir ou aparecer em mais evidências.
- Saltos intermediários mudaram: mesmo caminho de ASN com evidência de ASN = observação de balanceamento; caminho de ASN mudou = Mudança de Rota confirmada; IPs mudaram sem evidência de ASN = Mudança de Rota suspeita.
- O trânsito (caminho de ASN) dos saltos intermediários mudou e o destino final também mudou: Mudança de Rota coexiste com Mudança de Host Final no mesmo teste.
- Loop de roteamento tem prioridade sobre a observação de balanceamento quando a própria rota mostra uma sequência cíclica real (A->B->A->B).
- Mudança de Rota com Degradação de Desempenho ou Alvo Offline do mesmo alvo na mesma janela: a mudança sobe para aviso e aponta o evento correlacionado; os dois continuam eventos separados.
Personalização de Alertas
O TraceLog permite que você seja notificado instantaneamente quando eventos críticos ocorrem, garantindo uma resposta rápida a incidentes de rede.
Canais de E-mail
Configure múltiplos destinos de e-mail separados por vírgula. Ideal para listas de distribuição NOC ou equipes de suporte.
Integração com Telegram
Receba alertas em tempo real no seu celular. Você precisará de um Bot Token (gerado pelo @BotFather) e o Chat ID de destino.
Como testar sua configuração
- Acesse o menu Configurações > Notificações no topo da página.
- Ative o canal desejado (E-mail ou Telegram).
- Preencha os dados necessários.
- Clique no botão "Testar Notificação". O sistema enviará um evento de exemplo imediato.
Critérios de Notificação
- Todos os Eventos: Qualquer alteração detectada gera um alerta.
- Mudança de Rota (Internet): Indica redirecionamento no caminho intermediário da internet pública (trânsito/ASN).
- Degradação de desempenho (qualidade): Latência ou perda de pacotes acima dos limiares do alvo: suspeita na primeira amostra, confirmada quando a janela inteira viola. Balanceamento de carga é observação e nunca notifica.
- Mudança de Host Final (App): Failover de DNS ou migração de servidor quando o destino final realmente mudou para outro ASN/contexto de destino.
- Condições combinadas: Mais de um alerta pode ser gerado a partir do mesmo teste quando causas distintas coexistem.
Resolução de Problemas (Troubleshooting)
A sonda não reporta dados
- Verifique se a SENSOR_KEY no container/agente está correta.
- Certifique-se de que o host tenha acesso à porta 80/443 do servidor TraceLog.
- No Docker, use "docker logs [container_id]" para ver erros de conexão.
Rota Incompleta (Asteriscos)
Isso ocorre quando um roteador intermediário bloqueia o protocolo ICMP ou UDP da sonda. O TraceLog continuará tentando mapear outros saltos para completar a visão geral.
Alvo sempre offline
Verifique se o firewall de destino permite pacotes ICMP (Ping). Algumas infraestruturas (como AWS/Azure) requerem configuração explícita no Security Group.
Perda falsa de pacotes (limitação de taxa)
Alguns hosts (como Cloudflare ou IPs protegidos contra DDoS) descartam pacotes ICMP quando a frequência é alta. Se você observar perda intermitente, tente mudar o protocolo de destino para TCP ou UDP nas configurações de destino.
Compatibilidade com Agente NOC
O Agente NOC é uma camada opcional de compatibilidade. O TraceLog continua responsável por sondas, telemetria, painéis e análise histórica, enquanto o agente pode consumir esses dados para clientes que já o utilizam.
Reimplantação da Sonda
Se você mover um sensor para um novo local ou rede, use a ação "Limpar Histórico" no menu do sensor para redefinir as métricas sem gerar uma nova chave de API.