Monitorización de enlaces cortos con Sentry y Datadog: quién hace qué

La monitorización de enlaces cortos se reparte con claridad entre las dos herramientas. Sentry es donde Elido envía los eventos de salud del enlace: un destino que dejó de responder, un enlace que caducó, un límite de clics alcanzado, un dominio personalizado que falló en la verificación. Datadog es donde Elido envía los clics, un registro por visita y tres métricas de recuento de clics por minuto. La latencia de redirección no va a ninguna de las dos, porque Elido no la exporta; la mides desde fuera con una sonda sintética.

Este artículo es la mitad centrada en Sentry de ese panorama, más una respuesta clara a "qué herramienta para qué". Si has llegado aquí buscando paneles de Datadog, la guía de métricas de redirección en Datadog cubre en profundidad las métricas de clics, la forma del registro y un panel de latencia basado en Synthetics, así que no lo repetiré aquí.

Un poco de contexto antes de entrar en la configuración. Una redirección puede estar perfectamente sana mientras el enlace está muerto: la URL corta responde en pocos milisegundos y envía a la gente a un 404. Por eso la monitorización de URL para enlaces cortos necesita una señal consciente del destino y una señal de velocidad, y por eso ninguna herramienta por sí sola te da las dos desde un mismo flujo. El desglose de p95 por debajo de 15 ms explica qué aspecto tiene "sano" en el lado de la velocidad.

Qué tiene que detectar la monitorización de enlaces cortos

Clasifico los fallos en tres categorías, porque cada una necesita una herramienta distinta.

El enlace se rompió. Su destino devuelve un 4xx o un 5xx, se agota el tiempo de espera, o el dominio dejó de resolverse. Tu redirección sigue funcionando, pero ahora envía a la gente a una página de error. Elido detecta esto con una comprobación diaria del destino y lanza link.broken.

El enlace se detuvo a propósito. Llegó a su fecha de caducidad o a su límite de clics, así que Elido dejó de redirigirlo. Técnicamente no hay ningún problema, pero si una campaña todavía apunta a él, alguien necesita saberlo. Eso son link.expired y link.cap_reached. Un dominio personalizado que nunca se verificó lanza domain.ssl_failed, que pertenece al mismo grupo.

La propia redirección se volvió lenta o dejó de funcionar. Esa es la señal de velocidad, y es la única que Elido no emite como métrica. La vigilas desde fuera.

El tráfico es una cuarta señal, pero más suave. Una campaña que normalmente hace miles de clics por hora y de repente hace unas pocas decenas suele significar que algo cambió más arriba en la cadena, como un anuncio pausado o una pegatina QR arrancada. Los recuentos de clics viven en Datadog, así que ahí es donde va el monitor de caída.

Qué envía Elido a Sentry

Sentry es uno de los tipos de canal saliente en el sistema de notificaciones de Elido, junto a Discord, Telegram y los webhooks planos firmados. Viaja por la misma canalización de entrega que los webhooks, con una diferencia: en lugar del evento bruto de Elido, publica un pequeño evento de Sentry.

Cada entrega es un evento JSON enviado al endpoint store de tu proyecto, que Elido deriva del DSN. Dado https://[email protected]/8, el destino es https://o4711.ingest.sentry.io/api/8/store/ y la clave pública va en la cabecera X-Sentry-Auth. No hay ningún SDK de Sentry en ningún punto del camino, y como el host del DSN se analiza en lugar de estar fijado en el código, un servidor autoalojado compatible con Sentry funciona de la misma manera. La carga útil sigue el formato de carga útil de eventos de Sentry:

{
  "event_id": "9f0c4e1b2a7d4c33b8e5d6a1f2c3b4a5",
  "timestamp": 1790000000,
  "level": "error",
  "logger": "elido",
  "platform": "other",
  "message": "<humanized event name, e.g. Link / Broken>",
  "environment": "production",
  "tags": { "event_type": "link.broken", "workspace_id": "42" }
}

El nivel se elige a partir del nombre del evento. Cualquier cosa que signifique "este enlace no funciona ahora mismo" llega como error: .broken, .expired, cap_reached, ssl_failed. Las eliminaciones y las degradaciones llegan como warning, y todo lo demás como info.

Ahora la parte honesta sobre las etiquetas. Todo evento lleva las etiquetas event_type y workspace_id, y los campos environment y release se rellenan cuando los configuras en el canal. Un evento de límite alcanzado también lleva una etiqueta clicks. El evento de enlace roto, sin embargo, hoy no lleva el slug ni el destino como etiquetas, así que la incidencia de Sentry te dice que un enlace del espacio de trabajo 42 se rompió, y tienes que abrir la lista de enlaces en Elido, donde el roto lleva una marca. Prefiero decírtelo ahora antes que dejarte buscando una etiqueta slug a las dos de la madrugada.

Configurar un canal de Sentry para alertas de enlaces rotos

La configuración lleva un par de minutos y el DSN es la única credencial. El canal de Sentry está marcado como Beta porque el proyecto de Sentry lo creas tú mismo; una instalación de un clic a través de la plataforma de integraciones de Sentry está en la hoja de ruta pero todavía no está construida, así que hoy toca pegar el DSN a mano.

1. En Sentry, crea un proyecto, elige la plataforma Other y copia el DSN en la siguiente pantalla. La explicación del DSN muestra qué parte es la clave y cuál es el ID del proyecto.
2. En el panel de Elido, abre Notifications, añade un canal, elige Sentry, pega el DSN y, opcionalmente, un nombre de entorno como production.
3. Mantén los eventos predeterminados o elige los tuyos. Los predeterminados son link.broken, link.expired, link.cap_reached y domain.ssl_failed.

Elido comprueba el DSN al guardar: debe ser http o https, incluir una clave pública y terminar en un ID de proyecto. Uno mal formado se rechaza ahí mismo en lugar de fallar en silencio más tarde.

Si gestionas la configuración como código, el mismo canal es una sola llamada a la API. Los canales son endpoints de webhook con un kind:

curl -X POST https://api.elido.app/v1/workspaces/42/webhooks \
  -H "Authorization: Bearer elido_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "sentry",
    "url": "https://[email protected]/8",
    "events": ["link.broken", "link.expired", "link.cap_reached", "domain.ssl_failed"],
    "description": "Link health to Sentry",
    "config": { "environment": "production", "release": "spring-campaign" }
  }'

Las entregas a Sentry no llevan firma HMAC, ya que Sentry autentica la petición por su clave en su lugar. Sí reciben la política de reintentos normal: tres intentos en total, con los reintentos a los cinco y quince minutos de un fallo, y después la entrega se marca como fallida. Puedes listarlas en /v1/workspaces/{workspace_id}/webhooks/{id}/deliveries y reintentar una a mano.

No hay botón de prueba para este canal. La prueba más limpia que conozco: crea un enlace desechable con una caducidad a uno o dos minutos vista y espera. Elido escanea en busca de enlaces recién caducados cada cinco minutos, así que poco después debería aparecer una incidencia de nivel error en Sentry.

Una vez que los eventos de salud del enlace llegan a Sentry, la siguiente pregunta es qué vas a hacer con ellos, y eso depende de cómo los agrupe Sentry. Si todavía estás eligiendo un plan, compara qué incluye cada nivel antes de conectar el canal.

Cómo agrupa Sentry los eventos de salud del enlace de Elido

Estos eventos no tienen ni traza de pila ni excepción, así que el agrupamiento de respaldo de Sentry los agrupa por mensaje. En la práctica eso significa una incidencia por tipo de evento: todos los eventos de enlace roto se convierten en una incidencia cuyo recuento de eventos va subiendo, y todas las caducidades en otra.

Eso resulta útil para las alertas de guardia y menos útil para la clasificación. Dos ajustes ayudan:

• Configura el entorno en el canal. Con canales separados por espacio de trabajo o por entorno (production, campaigns), cada uno obtiene su propio filtro en el flujo de incidencias, y puedes limitar las reglas de alerta a uno solo.
• Añade una regla de fingerprint en la configuración del proyecto de Sentry sobre tags.workspace_id si enrutas varios espacios de trabajo hacia un mismo proyecto y quieres una incidencia por espacio de trabajo.

Para las alertas, apóyate en las propias reglas de alerta de incidencias de Sentry: "se crea una incidencia nueva" detecta el primer enlace roto, y "la incidencia se ve más de N veces en una hora" detecta un lote, por ejemplo toda una campaña cuyo dominio de aterrizaje se cayó. Ten en cuenta el ritmo de detección que hay detrás. La comprobación del destino se ejecuta una vez al día, el primer fallo se dispara de inmediato, y un enlace que sigue roto se dispara de nuevo pasadas 24 horas. Sentry es la bandeja de entrada adecuada para esto. No es un detector de caídas de cinco minutos, y no pretendo hacer creer lo contrario.

Dónde encaja Datadog en la monitorización de redirecciones

Datadog recibe clics, no salud del enlace. Cada clic se convierte en un registro enviado a la ingesta de Logs de tu sitio de Datadog, con la fuente elido, las etiquetas workspace_id, vendor:elido y link_id, y los campos del clic bajo attributes. Una vez por minuto, Elido también envía tres gauges por espacio de trabajo: elido.clicks, elido.clicks_by_country y elido.clicks_by_device.

Lo que no está ahí importa tanto como lo que sí. No hay métrica de latencia, ni códigos de estado, ni etiquetas de dominio, nivel o región. Un POST de registro fallido recibe un reintento y luego se descarta. La configuración se cachea hasta cinco minutos, así que una clave recién guardada tarda un momento en activarse, y el botón Test connection del panel envía un registro de prueba y muestra la respuesta de Datadog, lo que detecta una clave o un site equivocados pero no un pipeline que descarta los registros, así que un clic real sigue siendo la prueba de que funciona.

Así que el trabajo de Datadog aquí es el tráfico: volumen de clics por minuto, países principales y un monitor para "clics caídos a casi cero". La guía de monitorización de URL en Datadog tiene las consultas, los pasos de configuración, y la página de integración enumera los campos. Concilia los totales con la analítica de clics de Elido, que sigue siendo la fuente de verdad.

Vigilar la latencia de redirección desde fuera

Para la señal de velocidad, apunta una comprobación sintética a un enlace corto canario: un enlace que creas únicamente para monitorización, de modo que las sondas nunca se mezclen con las cifras de campaña. Las pruebas HTTP de Datadog hacen esto bien, y cualquier servicio de uptime que pueda saltarse las redirecciones también sirve.

Tres ajustes deciden si el número significa algo:

• Desactiva el seguimiento de redirecciones. Quieres el tiempo hasta que llega el 301 o el 302, no el tiempo que tarda en renderizarse tu página de aterrizaje.
• Valida el código de estado y la cabecera Location, para que una redirección al lugar equivocado haga fallar la comprobación.
• Envía un User-Agent que contenga bot. Elido omite los eventos de clic para agentes bot conocidos, así que tu sonda no inflará los recuentos de clics.

Ejecuta la sonda desde ubicaciones cercanas a tu audiencia. Una redirección con acierto de caché dentro de la región debería quedar bien por debajo del presupuesto de p95 de 15 ms, y un salto sostenido merece una alerta. Una comprobación contra tu dominio personalizado también te dice si su certificado TLS sigue funcionando, algo que un simple reenviador de clics nunca podría decirte.

Qué herramienta para qué

Así es como repartiría esto para un equipo que ejecuta campañas de pago con enlaces cortos:

Un equipo pequeño puede empezar solo con el canal de Sentry; cubre los fallos que desperdician gasto publicitario en silencio. Añade Datadog en cuanto alguien realmente mire los paneles de tráfico, y añade la sonda el día en que una redirección lenta te empiece a costar dinero. Si Sentry no es la bandeja de entrada de tu equipo, los mismos eventos de salud del enlace van a Discord o Telegram, y un enlace roto también puede abrir un ticket en Linear.

Lee el artículo pilar → Cómo lograr un p95 por debajo de 15 ms en las redirecciones

Relacionado en el blog

• Monitorización de URL en Datadog para enlaces cortos - métricas de clics, registros y un panel de latencia con Synthetics.
• Estrategia de prevención del deterioro de enlaces - qué hacer después de que llegue una incidencia de enlace roto.
• Alertas de Discord y Telegram para enlaces cortos - los mismos eventos de salud del enlace en un canal de chat.
• Tickets de Linear a partir de alertas de enlaces - convertir un enlace roto en una tarea rastreada.