OpenTelemetry: logs estables para una telemetría completa
Actualizado: 2026-05-03
Durante años, OpenTelemetry (OTel) avanzó a dos velocidades. Las trazas distribuidas fueron lo primero en madurar, heredando el trabajo de OpenTracing y OpenCensus y resolviendo un problema que nadie más estaba resolviendo bien. Las métricas llegaron después con su propio modelo de datos. Los logs, en cambio, quedaron etiquetados como “en desarrollo” durante demasiado tiempo, y la comunidad se acostumbró a una frase incómoda: “OTel para trazas y métricas, Fluent Bit o Filebeat para logs”. En julio de 2024 esa frase dejó de ser cierta. El grupo técnico del proyecto declaró estables el Logs Data Model 1.0 y el protocolo OTLP para logs, y los SDKs principales (Java, Go, Python, .NET) marcaron su API de logs como GA.
Puntos clave
- OTel Logs GA significa modelo de datos congelado y garantías de compatibilidad hacia atrás: instrumentar logs con OTel ya no es una apuesta técnica.
- La correlación automática (trace_id y span_id inyectados en el LogRecord) convierte una investigación de quince minutos en un hiperenlace.
- El OTel Collector como hub permite fan-out: el mismo log puede ir a Loki para búsqueda y a un SIEM para compliance sin duplicar instrumentación.
- La migración desde Fluent Bit o Filebeat puede ser gradual y no disruptiva gracias a los receivers Fluent Forward y Filelog.
- Si tu stack ya funciona bien con Fluent Bit + Loki, no hay urgencia de migrar: OTel Logs GA es una invitación, no un ultimátum.
Qué significa “estable” en este contexto
La CNCF aplica un criterio estricto: una señal estable implica un modelo de datos congelado, un protocolo con garantías de compatibilidad hacia atrás, y SDKs con APIs públicas que no cambiarán sin un ciclo formal de deprecación. Para los equipos de plataforma, esto se traduce en algo muy concreto: instrumentar logs con OTel ya no es apostar por una tecnología en evolución. El collector soporta pipelines de logs en producción desde hace meses, y los exporters hacia Loki, Elasticsearch, Splunk, Datadog, AWS CloudWatch y GCP Cloud Logging ya no llevan etiqueta de “alpha”. Las APIs puente para integrar loggers existentes (Log4j, java.util.logging, el módulo logging de Python, log/slog en Go 1.21+) permiten adoptar OTel sin reescribir código de aplicación.
Por qué unificar las tres señales importa
La observabilidad moderna se apoya en tres tipos de telemetría con propósitos distintos:
- Métricas: ¿qué está pasando? Cardinalidad baja, coste predecible.
- Trazas: ¿por qué ocurre en este request concreto? Contexto causal, muestreadas.
- Logs: ¿qué ocurrió exactamente, con qué valores, en qué línea? Alta fidelidad, volumen elevado.
El problema histórico es que las tres señales viajaban por tuberías distintas, con agentes distintos y formatos distintos. Correlacionar un log con la traza que lo originó requería extraer un trace_id del mensaje con una expresión regular, pegarlo en la UI de Jaeger y cruzar los dedos.
OTel resuelve esto por diseño. Cuando una aplicación emite un log dentro de un span activo, el SDK inyecta automáticamente trace_id y span_id en el LogRecord. Al llegar a Grafana, Kibana o cualquier frontend compatible, el log aparece con un enlace directo a la traza padre. Ese “click y salto” cambia la experiencia de debugging de forma radical: la pregunta “¿qué request causó este error?” pasa de ser una investigación de quince minutos a un hiperenlace.
Arquitectura y migración
La arquitectura típica coloca un OTel Collector como DaemonSet en Kubernetes o como servicio systemd en VMs. Las aplicaciones le envían logs vía OTLP sobre gRPC (puerto 4317) o HTTP (puerto 4318), y el collector aplica procesadores antes de exportar:
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
attributes:
actions:
- key: deployment.environment
value: prod
action: insert
exporters:
loki:
endpoint: http://loki:3100/loki/api/v1/push
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch, attributes]
exporters: [loki]Una fortaleza del collector es el fan-out: el mismo log puede salir simultáneamente hacia Loki para búsqueda barata y hacia un SIEM para compliance, sin duplicar instrumentación en la aplicación.
Para equipos con Fluent Bit o Filebeat ya desplegado, la migración puede ser gradual y no disruptiva. El collector acepta receivers fluent_forward y filelog, lo que permite mantener los agentes existentes mientras las aplicaciones nuevas empiezan a hablar OTLP directamente. Primero el collector se convierte en el destino común; luego las aplicaciones migran de una en una; finalmente los agentes legacy se retiran cuando la cobertura es total.
La recompensa aparece cuando el stack converge: un único binario que procesa trazas, métricas y logs, con atributos de recurso idénticos (service.name, service.version, deployment.environment, k8s.pod.name) en las tres señales. Las consultas cruzadas dejan de ser un ejercicio de arqueología. Esta convergencia tiene especial valor junto a Parca para la cuarta señal: los profiles de CPU.
Consideraciones prácticas
El coste de almacenamiento no desaparece por usar OTel; los logs siguen ocupando espacio en el backend elegido. Lo que cambia es la capacidad de actuar sobre ese coste desde un único punto: el collector permite muestreo (head-based en origen, tail-based tras bufferizar), filtrado de atributos ruidosos y redacción de datos sensibles antes de que salgan del host.
La cardinalidad sigue siendo el enemigo: atributos con valores de alta variabilidad (request_id, user_id) son tan problemáticos en logs como en métricas. Tratar los identificadores de alta cardinalidad como parte del body del mensaje en lugar de como atributo indexado es la práctica correcta.
La curva de aprendizaje es real. OTel introduce vocabulario propio (signal, resource, instrumentation scope, log record) que se superpone a los conceptos clásicos de logging. La inversión de tiempo en leer las semantic conventions[1] del proyecto paga rápido: son el pegamento que hace que un dashboard construido por un equipo sea reutilizable por otro.
Cuándo no migrar todavía
Si el stack actual de Fluent Bit + Loki funciona bien, con alertas maduras y coste controlado, no hay imperativo de migrar. El caso claro para OTel Logs es greenfield: cualquier servicio nuevo se instrumenta directamente con el SDK y se olvida del agente. El caso intermedio es híbrido: collector como hub, Fluent Bit siguiendo vivo para aplicaciones legacy. El caso ambicioso es migración completa, que solo tiene sentido cuando el valor de la correlación automática con trazas compensa el coste de integración por aplicación.
Lo que sí es innegable es que la dirección del ecosistema está fijada. Los proveedores de observabilidad están alineando sus agentes con OTLP, los frameworks están incluyendo bridges nativos, y los equipos que eligen herramientas para los próximos cinco años lo hacen sabiendo que la telemetría hablará OTel.
Conclusión
OpenTelemetry Logs GA cierra el stack de observabilidad moderna bajo un único protocolo, un único modelo de datos y una única capa de procesamiento. La correlación automática con trazas es el feature que cambia el flujo de debugging de forma irreversible. La migración desde Fluent Bit o Filebeat puede ser gradual sin romper nada. Para nuevos proyectos, OTel es el default sin discusión. Para stacks existentes que funcionan, la transición puede esperar al momento en que el valor de la correlación justifique el esfuerzo de integración.
