Monitorización de enlaces cortos con Sentry y Datadog

Si un enlace corto devuelve 5xx durante 30 segundos en plena campaña de Instagram, pierdes aproximadamente entre un 4% y un 7% de la cohorte. La mayoría de los equipos de ingeniería se enteran a la mañana siguiente cuando alguien pega una captura de Slack. Esta guía es el playbook que usamos en Elido para detectar fallos de redirección en menos de 60 segundos con dos herramientas que probablemente ya pagas: Sentry para issues y Datadog para métricas. Es la misma configuración que utilizamos en nuestros propios edge POPs, que sirven aproximadamente 240 millones de redirecciones al mes con un p99 de 13 ms.

En pocas palabras: Sentry hace una cosa muy bien en el contexto de redirecciones, y esa cosa es "un issue por destino roto, con la lista de slugs que lo han impactado." Datadog hace lo complementario: series temporales. Quieres ambas cosas, y Elido emite a las dos de forma nativa. Sentry está actualmente en Beta (pega un DSN y listo); Datadog está en Live con un metric collector dedicado. A continuación: qué señales importan, cómo funciona internamente la integración con Sentry y qué debe contener realmente un dashboard de Datadog para la salud de las redirecciones.

Qué señales importan en la monitorización de redirecciones

Antes de configurar nada, decide qué te importa de verdad. La monitorización de redirecciones es un problema más acotado que el APM completo, y el conjunto de señales es pequeño. Cuatro señales cubren aproximadamente el 95% de los incidentes reales:

Eventos de redirección 4xx. Un 404 en un enlace corto casi siempre es una de tres cosas: un slug fue eliminado, un slug expiró o alguien está escaneando tu dominio. Un 410 es intencional y genera ruido, así que lo suprimimos de las alertas. Un 451 (bloqueo geográfico) solo es interesante en agregado. El volumen de 4xx por evento es demasiado ruidoso para generar páginas; trátalo como una métrica, no como un issue.

Eventos de redirección 5xx. Estos sí justifican un page al responsable de guardia. Un 5xx significa que el edge no pudo alcanzar Redis (caché L2), no pudo alcanzar api-core (gRPC de origen) o que la URL de destino tuvo un fallo de DNS durante un HEAD-check. Cada caso tiene un runbook diferente. El transformer de Sentry en api-core etiqueta la causa raíz para que el título del issue sea algo como 5xx: redis-timeout (12 slugs afectados, último hace 14s) en lugar de un genérico Internal Server Error.

Latencia del edge p99. Una redirección con cache HIT debería servirse en menos de 15 ms en p99 desde cualquiera de nuestros tres POPs. Alertamos si p99 supera 50 ms durante más de 5 minutos. El motivo es que una sola consulta lenta no elevará p99 durante 5 minutos, pero una réplica de Redis desincronizada sí. Ver redirect p95 por debajo de 15 ms para el desglose del presupuesto de latencia.

Anomalía en la tasa de clics y fallos de escaneo. Las anomalías en la tasa de clics son el sistema de alerta tardía. Si una campaña normalmente hace 4.000 clics/hora y de repente solo 200, algo aguas arriba se rompió (tu anuncio fue rechazado, tu sticker QR se despegó, alguien cambió el enlace incorrecto). Los fallos de escaneo provienen del servicio url-scanner, que analiza los destinos en busca de malware. Un pico de fallos de escaneo suele significar que una cuenta fue comprometida y está creando enlaces de phishing.

Enrutar las señales a la herramienta correcta

No todas las señales pertenecen a todas las herramientas. Enviar el volumen de 4xx a Sentry como issues enterrará el issue real de "destino roto" bajo el ruido. Enviar la latencia p99 a Sentry como alertas es incómodo porque el sistema de alertas de Sentry está construido alrededor de la frecuencia de issues, no de series temporales. El modelo mental: Sentry = excepciones, Datadog = métricas, Slack = personas, Linear = tickets de seguimiento.

Elido emite donde está la X. No enviamos eventos 4xx a Sentry porque no son excepciones. No enviamos cada evento de clic a Datadog porque el volumen no justifica el coste (las métricas personalizadas de Datadog se facturan por combinación única de etiquetas, y la cardinalidad de slug x región x tier quemaría $4.000/mes para un workspace de tamaño medio). La división anterior es la que adoptamos tras 9 meses de operar el sistema internamente.

Integración con Sentry: pegar el DSN y el envelope transformer

La integración de Sentry en Elido está en Beta pero funcionalmente completa. La configuración son tres clics. Vas a /integrations, encuentras Sentry, pegas un DSN y eliges qué tipos de eventos reenviar. El DSN es el único secreto. Lo almacenamos en Postgres con cifrado de envelope (KMS-wrapped según ADR-0036) para que incluso nuestros administradores de DB no puedan leerlo en texto claro.

Lo que ocurre internamente es que api-core tiene un webhook transformer que escucha el bus de eventos interno (topic de Redpanda redirect.errors) y empaqueta los eventos coincidentes en envelopes de Sentry. El formato de envelope está documentado en la especificación de envelope de Sentry - es simplemente un HTTP POST con una línea de cabecera JSON, una cabecera de item JSON y un payload de item JSON, separados por saltos de línea. No hay SDK de Sentry en el camino de la solicitud. Esto mantiene el código del edge (services/edge-redirect) pequeño y evita una dependencia en el hot path.

El transformer hace tres cosas útiles:

Fingerprinting. Sentry agrupa los eventos por fingerprint. Un fingerprint ingenuo agruparía todos los 5xx en un issue enorme, lo que es inútil. Nuestro transformer hace fingerprint por error_class:destination_host, de modo que un timeout de Redis en enlaces apuntando a acme.com es un issue separado del timeout de Redis en enlaces apuntando a globex.com. Esto hace que "un destino roto = un issue" sea realmente cierto.

Agregación de slugs. Cada evento de Sentry lleva un bloque tags que lista los primeros 50 slugs afectados, el ID del workspace y el dominio de redirección. Cuando 800 slugs comparten un destino y ese destino empieza a devolver DNS NXDOMAIN, ves un issue con slugs_affected: 800 y una muestra de 50, no 800 alertas separadas.

Rate limiting por workspace. Un workspace ejecutando una campaña defectuosa puede generar 10.000 errores 5xx en 60 segundos. Sentry los aceptará todos y te los cobrará. El transformer limita a 50 envelopes por minuto por workspace y agrupa el resto en un único evento "suppressed" con un contador. Lo aprendimos a la mala cuando un cliente apuntó 4 millones de enlaces cortos a un dominio que empezó a devolver 503.

Si prefieres gestionar el ingest tú mismo en lugar de usar el transformer de Elido, la guía de observabilidad cubre el camino alternativo: suscríbete a nuestro bus de eventos webhook y convierte los eventos en envelopes de Sentry en tu propia infraestructura. La mayoría de los equipos no se molestan. El transformer es más rápido de adoptar que de construir.

Una nota sobre lo que aparece como "issue": la interfaz de Sentry trata cada evento agrupado como una tarjeta de issue con una sparkline, un evento de muestra y una lista de etiquetas. Para errores de redirección, la etiqueta más útil es cache_result (HIT, MISS, BYPASS). Si ves una ola de 5xx con cache_result: BYPASS, probablemente alguien en tu equipo desplegó un cambio que forzó el bypass de caché para pruebas y olvidó revertirlo. Historia real, dos veces en el último año.

Integración con Datadog: metric collector y dashboards

Datadog está en Live. La configuración también son tres clics, pero la arquitectura es diferente. En lugar de un transformer por evento, ejecutamos un metric collector en el lado de api-core que agrega la telemetría de redirección al formato de métricas de Datadog y envía lotes cada 10 segundos a través de la API de métricas personalizadas de Datadog. El collector pre-agrega para que nunca enviemos eventos en bruto. Esto mantiene baja la cardinalidad de las métricas personalizadas y tu factura de Datadog bajo control.

Las métricas que emitimos por defecto:

• elido.redirect.count - contador, etiquetado por domain, tier, region, cache_result, status_class (2xx/3xx/4xx/5xx)
• elido.redirect.latency.ms - distribución, etiquetada por domain, tier, region, cache_result
• elido.click.count - contador, etiquetado por domain, tier (deduplicado en la frontera del click-ingester)
• elido.scanner.failure.count - contador, etiquetado por reason (malware, phishing, expired_cert, dns_nxdomain)

Las etiquetas son el palanca. Puedes consultar "latencia p99 para link.acme.com en FRA durante las últimas 4 horas" con una query de una sola línea. No necesitas construir dashboards por adelantado para cada dominio. Ver /integrations/datadog para la referencia de métricas y taxonomía de etiquetas.

Los cuatro paneles anteriores son los que ponemos en nuestra propia pantalla del NOC. Cubren la vista diaria de guardia. Latencia p99 del edge por región detecta regresiones a nivel de POP (un fallo en Hetzner FRA se ve diferente a uno en OVH SGP, y quieres verlos uno al lado del otro). Tasa de error por dominio top-10 expone a los clientes ruidosos: si acme.com está al 8% de 5xx y todos los demás están al 0,02%, no tienes un problema de Elido, tienes un problema de acme. Volumen de clics por tier (f / s / b para free, starter, business mediante aislamiento por tier) indica si un pico de tráfico proviene de un tenant de pago o de una campaña del tier gratuito que debería estar limitada. Recuento de redirecciones rotas en las últimas 24h es la métrica de cierre: una redirección que devolvió 4xx debería haberse corregido o expirado y eliminado en 24 horas; ver prevención del deterioro de enlaces para el camino de autoreparación.

Umbrales de alerta recomendados (son nuestros valores predeterminados; puedes sobrescribirlos por workspace):

• elido.redirect.latency.ms p99 > 50 ms sostenido 5 min - avisar al guardia
• elido.redirect.count{status_class:5xx} tasa > 0,5% sostenida 2 min - avisar al guardia
• elido.redirect.count{status_class:4xx} tasa > 5% sostenida 10 min - solo Slack
• elido.scanner.failure.count tasa > 10/min para un workspace - revisión de seguridad, sin page

El umbral del 0,5% de 5xx es conservador. Nuestra línea base es ~0,01% (principalmente fallos de DNS en destinos de clientes), por lo que el 0,5% es una desviación de 50x, lo cual es real.

Cuándo usar cada herramienta

Para un equipo pequeño que opera un producto orientado a desarrolladores en /solutions/developers, Sentry probablemente sea suficiente. Te avisarán por 5xx reales, verás los issues y los solucionarás. No tendrás la cultura de dashboards que haga que Datadog valga $1,50/host/mes de sobrecarga.

Para una empresa más grande en /solutions/enterprise con una rotación de guardia de SREs, querrás ambas. Sentry para el flujo de issues, Datadog para los dashboards, alertas de Slack integradas con PagerDuty para los avisos. La guía de observabilidad explica el mapeo de servicios de PagerDuty si vas por ese camino.

Para todos los que están en el medio, nuestra recomendación es: Sentry desde el primer día (el tier gratuito de Sentry está bien para menos de 5.000 eventos/mes), Datadog cuando tengas más de un dominio de redirección o más de una región de tráfico. La factura del metric collector de Datadog en un workspace típico de Elido Business ronda los $35/mes, que es el precio de que un ingeniero no tenga que buscar en logs de nginx un domingo.

Qué te da esto que los monitores genéricos de uptime no ofrecen

Un check de Pingdom o UptimeRobot en f.elido.me te dirá si el edge está activo. No te dirá que el destino del slug summer24 empezó a devolver DNS NXDOMAIN hace 12 minutos, ni que p99 en SGP está 4 veces por encima del p99 en FRA porque un líder de partición de Redpanda se reinició. La monitorización de redirecciones es un problema consciente del destino. La redirección en sí puede estar sana mientras el enlace está muerto.

La combinación de Sentry y Datadog te da visibilidad consciente del destino sin tener que escribir sondas personalizadas. Sentry te dice qué está roto a nivel de destino. Datadog te dice qué se está degradando a nivel de edge. Slack informa a las personas, Linear gestiona el seguimiento. La configuración es pegar-un-DSN para Sentry y un único flujo OAuth para Datadog. Empieza con Sentry hoy; añade Datadog cuando tu recuento de dominios de redirección supere uno.

Para precios y qué tier incluye cada integración, ver /pricing. Para la superficie de API alrededor de las suscripciones a eventos si quieres construir la tuya propia, /features/analytics y el desglose de Sentry en 12 servicios Go cubren la taxonomía de eventos.