El ecosistema CNCF (Cloud Native Computing Foundation) se ha convertido en el referente para arquitectos de observabilidad y SREs que diseñan plataformas a gran escala. Su catálogo de proyectos abarca desde soluciones base para orquestación y redes hasta herramientas de monitorización, trazabilidad y seguridad. Sin embargo, la velocidad de adopción y evolución de estos proyectos es desigual. Algunos se han consolidado como piezas clave en arquitecturas de producción, mientras otros muestran señales de estancamiento o pérdida de relevancia.
En este artículo abordaremos desde un punto de vista técnico y con experiencia real cuáles proyectos del CNCF Landscape han alcanzado madurez suficiente para ser considerados en entornos críticos, cuáles están en fase de consolidación con casos de uso específicos y cuáles parecen perder tracción frente a alternativas externas o cambios en los requerimientos del mercado. La intención es aportar criterio para decidir dónde enfocar esfuerzos de investigación o integración en plataformas de observabilidad y SRE.
Antes de entrar en materia, conviene recordar que la CNCF clasifica sus proyectos albergados en tres niveles de madurez: sandbox (fase temprana, exploración), incubating (en proceso de maduración con adopción creciente) y graduated (producción, adopción amplia, comunidad sólida). Además, en el CNCF Landscape aparecen productos y herramientas de terceros que no son proyectos CNCF albergados, pero que forman parte del ecosistema cloud native. Esta distinción es importante porque a menudo se confunden ambas categorías.
Proyectos maduros y ampliamente adoptados
En la cima de madurez encontramos proyectos con una trayectoria consolidada y amplia adopción en producción. Prometheus es el ejemplo paradigmático: su modelo de monitorización basado en métricas de series temporales y su ecosistema de exportadores siguen siendo la base para la mayoría de arquitecturas observables. Es proyecto CNCF graduado desde 2018, el segundo en graduarse después de Kubernetes. Su diseño descentralizado, la integración con Alertmanager y la compatibilidad con estándares abiertos como OpenMetrics garantizan su vigencia. Sin embargo, su escalabilidad horizontal requiere soluciones complementarias como Thanos o Cortex para entornos de muy alto volumen, lo que añade complejidad operativa.
OpenTelemetry merece un lugar destacado en esta categoría. Es el segundo proyecto más activo de toda la CNCF, solo por detrás de Kubernetes, y se ha convertido en el estándar de facto para la instrumentación de aplicaciones cloud native. Su ambición de unificar la recolección de métricas, logs y trazas bajo un estándar abierto ha generado un ecosistema enorme, con SDKs estables para los principales lenguajes y un Collector maduro y extensible. A día de hoy, la mayoría de los grandes proveedores de observabilidad (Dynatrace, Datadog, New Relic, Splunk, Grafana Labs) soportan nativamente la ingesta de datos en formato OTLP, lo que demuestra que OpenTelemetry ha cruzado definitivamente el umbral de la adopción masiva.
Un dato especialmente relevante para quienes trabajamos con plataformas comerciales: Dynatrace no solo soporta OpenTelemetry como fuente de datos, sino que contribuye activamente al proyecto. La compañía participa en distintos grupos de trabajo (SIGs) y en la comunidad técnica, lo que refuerza su apuesta por este estándar.
La plataforma acepta datos nativos en formato OTLP y los enriquece automáticamente con contexto topológico mediante Davis AI y su pipeline de ingestión (OpenPipeline), lo que permite mantener una visión completa del sistema incluso con instrumentación heterogénea.
La documentación oficial de Dynatrace sobre integración con OpenTelemetry es extensa y demuestra que la apuesta por los estándares abiertos es estratégica, no testimonial. Para quienes gestionamos tenants Dynatrace en producción, esto significa que podemos combinar instrumentación OneAgent con instrumentación OpenTelemetry según las necesidades de cada servicio, sin perder capacidades analíticas.
Esta tendencia no es exclusiva de Dynatrace. La adopción de OpenTelemetry por parte de los principales proveedores comerciales confirma que el mercado ha validado el estándar: los clientes quieren instrumentación abierta y portable, y los proveedores compiten en la capa de análisis y valor añadido sobre esos datos, no en la captura propietaria. Para un SRE o un arquitecto de observabilidad, esto simplifica enormemente las decisiones de instrumentación a medio plazo.
Dicho esto, OpenTelemetry todavía presenta retos reales en despliegues a gran escala. La madurez de los SDKs varía según el lenguaje (Go y Java están muy avanzados; otros lenguajes van más rezagados), y la complejidad operativa del Collector en arquitecturas distribuidas no es trivial. No es un proyecto que despliegues y olvides: requiere planificación, gobierno de convenciones semánticas y disciplina en la gestión de etiquetas para no generar problemas de cardinalidad.
En el ámbito de la trazabilidad distribuida, Jaeger sigue siendo un proyecto CNCF graduado relevante, con una comunidad activa y buena integración con OpenTelemetry. Sin embargo, su papel ha evolucionado: cada vez más organizaciones lo utilizan como backend de desarrollo y pruebas, mientras que para producción a gran escala optan por soluciones como Tempo o backends comerciales.
En logging, Fluentd es el proyecto CNCF graduado de referencia para la recolección y envío de logs. Su arquitectura de plugins y su estabilidad probada en producción lo mantienen como una opción sólida, aunque Fluent Bit (proyecto CNCF graduado también, más ligero y optimizado para contenedores) ha ganado terreno en despliegues Kubernetes por su menor consumo de recursos.
Proyectos del ecosistema Grafana: presentes en el Landscape, pero no albergados por CNCF
Es importante aclarar un punto que genera confusión frecuente. Grafana, Loki, Tempo y Mimir aparecen en el CNCF Landscape, pero no son proyectos albergados por la CNCF. Son productos open source desarrollados y mantenidos por Grafana Labs. Esto no les resta valor técnico, pero conviene tener clara la distinción.
Grafana se ha convertido en el estándar de facto para visualización y paneles en observabilidad. Su capacidad para integrar múltiples fuentes de datos (Prometheus, Loki, Tempo, Mimir, Elasticsearch y muchos más) lo hace fundamental en arquitecturas modernas. Es difícil encontrar una plataforma de observabilidad open source que no use Grafana como capa de visualización.
Loki ha ganado terreno como solución de logs gracias a su modelo de indexación basado en etiquetas, que reduce costes de almacenamiento y facilita la correlación con métricas y trazas dentro del stack LGTM (Loki, Grafana, Tempo, Mimir). Sin embargo, no es adecuado para casos con requerimientos complejos de búsqueda de texto completo (full-text) o análisis avanzado de logs, donde Elasticsearch sigue siendo más sólido. Un dato reciente a considerar: en Loki 3.4, Promtail ha sido fusionado con Grafana Alloy y entrará en fin de vida en marzo de 2026, lo que obliga a planificar la migración a Alloy como agente de recolección unificado.
Tempo ha madurado como una solución escalable y económica para almacenar grandes volúmenes de trazas sin necesidad de bases de datos externas. Su integración nativa con Grafana y el soporte para múltiples formatos de instrumentación (OpenTelemetry, Jaeger, Zipkin) lo posicionan como opción preferente frente a sistemas más pesados. El proyecto Rhythm, anunciado con Tempo 2.9, replantea su arquitectura interna para mejorar la alta disponibilidad y reducir el coste total de operación, lo que indica un compromiso claro con la evolución a largo plazo.
Mimir ofrece una arquitectura modular y escalable orientada a despliegues cloud native para almacenamiento de métricas a largo plazo, como alternativa a Cortex o Thanos. Su elección dependerá de factores como el volumen de datos, requisitos de retención y la experiencia del equipo con arquitecturas distribuidas.
Proyectos en fase de consolidación con casos de uso específicos
En monitorización de redes y seguridad, Cilium (proyecto CNCF graduado, basado en eBPF) está ganando terreno para observabilidad a nivel de red y seguridad con un enfoque nativo en Kubernetes. Su capacidad para visibilizar tráfico, aplicar políticas y detectar anomalías sin agentes adicionales es un avance significativo. Sin embargo, su adopción implica una curva técnica importante y dependencias en el kernel que pueden limitar su uso en entornos heterogéneos o con requisitos estrictos de estabilidad.
Falco, creado originalmente por Sysdig y donado a la CNCF, es proyecto graduado desde febrero de 2024 y se ha convertido en el estándar open source para detección de amenazas en tiempo de ejecución en entornos cloud native. Con más de 140 millones de descargas y una comunidad activa que ha hecho crecer su ecosistema de plugins en un 40 % desde la graduación, Falco demuestra que la seguridad en tiempo de ejecución es una pieza cada vez más integrada en las arquitecturas de observabilidad. Su base en eBPF le permite capturar llamadas al sistema con un impacto mínimo en el rendimiento.
En el ámbito de almacenamiento de métricas, VictoriaMetrics (que no es proyecto CNCF albergado, sino miembro Silver de la fundación) representa una alternativa cada vez más seria a Prometheus para entornos de alto volumen. Destaca por su eficiencia en almacenamiento, consultas y su capacidad de funcionar como reemplazo directo (drop-in replacement) de Prometheus con escalabilidad horizontal. Spotify, por ejemplo, migró su base de datos de series temporales interna a VictoriaMetrics y Prometheus, logrando consultas diez veces más rápidas y ahorros significativos en costes. Aún así, ni VictoriaMetrics ni Mimir han desplazado completamente a Prometheus en entornos donde la simplicidad y el ecosistema existente son prioritarios.
Proyectos que muestran señales de pérdida de tracción
En un ecosistema tan dinámico, algunos proyectos pierden relevancia por falta de adopción, competencia externa o cambios en la demanda.
Zipkin es el caso más claro. Fue uno de los pioneros en trazabilidad distribuida, pero su uso ha decrecido frente a soluciones más modernas como OpenTelemetry y Tempo. Un dato contundente: OpenTelemetry deprecó oficialmente el exportador Zipkin en diciembre de 2025, y los nuevos SDKs ya no están obligados a implementarlo. El soporte de seguridad para los exportadores existentes se mantendrá solo hasta diciembre de 2026. Aunque Zipkin sigue siendo útil para entornos heredados y para quienes ya lo tienen desplegado, no es recomendable para nuevos proyectos. Conviene también señalar que Zipkin no es proyecto CNCF: actualmente está en el Apache Incubator.
Otros proyectos que no han logrado consolidar una comunidad activa o casos de uso claros tienden a estancarse. Esto no significa que carezcan de valor técnico, pero sí que no ofrecen ventajas competitivas claras frente a alternativas más maduras o comerciales. En estos casos, la recomendación es evaluar cuidadosamente el soporte comunitario, la frecuencia de releases y la hoja de ruta antes de adoptar.
Criterios para decidir qué proyectos investigar o adoptar
La decisión de integrar un proyecto del ecosistema CNCF en una plataforma de observabilidad o SRE debe basarse en criterios técnicos claros y alineados con los objetivos del negocio y la arquitectura existente.
El primer factor es la madurez y estabilidad del proyecto. Preferir proyectos con trayectoria comprobada, comunidades activas y, en el caso de proyectos CNCF, al menos nivel incubating. Los proyectos graduados ofrecen garantías adicionales de gobernanza, seguridad y continuidad.
El segundo es la escalabilidad y el rendimiento. No basta con que un proyecto funcione en un laboratorio: hay que evaluar si puede manejar la carga y volumen esperado en producción sin comprometer la estabilidad. Un ejemplo concreto: Prometheus funciona bien para volúmenes moderados, pero a partir de cierta escala necesitarás Thanos, Mimir o VictoriaMetrics para almacenamiento a largo plazo y consultas federadas.
El tercero es la integración y el ecosistema. Considerar la compatibilidad con herramientas ya desplegadas y la facilidad para correlacionar métricas, logs y trazas. La tendencia actual del mercado favorece claramente los estándares abiertos (OpenTelemetry, PromQL, OTLP) frente a formatos propietarios, precisamente porque facilitan esta integración.
El cuarto son los costes operativos y la complejidad. Analizar el coste total de propiedad, incluyendo operaciones, mantenimiento y formación del equipo. A veces la solución técnicamente más elegante no es la más adecuada si el equipo no tiene capacidad para operarla.
Y por último, los casos de uso específicos. Algunos proyectos brillan en nichos concretos: Cilium en observabilidad de red, Falco en detección de amenazas en runtime, VictoriaMetrics en eficiencia de almacenamiento de métricas. La alineación con las necesidades específicas de tu entorno es fundamental.
En suma, no existe una solución única para todos los escenarios. La combinación de Prometheus para métricas, Grafana para visualización, Loki para logs y Tempo para trazabilidad es una base sólida para la mayoría de arquitecturas cloud native. Instrumentar con OpenTelemetry como estándar de recolección y complementar con proyectos como Cilium o Falco según las necesidades de seguridad y red aporta una cobertura completa. Y si tu entorno ya utiliza una plataforma comercial como Dynatrace, la integración con OpenTelemetry garantiza que puedes combinar lo mejor de ambos mundos: instrumentación abierta y análisis inteligente.
En 2026, la batalla ya no está en cómo recoger datos, sino en cómo darles sentido.
Para seguir aprendiendo
Para profundizar en el ecosistema CNCF y su evolución, estas referencias aportan información técnica de calidad y perspectivas fundamentadas:
«Cloud Native Observability with OpenTelemetry», Alex Boten (Packt, 2022). Análisis detallado sobre la instrumentación unificada y los desafíos prácticos de OpenTelemetry en producción. Disponible en: https://www.packtpub.com/en-us/product/cloud-native-observability-with-opentelemetry-9781801071901
«Distributed Tracing in Practice», Austin Parker et al. (O’Reilly, 2020). Cubre fundamentos y herramientas de trazabilidad distribuida, con enfoque en proyectos del ecosistema CNCF. Disponible en: https://www.oreilly.com/library/view/distributed-tracing-in/9781492056621/
Documentación oficial de Prometheus (Cloud Native Computing Foundation). Recurso esencial para entender el diseño, escalabilidad y casos de uso de la monitorización basada en métricas. Disponible en: https://prometheus.io/docs/
Documentación oficial de Cilium (Cloud Native Computing Foundation). Explica la arquitectura basada en eBPF para seguridad y observabilidad a nivel de red en Kubernetes. Disponible en: https://docs.cilium.io/
Documentación de OpenTelemetry. Referencia completa del proyecto, incluyendo SDKs, Collector, convenciones semánticas y guías de migración. Disponible en: https://opentelemetry.io/docs/
Documentación de Dynatrace sobre OpenTelemetry. Detalla la integración de datos OTLP con la plataforma Dynatrace, opciones de ingesta y casos de uso. Disponible en: https://docs.dynatrace.com/docs/ingest-from/opentelemetry
Repositorio Tempo en GitHub (Grafana Labs). Fuente directa para evaluar el estado actual, hoja de ruta y comunidad de esta solución de trazabilidad escalable. Disponible en: https://github.com/grafana/tempo
CNCF Landscape interactivo. Mapa completo del ecosistema cloud native con información sobre todos los proyectos y productos. Disponible en: https://landscape.cncf.io
