El viernes por la noche, un cliente hace clic en "Pagar". La solicitud pasa por nginx, la API de pago, el servicio de inventario en gRPC, Redis, PostgreSQL y luego un trabajo de webhook asincrónico. El soporte recibe un “tiempo de espera”. Los registros de API muestran "tiempo de espera agotado"; registros de inventario, nada anormal en volumen. Sin embargo, una sola llamada gRPC lenta, ahogada en el promedio, explica la espera. Sin un rastro unificado, nadie lo ve.
Tan pronto como una acción cruza dos o más ladrillos, el diagnóstico se fragmenta. El seguimiento distribuido adjunta un trace_id a la solicitud original y registra cada segmento (intervalo): duración, servicio, error. Ves el árbol completo, no hojas aisladas. La verdadera pregunta: ¿sabes cómo reconstruir el hilo que un usuario experimenta como una sola acción?
Seguimientos, registros y métricas: tres pilares, no tres sustitutos
Prometheus informará un p95 duplicado en /api/checkout; consulte Prometheus: elegir métricas que expliquen la lentitud. Los registros centralizados mostrarán un seguimiento de la pila en un momento dado. Ninguno vincula el tiempo de espera de nginx con la consulta SQL lenta en el catálogo ni con el trabajo del webhook sin contexto.
| Pilar | Lo que revela | Límite típico |
|---|---|---|
| Métricas | Tendencias, alertas, cumplimiento de SLO | Agregado: un caso raro desaparece en el p95 |
| Registros | Contexto del texto, configuraciones, errores | Un silo por departamento, correlación manual |
| Rastros | Ruta completa de una consulta | Costo de almacenamiento si el muestreo no es satisfactorio |
Eliminar los rastros significa adivinar dónde se rompió el camino: el tipo de ceguera que alimenta la fatiga de alerta.
Span, rastreo y propagación de contexto
Un rastreo representa el recorrido completo de una acción del usuario, por ejemplo, checkout-abc123. Un span es una operación unitaria dentro de este recorrido: una llamada HTTP GET /stock, una consulta SQL SELECT, una publicación de Redis. Cada lapso registra su duración, su estado y el servicio que lo ejecutó.
La propagación del contexto es el eslabón débil más común. El trace_id debe viajar desde el proxy inverso a los trabajadores asincrónicos, a través de encabezados HTTP W3C (traceparent, tracestate), metadatos de gRPC o la carga útil del trabajo en cola. Sin esta transmisión, el trabajador crea un rastro huérfano no relacionado con la solicitud original y la mitad de la historia desaparece en el primer procesamiento diferido.
| Componente | Instrumentación actual |
|---|---|
| nginx | Módulo OpenTelemetry o ingreso de malla de servicio |
| PHP/Laravel | biblioteca open-telemetry/opentelemetry-php |
| Ir/Java | kits nativos maduros, integración sencilla |
| Trabajador de cola | extracción de contexto del mensaje de trabajo |
Instrumentar el proxy inverso sin instrumentar la aplicación significa ver la entrada y la salida, no lo que sucede en el medio.
OpenTelemetry, Jaeger y Tempo: elige tu pila
OpenTelemetry (OTel) recopila seguimientos, métricas y registros con instrumentación única. Exporte a Jaeger (interfaz independiente), Grafana Tempo (almacenamiento de objetos, correlación Loki/Prometheus) o un servicio administrado. En un VPS modesto, un agente OTel Collector de Tempo Cloud o Grafana Cloud evita alojar a Jaeger y Elasticsearch usted mismo.
Muestreo: no rastrear todo el tráfico
El seguimiento de cada consulta en producción genera un volumen de datos que es difícil de almacenar y consultar. Predominan dos estrategias.
El muestreo de cabeza decide la entrada (por ejemplo, una consulta entre cien): simple, pero un caso raro puede escapar de la red. El muestreo de cola mantiene sistemáticamente rutas lentas o erróneas; Grafana Tempo sobresale en este modelo. Configure estas reglas antes de una carga máxima, no durante el incidente.
Correlacionar registros y seguimientos: cerrar el ciclo
Inyecte trace_id en sus registros JSON (“trace_id”: “abc123…”`). En Grafana, un clic desde un intervalo lento abre el registro con el seguimiento de la pila. Procedimiento del incidente: alerta p95 → rastreo más lento → intervalo de SQL defectuoso → consulta exacta en el registro. Excluya datos confidenciales (correo electrónico, tarjeta, identificación del paciente) de los atributos de intervalo.
Limitaciones y dificultades comunes
Abarca demasiado granular → sobrecarga e interfaz ilegible. Relojes no sincronizados → árbol inconsistente (se requiere NTP). Istio rastrea HTTP entre pods, no sus consultas SQL sin instrumentación de la aplicación. “Jaeger instalado” ≠ “pago lento diagnosticable”: comience con las rutas que generan cifras.
La cumbre: tres paneles, cero historias
Esto es lo que las pilas "observables" que se venden llave en mano suelen pasar por alto.
Decide y avanza sin puntos ciegos
En uno o dos días, haga que una arquitectura multiservicio sea diagnosticable. Primero identifique una ruta crítica (pago, inicio de sesión, API de socio) e instrúyala como una prioridad. Implemente OpenTelemetry en el proxy inverso, la aplicación y los trabajadores, luego verifique que el contexto atraviese las colas asincrónicas. Configure el muestreo de cola para mantener los seguimientos erróneos y aquellos que estén por encima de su umbral de latencia. Inyecte trace_id en los registros JSON y pruebe la navegación de intervalo → registro. Simule una solicitud lenta deliberada: si no aparece en un seguimiento de un extremo a otro, corrija la propagación antes del siguiente incidente.
Compare los hosts donde puede instalar sus propios agentes a través del directorio y la comparación. Si Prometheus muestra degradación sin localizar la capa defectuosa, lea Prometheus: elegir métricas que expliquen la lentitud antes de agregar un panel.
Preguntas frecuentes
Seguimientos, registros o métricas: ¿qué elegir?
Los tres se complementan, ninguno reemplaza a los demás. Las métricas se agregan con el tiempo y brindan alertas; los registros describen un momento específico con contexto textual; Los seguimientos conectan segmentos de la misma solicitud de usuario en múltiples servicios. Prometheus por sí solo no dirá qué consulta SQL bloqueó el pago; un seguimiento lo mostrará de un vistazo.
¿Es OpenTelemetry el estándar a adoptar?
Sí, es la opción más sostenible en la actualidad. OpenTelemetry ofrece instrumentación independiente del proveedor, con exportadores a Jaeger, Grafana Tempo, Datadog u otros backends. Evite vincular su aplicación a un único SDK propietario: probablemente cambiará las herramientas de visualización antes de reescribir su código.
¿Cómo propagar el contexto entre servicios?
Utilice los encabezados traceparent y tracestate del W3C desde el punto de entrada a los trabajadores asincrónicos. Cada salto (proxy inverso, llamada gRPC, cola de mensajes) debe transmitir el mismo ID de seguimiento. Sin esta propagación, cada servicio crea un rastro huérfano aislado y se pierde la mitad de la historia en el primer trabajo diferido.
¿Qué muestreo en producción?
Un muestreo de cabeza del 1 al 10 % suele ser suficiente para el tráfico común. El muestreo de cola, ofrecido por Grafana Tempo, mantiene sistemáticamente rastros lentos o erróneos, lo que equilibra el costo de almacenamiento y la capacidad de diagnóstico. Configure estas reglas antes de una carga máxima, no durante el incidente.
La próxima vez que un incidente cruce tres servicios sin un culpable obvio, haga una pregunta: ¿podemos rastrear una sola solicitud de extremo a extremo? Si la respuesta es no, el trace_id faltante costará más que su instrumentación.