Guía del Usuario

Lógica del Sistema

TraceLog opera con base en la relación entre Sondas y Objetivos.

Sondas (Sensores)

Puntos de origen de las pruebas. Pueden ser el propio servidor de la aplicación o Sondas Remotas instaladas en infraestructuras externas.

Objetivos

Destinos monitoreados (ej., dominios, direcciones IP). TraceLog mapea la ruta exacta hacia ellos.

Eventos

Notificaciones generadas automáticamente cuando el sistema detecta cambios de enrutamiento (saltos) o desviaciones inesperadas.

Flujo de Operación

Registrar Objetivos

Agrega los destinos que deseas monitorear. Usa nuestra base de datos de "Objetivos Conocidos" para importar rápidamente servicios populares.

Gestionar Objetivos

Generar SENSOR_KEY

Cada sonda remota necesita una clave única para autenticación. Genéralas en el menú Red > Sondas.

Gestionar Sondas

Importación Masiva

Ahorra tiempo usando la herramienta de importación masiva. Puedes pegar una lista de IPs/Hosts o seleccionar servicios populares (Google, Cloudflare, etc.) para monitoreo inmediato.

Ir a Objetivos e Importación

Despliegue de Sonda

Usa el contenedor Docker para servidores Linux y, si tu operación ya ejecuta Agente NOC, consume la telemetría de TraceLog mediante la compatibilidad opcional entre ambos productos.

Guía Técnica

Gestión de Equipo

TraceLog es nativamente multi-tenancy, lo que te permite organizar tu estructura en diferentes Equipos para el aislamiento de datos y la colaboración.

Aislamiento Total

Las Sondas y Objetivos registrados en un equipo no son visibles para otros equipos, garantizando la privacidad entre proyectos o clientes.

Asignación de Miembros

Invita a colaboradores a tu equipo por correo. Define quién solo puede ver o quién puede gestionar la infraestructura.

Gestionar Equipos

Disparadores Inteligentes

Evita "falsos positivos" configurando disparadores basados en ocurrencias consecutivas y ventanas de confirmación — cada objetivo responde tres preguntas: ¿llega? ¿llega bien? ¿por dónde llega?

Detección de Offline

Define cuántos fallos consecutivos de Ping (100% de pérdida) deben ocurrir antes de activar una Alerta de Offline.

Recuperación Online

Determina cuántos éxitos consecutivos se necesitan para considerar el objetivo estable y generar un evento de recuperación.

Degradación de Rendimiento

Define el umbral de latencia (ms), el límite de pérdida (%) y la ventana (minutos). La primera muestra por encima de uno de los umbrales crea un evento sospechoso; toda la ventana violando (o dos sondas coincidiendo) lo confirma; el evento se marca como recuperado tras el período de estabilidad sin violación.

Profundidad del trazado (TTL máximo)

Limita cuántos saltos recorre la sonda (hasta 255). Es un parámetro de medición, no un disparador: el número de saltos pasó a ser atributo del Cambio de Ruta y el exceso de saltos se convierte en observación, sin alerta.

Ventanas de Mantenimiento

Programa períodos de mantenimiento para silenciar notificaciones durante actualizaciones planificadas. A diferencia de deshabilitar un objetivo, la ventana de mantenimiento continúa recopilando telemetría, permitiéndote analizar el comportamiento de la red durante la intervención, pero sin disparar alertas al equipo.

Cómo funciona

Las notificaciones por Email/Telegram están suspendidas.
Los webhooks no se disparan.
La recopilación de telemetría (latencia/ruta) permanece activa.

Programar Mantenimiento

Webhooks Nativos

Integra TraceLog con cualquier sistema externo. Enviamos un JSON vía POST a la URL configurada siempre que ocurre un evento relevante. El campo "event" solo emite los 6 tipos vigentes (target_offline, target_online, route_change, final_host_change, routing_loop, performance_degradation).

Seguridad HMAC

Cada solicitud incluye un encabezado "X-Tracelog-Signature" que contiene el hash HMAC-SHA256 del payload, firmado con tu Secret.

{ "event": "performance_degradation", "target": "8.8.8.8", "details": { "metric": "loss", "status": "confirmed" } }

Compatibilidad con nombres antiguos

Las suscripciones con los nombres antiguos siguen aceptándose y se normalizan al guardar: packet_loss y high_latency pasan a performance_degradation; hop_count_exceeded pasa a route_change. load_balancing dejó de ser entregable — es observación, no evento — y una suscripción que solo tenía ese tipo se rechaza con un aviso.

Configurar Webhooks

Análisis e Inteligencia

Panel Estratégico

Obtén visibilidad macro de toda tu red. Una vista unificada de tendencias de rendimiento permite respuestas proactivas antes de que los clientes perciban degradación del servicio.

Diferencial de Saltos

Identifica cambios silenciosos en los proveedores de tránsito a través del historial de ASN en cada salto de la ruta.

Evidencias en PDF

Exporta informes completos directamente desde el Panel. Ideal para abrir tickets con proveedores de tránsito. El PDF incluye gráficos periódicos, la matriz de saltos y el ASN consolidado de cada salto para demostrar dónde ocurrió el fallo.

Enfoque en la Resolución de Problemas

Reduce el MTTR (Tiempo Medio de Reparación). Identifica si el problema es local, del proveedor de tránsito o del datacenter de destino analizando visualmente el desglose de la ruta.

Análisis Comparativo

El Análisis Comparativo muestra el mismo objetivo visto por varias sondas a la vez. Como cada sonda observa el destino desde una red distinta, comparar las curvas revela si la degradación está en el destino, en el tránsito compartido o dentro de la red de una sola sonda.

1. Selecciona el objetivo

Elige el destino en el selector de Objetivo. Mientras no se elija un objetivo, la página solo muestra la Matriz de Conectividad.

2. Elige las sondas

Activa o desactiva los chips de sonda para controlar qué series aparecen. Cada sonda mantiene un color fijo en el gráfico, las tarjetas de estadísticas y la leyenda. Sin ningún chip seleccionado, se muestran todas las sondas.

3. Elige la métrica y los filtros

Alterna entre Latencia, Jitter, Pérdida de Paquetes y Saltos. Acota los datos por Versión IP (IPv4/IPv6), Transporte (ICMP/TCP/UDP) y período. El modo En Vivo recarga las series cada 30 segundos.

Tarjetas de estadísticas por sonda

Cada sonda comparada recibe una tarjeta con la media, el P95 y el pico de la métrica seleccionada en el período, con el mismo color que su línea en el gráfico.

Eventos en la línea de tiempo

Las marcas verticales señalan eventos en el gráfico. Los chips de resumen cuentan eventos por tipo: haz clic en un chip para filtrar la lista y haz clic en una entrada de "Últimos eventos" para resaltar ese momento exacto en el gráfico.

Cómo interpretar la comparación

Todas las sondas se degradan al mismo tiempo: el problema está en el destino o en un tramo de tránsito compartido por todos los caminos; escala al destino o al operador común.
Solo una sonda se degrada: el problema es local de la red de esa sonda (uplink, peering o última milla). El destino sigue sano para todas las demás.
Las sondas difieren en valores absolutos pero se mueven juntas: eso es geografía, no un incidente; compara tendencias, no milisegundos en bruto.

La matriz como punto de entrada

La Matriz de Conectividad lista la puntuación de salud de cada par objetivo y sonda, con los peores pares primero. Haz clic en una celda para abrir la comparación de ese par exacto: el punto de partida más rápido cuando no sabes dónde mirar.

Abrir Análisis Comparativo

Puntuación de Salud

Cada par objetivo y sonda recibe una puntuación de salud de 0 a 100, recalculada cada vez que llega una nueva medición o comprobación de protocolo. La puntuación empieza en 100 y cada factor de abajo resta puntos. Las puntuaciones se mantienen por separado según la versión IP y el protocolo de transporte, así que un problema en IPv6 nunca se esconde detrás de un camino IPv4 sano.

Penalización por pérdida de paquetes

Cada 1% de pérdida de paquetes en la muestra más reciente resta 1 punto, con un tope de 50 puntos.

Latencia por encima de la línea base

Cuando la latencia supera la línea base aprendida, la puntuación pierde puntos en proporción al exceso: el doble de la línea base resta unos 20 puntos, con un tope de 25. Las líneas base se aprenden con las últimas 100 muestras del par (mínimo de 5).

Comprobación de protocolo fallida

Una comprobación de salud fallida (ICMP, TCP connect, HTTP, TLS, DNS o UDP) resta 35 puntos. Una comprobación exitosa no resta nada.

Normal 71-100

El par opera dentro de su comportamiento habitual.

Degradado 41-70

Degradación medible: inspecciona el par en el Análisis Comparativo.

Crítico 0-40

Pérdida severa, latencia sostenida o comprobaciones fallando: actúa ahora.

La puntuación refleja el estado más reciente del par, no una media histórica. Los mismos rangos alimentan la Matriz de Conectividad y la franja "Críticos ahora" del Panel NOC.

Recursos y Métricas Avanzadas

Cálculo Preciso de Jitter

TraceLog calcula Jitter utilizando el estándar RFC 3550, que representa la diferencia media absoluta entre retrasos consecutivos. Esto es crítico para aplicaciones en tiempo real como VoIP y Streaming de Video, donde la variación importa más que la latencia absoluta.

Profundidad del trazado y conteo de saltos

La profundidad del trazado (TTL máximo, hasta 255) define hasta dónde llega la sonda. El número de saltos dejó de ser alerta: viaja como atributo del Cambio de Ruta (antes/después/diferencia) y, cuando supera la profundidad configurada, queda registrado como observación hop_count_exceeded.

Umbrales Condicionales

Define criterios avanzados: recibe alertas solo si la latencia supera 200 ms O la pérdida de paquetes es mayor al 10% durante toda la ventana configurada, como 5 minutos continuos. Esto elimina ruido de oscilaciones transitorias.

Paridad Multi-Protocolo (v4/v6)

Monitorea el mismo objetivo vía IPv4 e IPv6 simultáneamente desde la misma Sonda. Analiza diferencias de ruta y compara rendimiento entre protocolos en tiempo real.

Inteligencia de Enrutamiento (Bucles vs Balanceo de Carga)

TraceLog distingue automáticamente el comportamiento de balanceo de las anomalías críticas de enrutamiento. Las repeticiones consecutivas, los patrones diamante y la rotación del salto final en el mismo ASN son observaciones de balanceo de carga (ECMP es normal). Solo las secuencias repetidas (A->B->A->B->A->B) se señalan como Bucle de Enrutamiento; la misma IP respondiendo 10+ veces es un router respondiendo por los TTL restantes y se convierte en observación repeated_hop.

Jerarquía y coexistencia de eventos

Un único trace puede generar más de un evento cuando ocurren causas distintas juntas. Ejemplo: si cambiaron saltos intermedios y también se movió el destino final, TraceLog puede emitir Cambio de ruta y Cambio de host final. Si solo cambió el salto final, no se degrada a un Cambio de ruta genérico.

Glosario de Eventos y Criterios de Inteligencia

TraceLog clasifica los incidentes de red en seis tipos, organizados en tres familias: disponibilidad (¿llega?), calidad (¿llega bien?) y ruta (¿por dónde llega?). Cada evento se dispara por criterios técnicos específicos y lleva status, confianza y evidencia para separar incidentes confirmados de comportamientos sospechosos o solo observados.

Disponibilidad — ¿llega?

Pérdida del 100 % (o el retorno por debajo) en N muestras consecutivas, evaluada por sonda y por protocolo. El objetivo solo aparece fuera de línea en el mapa cuando cualquier par sonda/protocolo está fuera de línea.

Alvo Offline
Alvo Online

Calidad — ¿llega bien?

Un único evento de calidad: latencia y/o pérdida por encima de los límites del objetivo. La métrica infringida queda en details.metric (latency, loss o both) y el evento evoluciona de sospechoso a confirmado y recuperado.

Degradação de Desempenho

Ruta — ¿por dónde llega?

Cambio en la secuencia de ASN de los saltos intermedios, cambio del host final a otro ASN y bucle de enrutamiento por secuencia repetida. El balanceo de carga y el exceso de saltos quedan como observaciones.

Mudança de Rota
Mudança de Host Final
Loop de Roteamento

Confianza, Estado y Evidencia

Todo evento mantiene su tipo técnico, pero details_json también incluye status, confidence, confidence_level y evidence. Confirmed significa que la señal fue validada por persistencia, un criterio fuerte de topología o muestras consecutivas. Suspected significa que la señal es real en la muestra, pero aún necesita persistencia u otra sonda para tratarse como definitiva. Recovered marca una degradación que pasó el período de estabilidad sin violar. Observed es comportamiento informativo, como el balanceo de carga, que explica la ruta sin tratarse por sí solo como incidente.

Objetivo Desconectado

Criterio: Se detectó una pérdida de paquetes del 100%.
Lógica: El sistema espera una cierta cantidad de comprobaciones fallidas consecutivas (definidas en los disparadores) antes de marcar el host como caído. Esto evita alertas de "flapping" durante microcortes de red.

Objetivo en línea (recuperación)

Criterio: La pérdida de paquetes cae por debajo del 100% (restablecimiento de la conectividad).
Lógica: Se activa cuando el host vuelve a un estado de respuesta. Al igual que con la detección fuera de línea, respeta un umbral de "estabilidad" de comprobaciones exitosas consecutivas.

Degradación de Rendimiento

Criterio: latencia Y/O pérdida de paquetes por encima de los límites definidos en el objetivo — el único evento de calidad (sustituye a Latencia Alta y Pérdida de Paquetes).
Lógica: La métrica infringida queda en details.metric (latency, loss o both), con los valores medidos, los umbrales y los saltos afectados. La pérdida del 100 % no es degradación — es disponibilidad (Objetivo Fuera de Línea). El evento tiene su propio ciclo de vida:

Sospechoso: primera muestra por encima del umbral (lo que antes era Latencia Alta o Pérdida de Paquetes). Se notifica solo si "También notificar eventos sospechosos" está activo.
Confirmado: toda la ventana (condition_duration_minutes) viola el umbral — con al menos dos muestras y un intervalo real entre ellas — o una segunda sonda ve la misma degradación en la ventana de confirmación. La repetición en la misma sonda no confirma.
Recuperado: tras recovery_stability_minutes sin ninguna violación.

Cambio de Ruta

Criterio: la secuencia de ASN (tránsito) de los saltos intermedios cambió — o las IP intermedias cambiaron sin evidencia de ASN de que siguieron en el mismo operador. Lleva old_hop_count, new_hop_count y hop_count_delta.
Lógica: Detecta inestabilidades de enrutamiento o "flapping" cuando el tránsito cambió de verdad. Severidad info por defecto; sube a aviso cuando existe Degradación de Rendimiento u Objetivo Fuera de Línea del mismo objetivo dentro de la ventana de confirmación (en ambos sentidos), con el evento correlacionado en details.correlated_event_id. Los saltos que cambian de IP dentro del mismo ASN — incluso con un salto más o menos, como en ECMP — son observación de balanceo, nunca Cambio de Ruta; un salto privado nunca cuenta como tránsito y un salto con timeout (???) no es diferencia. Si solo cambió el salto final, es Cambio de Host Final. Si la IP cambió pero el ASN del salto es desconocido, el Cambio de Ruta igual se registra, pero solo como sospechoso. Un destino que deja de responder no genera Cambio de Ruta; eso es disponibilidad.

Cambios de Host Final

Criterio: cambio en el último salto válido con un cambio real de destino final/ASN.
Lógica: Se usa cuando el último salto válido cambia a otro ASN (o ASN desconocido). Una sola muestra se marca como sospechosa porque traceroute/MTR clásico no siempre prueba que el host final de la aplicación cambió; la persistencia, varias sondas o la concordancia de protocolo refuerzan el diagnóstico. Si el destino solo rota dentro del mismo ASN, TraceLog registra una observación de balanceo en lugar de Cambio de Host Final.

Bucle de Enrutamiento

Prioridad crítica

Bucle de secuencia: El único detector de bucle: un patrón de IP (p. ej. A->B->A->B) que se repite 2 o más veces (A-B A-B A-B).
Salto repetido (observación): Una sola IP que responde 10 o más veces en el mismo trazado NO es un bucle — es un router respondiendo por todos los TTL restantes (MPLS/NAT). Se convierte en la observación repeated_hop, sin alerta.
Lógica anti-FP: Los rangos de IP privada y las repeticiones consecutivas cortas se suprimen para evitar falsos positivos de balanceadores internos o comportamiento ECMP.

Observaciones vs Incidentes

TraceLog almacena observaciones técnicas (network_observations) separadas de los eventos accionables. Una observación nunca genera correo, Telegram ni webhook — explica la ruta en el detalle de la medición. Una señal se convierte en incidente cuando persiste, llega al destino, afecta checks reales por protocolo o aparece en varias sondas. Hoy son observaciones:

load_balancing — ECMP es normal: patrones diamante, repeticiones consecutivas, rotación de destino o de saltos internos dentro del mismo ASN. Se registra cuando "Registrar observaciones de balanceo de carga" está activo en el objetivo.
hop_count_exceeded — el destino se alcanzó con más saltos que la profundidad del trazado configurada. El número de saltos es atributo del Cambio de Ruta; por sí solo no da acción al NOC.
repeated_hop — la misma IP respondiendo 10 o más veces (el antiguo criterio de "bucle distribuido").
intermediate_hop_loss — un salto intermedio que descarta ICMP mientras los saltos siguientes responden (rate-limit, no pérdida real).

Resumen de la jerarquía de eventos

Solo cambió el último salto: mismo ASN = observación de balanceo de carga; ASN/destino final distinto = Cambio de Host Final sospechoso hasta que persista o aparezca en más evidencias.
Cambiaron saltos intermedios: mismo camino de ASN con evidencia de ASN = observación de balanceo; el camino de ASN cambió = Cambio de Ruta confirmado; las IP cambiaron sin evidencia de ASN = Cambio de Ruta sospechoso.
El tránsito (camino de ASN) de los saltos intermedios cambió y el destino final también: el Cambio de Ruta coexiste con el Cambio de Host Final en la misma prueba.
El bucle de enrutamiento tiene prioridad sobre la observación de balanceo cuando la propia ruta muestra una secuencia cíclica real (A->B->A->B).
Cambio de Ruta con Degradación de Rendimiento u Objetivo Fuera de Línea del mismo objetivo en la misma ventana: el cambio sube a aviso y apunta al evento correlacionado; ambos siguen siendo eventos separados.

Personalización de Alertas

TraceLog te permite ser notificado al instante cuando ocurren eventos críticos, garantizando una respuesta rápida a los incidentes de red.

Canales de Correo

Configura múltiples destinatarios de correo separados por comas. Ideal para listas de distribución de NOC o equipos de soporte.

Integración con Telegram

Recibe alertas en tiempo real en tu móvil. Necesitarás un Bot Token (generado por @BotFather) y el Chat ID de destino.

Cómo Probar tu Configuración

Accede al menú Configuración > Notificaciones en la parte superior de la página.
Habilita el canal deseado (Email o Telegram).
Completa los datos necesarios.
Haz clic en el botón "Probar Notificación". El sistema enviará un evento de ejemplo de inmediato.

Criterios de Notificación

Todos los Eventos: Cualquier cambio detectado genera una alerta.
Cambio de ruta (Internet): Indica redireccionamiento en la ruta intermedia de internet pública (tránsito/ASN).
Degradación de rendimiento (calidad): Latencia o pérdida de paquetes por encima de los umbrales del objetivo: sospechada en la primera muestra, confirmada cuando toda la ventana viola. El balanceo de carga es una observación y nunca notifica.
Cambio de host final (aplicación): Failover DNS o migración de servidor cuando el destino final realmente se movió a otro ASN/contexto de destino.
Condiciones combinadas: Se puede generar más de una alerta a partir de la misma prueba cuando coexisten causas distintas.

Resolución de Problemas (Troubleshooting)

La sonda no reporta datos

Verifica si la SENSOR_KEY en el contenedor/agente es correcta.
Asegúrate de que el host tenga acceso al puerto 80/443 del servidor TraceLog.
En Docker, usa "docker logs [container_id]" para ver errores de conexión.

Ruta Incompleta (Asteriscos)

Esto ocurre cuando un router intermedio bloquea el protocolo ICMP o UDP de la sonda. TraceLog seguirá intentando mapear otros saltos para completar la visión general.

Objetivo siempre Offline

Verifica si el firewall de destino permite paquetes ICMP (Ping). Algunas infraestructuras (como AWS/Azure) requieren configuración explícita en el Security Group.

Falsa Pérdida de Paquetes (Rate Limiting)

Algunos hosts (como Cloudflare o IPs protegidas contra DDoS) descartan paquetes ICMP cuando la frecuencia es alta. Si ves pérdida intermitente, intenta cambiar el protocolo del objetivo a TCP o UDP en su configuración.

Compatibilidad con Agente NOC

Agente NOC es una capa opcional de compatibilidad. TraceLog sigue siendo responsable de las sondas, la telemetría, los paneles y el análisis histórico, mientras el agente puede consumir estos datos para clientes que ya lo usan.

Redespliegue de la sonda

Si mueves un sensor a otra ubicación o red, usa la acción "Borrar Historial" en el menú del sensor para restablecer las métricas sin generar una nueva clave API.

Volver al Centro