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 monitorizados (ex: domínios, endereços IP). O TraceLog mapeia o caminho exato até eles.
Eventos
Notificações geradas automaticamente quando o sistema deteta mudanças de encaminhamento (hops) ou desvios inesperados.
Fluxo de Operação
Registar Alvos
Adicione os destinos que deseja monitorizar. Use a nossa base de dados de "Alvos Conhecidos" para importar rapidamente serviços populares.
Gerir AlvosGerar SENSOR_KEY
Cada sonda remota precisa de uma chave única para autenticação. Gere-as no menu Rede > Sondas.
Gerir SondasImportação em Lote
Poupe tempo utilizando a ferramenta de importação em lote. Pode colar uma lista de IPs/Hosts ou selecionar serviços populares (Google, Cloudflare, etc.) para monitorização imediata.
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 Equipas
O TraceLog é nativamente multi-equipa, permitindo organizar a sua estrutura em diferentes Equipas para isolamento de dados e colaboração.
Isolamento Total
Sondas e Alvos registados numa equipa não são visíveis para outras equipas, garantindo privacidade entre projetos ou clientes.
Atribuição de Membros
Convide colaboradores para a sua equipa via email. Defina quem pode apenas visualizar ou quem pode gerir 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?
Deteçã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 a violar (ou duas sondas a concordar) confirma; o evento é marcado como recuperado após o 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 torna-se observação, sem alerta.
Janelas de Manutenção
Agende períodos de manutenção para silenciar notificações durante atualizações planeadas. Diferente de desativar um alvo, a janela de manutenção continua a recolher telemetria, permitindo analisar o comportamento da rede durante a intervenção, mas sem acionar alertas da equipa.
Como funciona
- Notificações por Email/Telegram são suspensas.
- Webhooks não são acionados.
- Recolha de telemetria (latência/rota) permanece ativa.
Webhooks Nativos
Integre o TraceLog com qualquer sistema externo. Enviamos um JSON via POST para o URL configurado sempre que ocorre um evento relevante. 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 pedido inclui um cabeçalho "X-Tracelog-Signature" com o hash HMAC-SHA256 do payload, assinado com o seu Segredo.
{ "event": "performance_degradation", "target": "8.8.8.8", "details": { "metric": "loss", "status": "confirmed" } }Compatibilidade com nomes antigos
Subscrições com os nomes antigos continuam a ser aceites e são normalizadas ao guardar: packet_loss e high_latency passam a performance_degradation; hop_count_exceeded passa a route_change. load_balancing deixou de ser entregável — é observação, não evento — e uma subscrição 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 desempenho permite respostas proativas antes que os clientes percebam degradação do serviço.
Diferencial de Hops
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 tickets junto de 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 Reparação). 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 partilhado 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 apresenta apenas a Matriz de Conectividade.
2. Escolha as sondas
Ative ou desative os chips de sonda para controlar que 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 apresentadas.
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 Em Direto 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 cronologia
Traços verticais marcam eventos no gráfico. Os chips de resumo contam eventos por tipo — clique num chip para filtrar a lista e clique numa entrada em "Últimos eventos" para destacar esse momento exato no gráfico.
Como interpretar a comparação
- Todas as sondas degradam ao mesmo tempo: o problema está no destino ou num troço de trânsito partilhado por todos os caminhos — escale para o destino ou para o operador em comum.
- Apenas uma sonda degrada: o problema é local à rede dessa sonda (uplink, peering ou última milha). O destino permanece saudável para todas as outras.
- As sondas diferem em valores absolutos mas movem-se em conjunto: isso é geografia, não um incidente — compare tendências, não milissegundos em bruto.
A matriz como porta de entrada
A Matriz de Conectividade lista a pontuação de saúde de cada par alvo e sonda, com os piores pares primeiro. Clique numa célula para abrir a comparação desse par exato — o ponto de partida mais rápido quando não sabe onde procurar.
Abrir Análise ComparativaScore de Saúde
Cada par alvo e sonda recebe uma pontuação de saúde de 0 a 100, recalculada sempre que chega uma nova medição ou verificação de protocolo. A pontuação começa em 100 e cada fator abaixo subtrai pontos. As pontuações são mantidas separadamente por versão IP e protocolo de transporte, pelo que um problema em IPv6 nunca se esconde atrás de um caminho IPv4 saudável.
Penalização por perda de pacotes
Cada 1% de perda de pacotes na amostra mais recente remove 1 ponto, com um máximo de 50 pontos.
Latência acima da linha de base
Quando a latência fica acima da linha de base aprendida, a pontuação perde pontos proporcionalmente ao excesso — o dobro da linha de base remove cerca de 20 pontos, com um máximo de 25. As linhas de base são aprendidas com as últimas 100 amostras do par (mínimo de 5).
Verificação de protocolo falhada
Uma verificação de saúde falhada (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 a falhar — atue já.
A pontuação reflete o estado mais recente do par, não uma média histórica. Os mesmos intervalos alimentam a Matriz de Conectividade e a faixa "Críticos agora" do Painel NOC.
Recursos e Métricas Avançadas
Cálculo Preciso de Jitter
O TraceLog calcula o Jitter usando a norma 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 registado 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)
Monitorize 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 encaminhamento (loops vs balanceamento de carga)
O TraceLog distingue automaticamente comportamento de balanceamento de anomalias críticas de encaminhamento. 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 Encaminhamento; o mesmo IP a responder 10+ vezes é um router a responder pelos TTLs restantes e torna-se 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 intermédios mudaram e o destino final também mudou, o TraceLog pode emitir Alteração de Rota e Alteração de Host Final. Se apenas o salto final mudou, isso não vira uma Alteração 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 transporta status, confiança e evidência para separar incidentes confirmados de comportamentos suspeitos ou apenas observados.
Disponibilidade — chega?
Perda de 100% (ou o regresso 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 intermédios, troca do host final para outro ASN e loop de encaminhamento 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, Estado e Evidência
Todo o evento mantém o 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 de 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: Detetada 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 deteçã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. A repetição na mesma sonda não confirma.
- Recuperado: após recovery_stability_minutes sem nenhuma violação.
Alteração de Rota
Critério: a sequência de ASNs (trânsito) dos saltos intermédios mudou — ou IPs intermédios mudaram sem evidência de ASN de que ficaram na mesma operadora. Transporta old_hop_count, new_hop_count e hop_count_delta.
Lógica: Deteta instabilidades de encaminhamento ou "flapping" quando o trânsito mudou de facto. Severidade info por defeito; 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 é registada, porém só como suspeita. Um destino que deixa de responder não gera Mudança de Rota; isso é disponibilidade.
Alterações 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 roda dentro do mesmo ASN, o TraceLog regista uma observação de balanceamento em vez de Mudança de Host Final.
Loop de Encaminhamento
Prioridade Crítica
Loop de Sequência: O único detetor 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 a responder 10 ou mais vezes no mesmo traçado NÃO é loop — é um router a responder por todos os TTLs restantes (MPLS/NAT). Torna-se a observação repeated_hop, sem alerta.
Lógica Anti-FP: Gamas 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. Uma observação nunca gera e-mail, Telegram ou webhook — explica o caminho no detalhe da medição. Um sinal torna-se 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. Registado quando "Registar 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 a responder 10 ou mais vezes (o antigo critério de "loop distribuído").
- intermediate_hop_loss — um salto intermédio 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 intermédios 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 intermédios mudou e o destino final também mudou: Mudança de Rota coexiste com Mudança de Host Final no mesmo teste.
- Loop de encaminhamento 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 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 equipas de suporte.
Integração com Telegram
Receba alertas em tempo real no seu telemóvel. Vai precisar de um Bot Token (gerado pelo @BotFather) e do Chat ID de destino.
Como testar sua configuração
- Aceda ao menu Definiçõ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 detetada gera um alerta.
- Alteração de Rota (Internet): Indica redirecionamento no caminho intermédio 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. O balanceamento de carga é observação e nunca notifica.
- Host Final (Aplicação): 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 ligação.
Rota Incompleta (Asteriscos)
Isso ocorre quando um router intermédio 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 observar perda intermitente, tente mudar o protocolo de destino para TCP ou UDP nas definiçõ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 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.