Si pensabas que podrías seguir ignorando el avance de OpenTelemetry (OTel) mientras te escondías en tus scripts legacy, Google Cloud acaba de enviarte un recordatorio amistoso —o una amenaza elegante, según cómo lo mires—. La plataforma ha lanzado una nueva API de ingestión que soporta de forma nativa los protocolos
Si pensabas que podrías seguir ignorando el avance de OpenTelemetry (OTel) mientras te escondías en tus scripts legacy, Google Cloud acaba de enviarte un recordatorio amistoso —o una amenaza elegante, según cómo lo mires—. La plataforma ha lanzado una nueva API de ingestión que soporta de forma nativa los protocolos de OTel (OTLP) para logs, trazas y métricas.
Básicamente, Google está ordenando la casa. A partir del 4 de marzo de 2026, la nueva API telemetry.googleapis.com se convertirá en una dependencia obligatoria para las APIs actuales de Cloud Logging, Cloud Trace y Cloud Monitoring. Es el fin de una era y el comienzo de una donde, por fin, parece que todos hablaremos el mismo idioma técnico.
Para los que trabajamos en SRE o DevOps, sabemos que la fragmentación de APIs es un dolor de cabeza constante. Google está intentando mitigar esto unificando los endpoints. La jugada es simple: quieren que la transición hacia herramientas de recolección modernas sea "seamless" (palabra favorita del marketing para decir que, si algo falla, probablemente sea culpa de tu configuración y no de ellos).
telemetry.googleapis.com.OpenTelemetry no es solo un capricho de la industria; es el estándar de facto para la observabilidad moderna. Al mover la ingestión hacia un endpoint unificado de OTel, Google está facilitando que saques tus datos de su ecosistema si algún día decides que el "vendor lock-in" te está saliendo muy caro.
Además, el soporte nativo para OTLP (OpenTelemetry Protocol) significa menos transformaciones de datos, menor latencia y, en teoría, menos bugs en el pipeline de telemetría.
El protocolo OTLP utiliza gRPC y HTTP/JSON para transportar datos de telemetría. Aquí te dejo un ejemplo conceptual de cómo se vería una configuración básica de un exportador en un colector de OTel para apuntar a Google Cloud:
exporters:
googlecloud:
project: "tu-proyecto-123"
log:
default_log_name: "opentelemetry.io/collector-export"
retry_on_failure:
enabled: true
service:
pipelines:
logs:
receivers: [otlp]
processors: [batch]
exporters: [googlecloud]
La buena noticia para los que practicamos "SRE para flojos" es que no se requiere ninguna acción inmediata. Google hará el trabajo sucio por ti. No habrá interrupciones en tus servicios actuales, o al menos eso prometen en su documentación oficial (y ya sabemos que las promesas en la nube son tan estables como un pod sin livenessProbe).
Si por alguna razón mística o conspiranoica decides que no quieres esta API, puedes desactivarla manualmente, aunque eso sería como intentar nadar contra la corriente en el Mapocho: sucio y probablemente termines mal.
Si quieres profundizar en cómo OpenTelemetry está devorando el mundo de la observabilidad, te recomiendo revisar estos enlaces:
En resumen, el cambio es inevitable. Google está moviendo las piezas para que la observabilidad sea más coherente. Así que, relájate, tómate un mote con huesillo y deja que los scripts de automatización de Google hagan su magia. Tienes hasta el 2026 para pretender que esto te tomó por sorpresa.
La solución no es meter la IA de vuelta en el cajón ni enterrar la confusión o los riesgos bajo más procesos. Es contratar y desarrollar más pensadores sistémicos.
El Ejecutivo ha sido incapaz de conformar el Consejo Directivo de la nueva Agencia de Protección de Datos Personales, el organismo encargado de fiscalizar el cumplimiento de la norma.
