Con 1.000 ficheros vigilados, el receptor File Log del OpenTelemetry Collector gastaba unos 77 ms de CPU por segundo solo en guardar por dónde iba leyendo. Desde Collector Contrib v0.164.0 ese checkpoint se escribe en protobuf y el coste baja a unos 16 ms, con un fichero un 35 % más pequeño. No hay que tocar la configuración, pero sí merece la pena entender qué cambia antes de subir de versión en tus DaemonSets.
Qué es el checkpoint y por qué pesaba tanto
Si configuras filelog con una extensión de almacenamiento (normalmente file_storage), el receptor guarda un registro por cada fichero que sigue: una huella con los primeros 1.000 bytes del fichero, el offset de lectura, el número de registro, los atributos y algo de estado para las líneas a medias. Esa lista entera se serializa y se escribe al final de cada ciclo de sondeo. Con el poll_interval por defecto de 200 ms son cinco escrituras por segundo, durante toda la vida del proceso; y solo se lee una vez, al arrancar.
En un nodo de Kubernetes con cientos de logs de contenedores, eso es mucho trabajo repetido. El cambio nace de un informe de octubre de 2025: un usuario veía que su Collector recogiendo logs de Kubernetes con file_storage consumía bastante más que Fluent Bit haciendo algo parecido, y el perfilado señaló la codificación JSON del checkpoint.
El problema de JSON aquí es triple. La huella son bytes en crudo y JSON tiene que pasarlos a texto, lo que la engorda en torno a un tercio y obliga a recodificar en cada guardado. Cada registro repite los nombres de los campos. Y números y fechas viajan como texto. Nadie lee ese fichero salvo el propio receptor, así que JSON pagaba legibilidad que no usaba nadie.
Las cifras
Los mantenedores midieron con los benchmarks de pkg/stanza/fileconsumer, con 1.000 ficheros, huellas de 1.000 bytes y cinco atributos por fichero, en una VM de 4 vCPU:
| Operación (1.000 ficheros) | JSON | Protobuf | Cambio |
|---|---|---|---|
| Guardar | 15,38 ms | 3,21 ms | −79 % |
| Cargar | 28,18 ms | 5,01 ms | −82 % |
| Tamaño del checkpoint | 1,740 MiB | 1,139 MiB | −35 % |
| Memoria asignada por guardado | 5,807 MiB | 2,919 MiB | −50 % |
La mejora se mantiene entre 4 y 6,5 veces desde un solo fichero hasta mil, así que no es un efecto de escala. La cifra que importa en producción es la de guardar, porque es la que se repite cinco veces por segundo: es CPU que vuelve al parseo y a la exportación de logs, y menos escritura en el disco del nodo. El único peaje es que protobuf hace entre un 10 y un 13 % más asignaciones por guardado, aunque más pequeñas y con la mitad de bytes en total.
Lo mismo aplica al archivo que mantiene la opción polls_to_archive, que usa la misma codificación.
Qué cambia en tu configuración
Nada. Al arrancar, v0.164.0 sigue leyendo los checkpoints JSON existentes y los reescribe en protobuf en el siguiente guardado, de modo que conservas los offsets y no se duplican ni se pierden logs. El formato protobuf deja de ser opcional: es el único que se escribe a partir de esta versión.
Esta es la configuración afectada; si tu filelog no tiene storage, los offsets viven en memoria y este cambio no te toca (aunque entonces cada reinicio relee o salta logs, que es un problema mayor):
extensions:
file_storage:
directory: /var/lib/otelcol/file_storage
receivers:
filelog:
include: [/var/log/pods/*/*/*.log]
storage: file_storage
service:
extensions: [file_storage]Cómo actualizar a v0.164.0
filelog no está en la imagen base del Collector: viene en la distribución Contrib o en la orientada a Kubernetes. Con Docker:
docker pull otel/opentelemetry-collector-contrib:0.164.0Con el chart de Helm oficial, actualiza el repositorio y comprueba que la versión de la aplicación del chart es 0.164.0 o posterior antes de hacer el upgrade de tu release:
helm repo update open-telemetry
helm search repo open-telemetry/opentelemetry-collectorCómo validarlo antes de producción
- Despliega la nueva versión en un nodo o un entorno de pruebas que ya tenga checkpoints JSON en
file_storage, para ejercitar la conversión y no solo un arranque en limpio. - Reinicia el pod un par de veces y comprueba en el backend que no aparecen líneas duplicadas ni huecos alrededor de cada reinicio.
- Compara la CPU del Collector antes y después en los nodos con más ficheros: es donde se nota la diferencia.
- Mira el tamaño del directorio de
file_storage: debería bajar en torno a un tercio.
La cautela que sí tiene este cambio es la vuelta atrás: el anuncio explica cómo se pasa de JSON a protobuf, pero no dice que una versión anterior sepa leer un checkpoint en protobuf. Si tu plan de despliegue incluye un rollback automático, pruébalo en ese entorno de pruebas antes de confiar en que conservará los offsets.
Fuentes
- Faster, smaller checkpoints: the File Log receiver now uses protobuf (OpenTelemetry blog, 28 de octubre de 2026)
- Install the Collector with Docker (documentación de OpenTelemetry)
- OpenTelemetry Collector Chart (documentación de OpenTelemetry)