Telemetría sin misterio: Prometheus, Loki, Tempo y Grafana, y por qué OpenTelemetry

Es lunes, nueve de la mañana, y las transferencias de un banco tardan el triple de lo normal. Llegan las quejas, se abre un incidente y se sientan en una misma llamada cinco equipos: canales digitales, el sistema central, antifraude, redes e infraestructura. Cada uno revisa su propia pantalla y cada uno concluye lo mismo: «de nuestro lado todo está bien». Pasan dos horas antes de que alguien note que la lentitud estaba en la consulta de un solo servicio.

Ese escenario, ilustrativo y sin cliente detrás, no habla de un equipo malo. Habla de un sistema del que nadie puede ver el recorrido completo de una operación. La telemetría es la respuesta a ese problema: los datos que un sistema emite sobre sí mismo mientras trabaja, para que se pueda entender desde fuera, sin abrirlo y sin adivinar. Este artículo es para quien responde por esos sistemas en un banco, una fintech, una aseguradora, una cadena de retail o una empresa regulada, y también para el director de negocio que quiere entender qué le están pidiendo cuando el equipo técnico dice «necesitamos observabilidad».

Hablaremos de cuatro herramientas abiertas muy usadas —Prometheus, Loki, Tempo y Grafana— y de un estándar, OpenTelemetry, que las une. Explicaremos qué responde cada una, cómo se cruzan entre sí, por qué conviene un estándar común, cómo se montan en contenedores y en Kubernetes, cuándo basta con leer los logs y cuándo hay que instrumentar el software por dentro, y qué cuesta y qué riesgos trae todo esto.

Tres señales para tres preguntas distintas

Un sistema en producción puede contar su historia de tres maneras, y cada una responde una pregunta diferente. Este artículo se concentra en las tres señales operativas más habituales, que OpenTelemetry llama señales [2]: métricas, trazas y logs.

• Métricas: ¿qué está pasando, y cuánto? Una métrica es una medición capturada mientras el sistema corre: cuántas transferencias por minuto, cuánto tardó el 95 % de ellas, cuántas fallaron. Es un número en el tiempo, barato de guardar y excelente para ver una tendencia o disparar una alerta. No dice cuál operación falló.
• Trazas: ¿por dónde pasó esta operación y dónde se detuvo? Una traza es el recorrido completo de una solicitud por todos los servicios que tocó, con el tiempo que pasó en cada uno [2]. Es el mapa de una sola operación. Cada tramo de ese mapa se llama span.
• Logs: ¿qué dijo el sistema en ese momento? Un log es el registro de un evento: una línea de texto o de datos con la fecha, la gravedad y el mensaje. Es el detalle fino: «se agotó el tiempo de espera del pool de conexiones».

Ninguna de las tres basta sola. La métrica avisa pero no localiza; la traza localiza pero no explica; el log explica pero, sin contexto, es una aguja en un pajar. La buena práctica, y el hilo de este artículo, es usarlas en cadena. En una instrumentación bien diseñada, la métrica suele advertir, la traza suele acotar el recorrido y los logs pueden aportar el detalle; la calidad de la respuesta depende de qué se haya emitido y conservado.

Qué responde cada herramienta

Cada señal tiene una herramienta abierta pensada para guardarla y consultarla. Antes de la tabla, una aclaración útil para un comité: ninguna de estas herramientas es intercambiable con otra. Son almacenes especializados.

Dos precisiones que ahorran malentendidos. La primera: Prometheus no es una caja registradora. Su propia documentación advierte que, si se necesita exactitud total, como la facturación por solicitud, no es buena opción [9]. Sirve para operar —saber si el sistema está sano—, no para conciliar. En un banco o una fintech esa frontera importa: la conciliación vive en los registros contables, no en un tablero de latencia.

La segunda: Loki es barato justamente porque no indexa el contenido de los logs, solo unas pocas etiquetas por flujo (de qué servicio y de qué entorno viene). Los datos se comprimen en bloques y se guardan en almacenamiento de objetos [15]. La contrapartida es que buscar texto dentro de los logs se hace en el momento de la consulta, no con un índice previo, y que las etiquetas hay que elegirlas con cuidado. Volveremos a eso en los costos.

El papel de Grafana

Grafana es la ventana. Según su documentación, permite consultar, visualizar, alertar y explorar métricas, logs y trazas sin importar dónde estén almacenados [19]. Cada almacén se conecta como una fuente de datos: Prometheus, Loki y Tempo son tres fuentes, y Grafana puede tener otras al lado, como bases de datos SQL [20].

Su valor no está en el tablero bonito, sino en que cruza las fuentes. Desde un mismo lugar se puede ir de una gráfica a una traza y de una traza a sus logs. Para un directivo, eso se traduce en algo concreto: Grafana puede concentrar la investigación en una vista si se configuran fuentes, permisos y enlaces, en lugar de cinco pantallas y una llamada.

Cómo se cruza la información

Que las tres señales existan no significa que estén conectadas. La conexión no aparece por instalar Grafana: se diseña desde que se instrumenta el software y se prueba de punta a punta. El hilo conductor es un identificador, el trace_id, que viaja con cada operación. El estándar de propagación que OpenTelemetry usa por defecto, W3C Trace Context, lleva ese identificador en una cabecera llamada traceparent de un servicio al siguiente [2].

Imagine el trace_id como el número de guía de un paquete. Si cada servicio lo estampa en lo que produce, después se puede pedir «todo lo que ocurrió con la guía 4F2A…».

De la métrica a la traza: los exemplars

Un exemplar es una muestra concreta pegada a una métrica agregada. Piense en una gráfica de latencia: cada punto resume miles de operaciones. Un exemplar es, en ese punto, el ejemplo de una operación real —con su trace_id— que contribuyó a esa medición. En Grafana aparece como una estrella sobre la gráfica; al hacer clic, se abre en Tempo la traza de esa operación [20].

Para que el clic de la gráfica a la traza funcione, cuatro piezas deben estar encendidas; si falta una, el clic no lleva a ninguna parte. La documentación de Grafana lo resume así: las métricas dan la vista agregada y las trazas, la vista fina de una solicitud [20]. Conviene conocer las condiciones antes de prometérselo a nadie:

1. La aplicación tiene que emitir el trace_id junto con la medición, dentro de una traza que se esté conservando.
2. Prometheus tiene que almacenar los exemplars. Hoy esa capacidad se activa con una bandera marcada como experimental y viene desactivada por defecto [12].
3. En Grafana hay que configurar la fuente Prometheus para que el enlace apunte a Tempo y diga qué campo trae el trace_id [20].
4. La traza referida tiene que existir todavía: si el muestreo o la retención ya la descartaron, el clic no lleva a ninguna parte.

Una ruta alterna es que Tempo calcule métricas a partir de las trazas —tasa de solicitudes, errores y duración, el conocido trío RED (Rate, Errors, Duration), las tres medidas estándar con que se vigila un servicio— y las envíe a una base compatible con Prometheus, con sus exemplars [17]. Esa ruta debe probarse contra los límites de series activas, un tema que se retoma en los costos.

De la traza al log: el `trace_id` en cada línea

Desde una traza en Tempo, Grafana puede abrir los logs de ese servicio en esa ventana de tiempo, consultando Loki. Eso se configura en la fuente de datos de Tempo (trace to logs), y existe un enlace equivalente hacia las métricas (trace to metrics) [21]. Para correlacionar un log con la traza, incluya el trace_id; añada el span_id cuando necesite acotar la búsqueda al span que emitió el log. El modelo de datos de logs de OpenTelemetry los contempla como campos propios [40], y para formatos que no son OTLP recomienda llamarlos trace_id, span_id y trace_flags [41].

Del log a la traza

El camino inverso se configura en Loki con campos derivados (derived fields): una regla que extrae el trace_id de la línea y lo convierte en un enlace a Tempo [47]. Ambos lados son necesarios: configurar solo Tempo no vuelve navegable un log hacia su traza.

Una regla de oro de este cruce: el trace_id, y en general cualquier identificador de cliente, orden, cuenta o póliza, no debe ser una etiqueta de Loki. Debe viajar dentro del contenido del log, o como metadato estructurado. Más adelante se explica por qué [14].

Por qué OpenTelemetry y no cada tecnología directo

Las cuatro herramientas anteriores tienen sus propias formas de recibir datos. Se podría programar cada aplicación para hablar directamente con cada una: una biblioteca para métricas de Prometheus, otra para logs hacia Loki y otra para trazas hacia Tempo. Funciona, pero ata el código de cada servicio a tres modelos distintos, tres estrategias de reintento y tres rutas de migración.

OpenTelemetry (se abrevia OTel) es un proyecto de la CNCF, la fundación que aloja a Kubernetes y a Prometheus. Se define como un marco para generar, exportar y recolectar telemetría; es neutral frente a proveedores y, importante, no es un backend: no guarda ni dibuja nada [1]. Aporta cuatro piezas:

• APIs y SDK: bibliotecas por lenguaje con las que el software emite métricas, trazas y logs con un modelo común.
• OTLP: el protocolo común para transportar las tres señales, sobre gRPC (puerto 4317 por defecto) o HTTP (4318) [4].
• Convenciones semánticas: nombres estándar para lo que se mide, de modo que «el servicio» o «el pod» se llamen igual en las tres señales [46]. Sin ese acuerdo, el cruce entre herramientas se rompe.
• Collector: un programa intermedio que recibe la telemetría, la enriquece, la filtra y la reenvía a uno o varios destinos [6].

La consecuencia práctica: la aplicación emite una sola vez, en un idioma estándar, y las decisiones de a dónde va, qué se filtra y qué se oculta viven en una configuración controlada, no regadas en el código de cada equipo. Los propios almacenes ya hablan ese idioma: Loki, Tempo y Alloy pueden recibir OTLP, y Prometheus puede recibir métricas OTLP cuando se habilita explícitamente --web.enable-otlp-receiver [13][16][18][26].

Para un directivo, el argumento es de portabilidad y control. La documentación de OpenTelemetry lo plantea como no quedar atado a un proveedor y aprender un único conjunto de convenciones [1]. OpenTelemetry reduce la dependencia del código respecto del destino, aunque una migración aún puede requerir validar convenciones, exportadores, muestreo, tableros, alertas y retención; el destino se cambia en el Collector.

Dos matices de honestidad, porque este tipo de promesa se infla fácil:

• Portabilidad no es gratuita. Aun con OpenTelemetry, los tableros, las alertas y las consultas escritas en PromQL, LogQL y TraceQL se reescriben si se cambia de almacén. Lo que se ahorra es la reinstrumentación del software, que suele ser la parte más cara.
• La madurez varía por señal y por lenguaje. Según la especificación, trazas, métricas y logs tienen protocolo estable, pero el SDK de métricas figura como «mixto» y los perfiles siguen en desarrollo [3]. Por lenguaje, Java tiene las tres señales estables; Go y Python y JavaScript tienen trazas y métricas estables, mientras que los logs están en candidato a versión final en Go y en desarrollo en Python y JavaScript [5]. Quien programa en Java parte de un terreno más sólido; quien programa en otros lenguajes debe verificar el estado de los logs antes de apostar por ellos.

Como referencia de adopción, en la encuesta anual de la CNCF de 2024, en la pregunta sobre proyectos incubados (n=689), el 39 % reportó OpenTelemetry en producción y el 23 % en evaluación; es una muestra de su comunidad, no una cuota de mercado [44].

Cómo se monta: contenedores y Kubernetes

La telemetría necesita tres cosas en el camino: quien la genere (el software), quien la recolecte y procese (el Collector o un agente) y quien la guarde y muestre (Prometheus, Loki, Tempo, Grafana). Cambia dónde se coloca el recolector según la plataforma.

En Docker y Docker Compose

Compose declara varios servicios, redes y volúmenes en un solo archivo, y por eso se usa para desarrollo, pruebas integradas y entornos pequeños [28]. El montaje típico es: las aplicaciones envían OTLP a un contenedor con el Collector (o Alloy); el Collector reparte las trazas a Tempo, los logs a Loki y las métricas a Prometheus; y Grafana consulta a los tres. El Collector se ejecuta como una imagen oficial con su archivo de configuración montado; sin ese archivo no arranca [28].

Hay dos detalles de los logs en Docker que suelen sorprender:

• Docker captura por defecto la salida estándar y la salida de error estándar. Si la aplicación escribe únicamente a archivos, docker logs no mostrará esas líneas. Por eso las imágenes oficiales de servidores web redirigen sus archivos a la salida estándar [28].
• El driver por defecto no rota los logs. El driver json-file no tiene límite de tamaño de forma predeterminada, y Docker recomienda el driver local, que rota por defecto (según Docker, archivos de 20 MB, hasta cinco) [28]. Un disco lleno por logs es un incidente de operación real.

Además, el modo de entrega importa: en modo bloqueante, que es el predeterminado, un driver lento puede frenar a la aplicación; en modo no bloqueante usa un búfer y, si se llena, descarta mensajes [28]. Y con el driver de Fluentd en modo síncrono, si no hay conexión el contenedor se detiene [29]. Hay que elegir con intención entre no perder logs y no frenar el servicio.

En Kubernetes

Kubernetes recomienda que las aplicaciones escriban a la salida estándar y que el almacenamiento de logs sea externo, con ciclo de vida separado del pod; no trae almacenamiento de logs propio [27]. La rotación la hace el kubelet (valor predeterminado de Kubernetes: archivos de 10 MiB y cinco por contenedor) y kubectl logs solo ve el archivo más reciente [27]. Es decir, sin un recolector, los logs de un pod que se reinició o rotó pueden perderse.

La documentación de Kubernetes describe tres patrones para recolectar a nivel de clúster: un agente por nodo, un agente en cada pod, o que la aplicación envíe directo al destino [27]. OpenTelemetry los traduce a estos montajes:

Cuatro cuidados que la documentación señala y que, cuando se ignoran, se pagan en retrabajo durante la implantación:

1. Etiquetar cada log con su dueño. Un log leído de un archivo no sabe de qué pod viene. El procesador k8sattributes pega el pod, el espacio de nombres, el despliegue y el nodo a cada registro, y es estable para las tres señales [33]. La lectura de archivos (filelog) está en beta para logs [32] y, por defecto, solo lee lo que llega después de arrancar; sin guardar su posición, un reinicio puede duplicar o perder líneas [32].
2. Una métrica, un solo escritor. Dos recolectores reportando la misma serie producen datos fuera de orden en Prometheus [8].
3. El recolector también falla. Con una cola de envío, reintentos y almacenamiento persistente configurados, puede resistir fallas transitorias; aun así, disco lleno, caída prolongada o límites de reintento pueden causar pérdida [35]. Se dimensiona y se vigila como un servicio más.
4. Con el Operator, el orden importa. La instrumentación automática exige que su recurso de configuración exista antes del pod, la anotación en el lugar correcto y un reinicio; además sobrescribe variables como JAVA_TOOL_OPTIONS [34].

Un aviso sobre Promtail. Es el agente de logs que muchos equipos instalaron hace años para Loki. Grafana declaró su fin de vida el 2 de marzo de 2026: ya no recibe actualizaciones ni soporte comercial, y se recomienda migrar a Alloy, con una herramienta de conversión [22]. Quien aún lo tenga en producción opera sin respaldo del fabricante.

¿Un agente que lee el log, o instrumentar la aplicación?

Es la decisión más práctica de todo el tema, y se plantea mal cuando se presenta como «lo viejo contra lo moderno». Son dos caminos con ventajas distintas.

• Un agente que lee es un programa que toma lo que el software ya escribe —a la salida estándar o a un archivo— y lo lleva al almacén. No requiere cambiar el software. A cambio, exige interpretar (parsear) líneas de formatos diversos, y no puede inventar un trace_id que la aplicación no escribió [32][40]. OpenTelemetry describe las dos vías —leer archivos o salida estándar, o enviar directo por OTLP— y resume el compromiso así: la primera no requiere cambios pero exige un parseo robusto; la segunda evita la complejidad de los archivos pero requiere configuración en la aplicación [39].
• Instrumentar por dentro es usar el SDK de OpenTelemetry o un appender —un adaptador que conecta el sistema de logs que el framework ya usa, como Logback o Log4j en Java, con OpenTelemetry— para que cada registro salga con su contexto de traza y con datos estructurados [38]. OpenTelemetry no reemplaza a esas bibliotecas de logs: las puentea [38]. A cambio, hay que modificar y desplegar código.

La respuesta madura suele ser híbrida, con una condición: no duplicar. Si la aplicación exporta un evento por su appender y, además, ese mismo evento se vuelve a leer del archivo, el almacén recibe dos copias. Cada flujo se declara para un camino o para el otro.

Una nota sobre la «instrumentación automática». En Java, el agente de OpenTelemetry se adjunta al arrancar (-javaagent) e inyecta código en tiempo de ejecución para capturar telemetría de las bibliotecas comunes: las llamadas HTTP que entran y salen, la base de datos [37]. Da visibilidad rápida sin cambiar el código fuente. Pero cubre los bordes técnicos, no la lógica del negocio: la documentación es explícita en que el código propio de la aplicación normalmente no se instrumenta solo [36]. Una decisión como «aprobación de crédito» o «asignación de inventario» solo aparece en la traza si alguien la marcó en el código. Lo que compra la instrumentación automática es un buen punto de partida, no el final del trabajo.

Qué mirar en cada industria

Estos son escenarios ilustrativos, sin clientes ni cifras medidas. Cada uno recorre la misma cadena: métrica que advierte, traza que acota, log que aporta el detalle.

Banca: transferencias y autorizaciones. Se vigila, en métricas, el tiempo en que responde el 95 % de las transferencias y la tasa de errores de autorización. Cuando sube, el exemplar abre la traza de una transferencia lenta; la traza muestra que el tiempo se fue en la consulta al sistema central, y el log del mismo trace_id dice que se agotó el tiempo de espera en el pool de conexiones. Con esa cadena montada y probada, saber dónde y por qué deja de depender de juntar a cinco equipos; el tiempo que tarde depende de que el cruce esté configurado como se describió arriba. Aviso: estas métricas sirven para operar, no para conciliar [9].

Fintech: APIs abiertas. Un aliado que consume sus APIs reporta que «a veces» fallan los pagos. Sin telemetría es una anécdota. Con trazas se puede buscar solo las operaciones fallidas de esa ruta y ver si coinciden con la tardanza de una consulta antifraude externa. También se vigilan la tasa de errores por aliado, los rechazos por límite de solicitudes y la latencia de las notificaciones (webhooks). Se separa así «falló nuestro sistema» de «se degradó un tercero», con evidencia.

Seguros: cotización y emisión. Una cotización tarda 40 segundos en la hora pico. La traza revela que cada cotización consulta en serie a tres sistemas de tarifas, y la métrica de errores muestra que uno de ellos se degrada al mediodía. Se decide paralelizar o poner una caché, no «comprar más servidores». En emisión, se mide el tiempo de punta a punta y dónde se acumulan las colas.

Retail: checkout e inventario. En una promoción, el carrito «se queda pensando». Las métricas muestran saturación del servicio de inventario; la traza revela que cada visita a un producto lo consulta doce veces. Se corrige la causa, no el síntoma. Y aquí aparece un costo concreto: si se etiquetan las métricas por producto o por cliente, se dispara la cardinalidad (más abajo).

Empresa regulada: facturación. Un auditor pregunta qué pasó con una solicitud de facturación el martes. Con el identificador de traza se reconstruye el recorrido por todos los sistemas, y en los logs asociados se ve qué se hizo y cuándo. Con una salvedad: la telemetría ayuda a entender el comportamiento técnico, pero no sustituye un registro de auditoría formal, íntegro y con la retención aprobada. Las trazas se muestrean y se conservan poco tiempo; eso se decide con Riesgo, Privacidad y Jurídico, no con una configuración técnica.

Costos y riesgos: lo que pocas veces se dice

En muchos casos, el costo relevante proviene del volumen, la cardinalidad, la retención, el cómputo de consulta y la operación; el peso de cada rubro depende de la plataforma y del contrato. Lo que más se decide, y más pesa, son tres cosas.

Cardinalidad: cada etiqueta nueva es una factura

La cardinalidad es el número de combinaciones distintas de etiquetas. En Prometheus, cada combinación nueva es una serie nueva que consume memoria, disco y cómputo. La guía del proyecto recomienda mantener la cardinalidad de cada métrica por debajo de 10 y, si pasa de cerca de 100 o puede crecer sin límite, buscar otra solución; su ejemplo es claro: 10,000 nodos con decenas de sistemas de archivos dan alrededor de 100,000 series, aceptable, pero añadir una cuota por usuario produce millones [10]. Tampoco se usan etiquetas para identificadores de usuario o correos [11]. Estas cifras son una guía de prácticas del proyecto, no un límite técnico duro.

Loki tiene su propia versión: etiquetas de valores ilimitados obligan a construir un índice enorme y miles de bloques diminutos, y el sistema rinde muy mal. La guía de Grafana —cifra de proveedor— sugiere no pasar de 10 a 15 etiquetas y mover los identificadores al contenido o a los metadatos estructurados [14].

Traducido al negocio: en la promoción de fin de año del escenario de retail, si cada cliente es una etiqueta, la factura y la lentitud crecen justo cuando más se necesita el sistema.

Datos personales: lo que no se emite, no se filtra

Los logs y las trazas tienen la mala costumbre de capturar de más. Un servicio que, por error, escribe el nombre completo y el documento de identidad de quien sube un archivo deja ese texto en el almacén, con su retención, a disposición de quien tenga acceso al tablero. OpenTelemetry es claro: no puede saber qué es sensible en su contexto, la responsabilidad regulatoria es de quien implementa, y evitar emitir el dato es mejor que remediarlo después; incluso advierte que aplicar un hash a un identificador puede no dar anonimato cuando el universo de valores es pequeño [42].

El Collector ofrece procesadores para quitar o transformar atributos, pero conviene medir su madurez: para logs, redaction y filter figuran en alfa y transform en beta [43]. Apoyar toda la protección en una pieza alfa es frágil. La práctica prudente son dos barreras: no emitir el dato desde la aplicación y, como segunda línea, filtrar en el Collector. En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente (publicada en el Diario Oficial el 20 de marzo de 2025, que abrogó la de 2010) tiene por objeto regular un tratamiento legítimo, controlado e informado, y obliga al responsable a mantener medidas de seguridad administrativas, técnicas y físicas [45]; qué se conserva y por cuánto tiempo se valida con Privacidad y Jurídico.

Retención y disco: nadie la decide por usted

Kubernetes no retiene logs a largo plazo, y Docker, por defecto, puede llenar el disco [27][28]. La retención de largo plazo es una decisión del almacén y del negocio, y debe distinguir entre métricas, logs, trazas y evidencia regulatoria. No incluimos cifras de retención ni precios porque dependen del proveedor y del contrato; cualquiera que se cite sin esos datos es una suposición.

Quién ve qué, y quién lo opera. Los tableros de Grafana muestran lo que los logs y las trazas contienen, así que el acceso se diseña por área: cada equipo ve los tableros y las fuentes que le corresponden, y quien consulta logs con datos personales es un grupo más reducido que quien mira una gráfica de latencia. Y operar este conjunto de herramientas requiere al menos una persona que entienda las consultas (PromQL, LogQL, TraceQL) y el Collector; es un costo humano, no solo de infraestructura, que conviene contar desde el principio.

A eso se suma el muestreo: conservar todas las trazas es caro, y conservar solo algunas obliga a decidir cuáles, por ejemplo todas las que fallan y una fracción de las sanas. Con un muestreo que se hace en el gateway, el enrutamiento tiene que mandar todos los spans de una misma traza al mismo recolector [8]. Y una nota de entrega del protocolo: ante fallas transitorias, una implementación puede reintentar el envío; si no recibió acuse, eso puede producir duplicados. Por ello, almacenamiento y consultas deben tolerarlos, sin asumir entrega garantizada [4].

Cómo empezar sin querer hacerlo todo

1. Elija un flujo de negocio crítico, no «todo el sistema». Una transferencia, una cotización, un checkout, una factura. Si falla, duele; por eso se instrumenta primero.
2. Defina de antemano las tres o cuatro preguntas que quiere poder contestar y la señal que las responde: ¿qué mide la métrica, qué marca la traza, qué debe decir el log?
3. Acuerde los nombres desde el principio. Un nombre de servicio y un entorno consistentes en las tres señales valen más que cualquier tablero [46].
4. Empiece con lo que no requiere tocar el software. Un agente que lee la salida estándar y, en Java, la instrumentación automática dan una primera vista en poco tiempo [36][37].
5. Instrumente por dentro lo que importa al negocio: los pasos de ese flujo, con el trace_id en cada línea de log.
6. Fije reglas de cardinalidad y de datos personales antes de abrir la llave: lista de atributos permitidos, qué datos no se emiten y quién decide la retención.
7. Pruebe el cruce de punta a punta: del clic en la gráfica a la traza y de la traza al log. Si algún salto falla, es cuando se aprende qué faltaba, no en un incidente real.
8. Retire lo que ya no tiene soporte. Si hay Promtail, planee la migración [22].

Antes de empezar, conviene acordar por escrito, para el primer flujo: qué flujo se incluye, quién es su dueño, la línea base y la meta de latencia y error, la cobertura mínima de trazas, los atributos prohibidos, la retención, el presupuesto mensual y la prueba de correlación de la métrica a la traza y al log.

Saber qué herramienta existe es la parte fácil. Lo difícil es saber qué parte de su plataforma ya emite lo que hace falta, qué se puede observar sin tocar el software y qué requiere instrumentación, dónde hoy se están colando datos personales en los logs y qué costo trae cada decisión. Eso es lo que revisamos en un diagnóstico: le entregamos un mapa de señales de sus flujos críticos, la tabla de qué se cubre con un agente y qué requiere instrumentar, el inventario de datos personales que hoy llegan a los logs, los factores de costo que más pesan en su caso y el orden recomendado para adoptarlo, para que TI, seguridad, riesgo y negocio decidan con la misma información.