- La suite de productos de Grafana retira o reemplaza con frecuencia componentes clave en ciclos cortos, lo que crea una estructura difícil de operar a largo plazo
- Cada vez que se adopta una nueva solución, la forma de configuración, el DSL, los charts de Helm y los Operators cambian repetidamente, generando un entorno difícil de mantener de forma estable
- Como la compatibilidad de CRD con el ecosistema de Prometheus Operator no es completa,
ServiceMonitor y PodMonitor funcionan, pero funciones clave como AlertmanagerConfig quedan con vacíos de soporte
- Mimir 3.0 añade de forma obligatoria una dependencia de Apache Kafka, aumentando mucho la complejidad del clúster y la carga operativa
- En Grafana Cloud y en toda la suite de Mimir, Loki y Grafana, la ubicación de configuraciones y endpoints puede cambiar fácilmente, por lo que se repite una estructura difícil de construir una vez y usar durante mucho tiempo
Cambios estructurales frecuentes en la suite de Grafana
- Funciones clave como Grafana Agent, Flow Mode y OnCall han sido retiradas o reemplazadas repetidamente en un plazo de 1 a 3 años
- La UI de Grafana basada en Angular migró a React y una parte importante de los dashboards existentes se rompió
- Algunos charts de Helm ya no reciben mantenimiento
Mayor complejidad por la adopción de Alloy
- Grafana Alloy, presentado como all-in-one, reemplazó al Agent anterior, pero tuvo problemas iniciales de estabilidad
- Usa su propio DSL (similar a HCL), rompiendo la continuidad con el flujo previo basado en YAML
- Con la incorporación de Alloy Operator, los componentes se volvieron aún más complejos
Alineación incompleta con el ecosistema de Prometheus Operator
- Soporta
ServiceMonitor y PodMonitor, que son el estándar de monitoreo en K8s, pero
PrometheusRules requiere configuración adicionalAlertmanagerConfig no está soportado- Como Mimir usa su propio Alertmanager, aparecen diferencias de versión e incompatibilidades de detalle
Introducción de la dependencia de Kafka en Mimir 3.0
- Aunque buscaba una escalabilidad mayor que antes,
- al añadir Kafka como requisito obligatorio en la configuración central, la dificultad operativa aumentó considerablemente
- pasar de una sola instalación con Helm a coordinar múltiples componentes hizo que la complejidad creciera exponencialmente
Un ecosistema difícil de usar de forma estable
- El endpoint de ingesta de Grafana Cloud se volvió más difícil de encontrar con la introducción de un nuevo sistema de administración
- El ciclo de actualización y retiro de componentes importantes es rápido, por lo que no encaja con organizaciones que buscan un monitoreo “aburrido y estable”
- Más que un problema de la tecnología en sí, la forma de gestionar el producto y la velocidad de cambio actúan como factores clave que reducen la confiabilidad
5 comentarios
El panel que ofrece InfluxDB por defecto también sirve bastante bien para usarlo de forma sencilla.
Coincido en que Grafana deja bastante que desear, pero ¿habrá alguna otra solución que recomienden y que soporte tantas fuentes de datos como Grafana?
No es que realmente haya alternativas.
Parece que en Grafana también había mucha gente que quería ascender o adornar su currículum.
Opinión de Hacker News
Yo también estoy considerando seriamente abandonar Grafana por completo por las mismas razones que el autor
Cansa tener que rehacer dashboards cada año, reconfigurar alertas y ponerse al día con nuevas funciones
Solo quisiera que me avisara cuando el servicio se cae, y mientras no cambien las fuentes de datos ni las métricas, quisiera mantener la misma definición de dashboard durante 10 años
Antes solo había 4 o 5 enlaces principales en la barra lateral, pero ahora hay demasiados submenús dentro de menús y hasta cuesta encontrar las funciones básicas (dashboards, alertas)
Es demasiado ineficiente tener que aprender de nuevo una UI que veo apenas una vez al mes
Cuando la vida útil de los servicios es de apenas 2 o 3 años y vas apilando varios productos, al final solo sientes que crece una montaña de deuda técnica
Es doloroso vivir en una realidad donde cada trimestre hay que reemplazar algo grande
Mimir es un sistema diseñado para manejar métricas a una escala completamente distinta
En ese nivel, Kafka realmente sí es necesario
Pero la mayoría de los usuarios no necesita ese nivel de escalabilidad
Si no estás ejecutando Mimir en un clúster de Kubernetes dedicado, entonces está sobrediseñado
Lo realista es simplemente usar Prometheus
Funciona sorprendentemente bien incluso en modo de instancia única, y es muy fácil de escalar
Lo he usado en varias organizaciones y proyectos personales, y siempre me ha dejado satisfecho
Pero Amazon Managed Prometheus de AWS está basado en Cortex, y OpenObserve ya opera a escala de petabytes
Lo ideal sería algo que se despliegue como un solo binario, sea compatible con OpenTelemetry y permita migrar después a otro proveedor de OTEL
Si alguien armara una solución nueva basada en OTEL, tengo curiosidad por cuál sería la alternativa más prometedora a Prometheus/Grafana
Para manejar logs y traces hacían falta más componentes complejos
Entonces encontramos GreptimeDB, que permite manejo unificado de métricas, logs y traces
Recolectamos con OpenTelemetry y visualizamos con Grafana
Poder crear dashboards con SQL encaja muy bien con las capacidades del equipo
Como ingeniero de plataforma, la estructura simple me deja bastante satisfecho
Fue creado para resolver la complejidad de Grafana y Elastic, y puede manejar logs, métricas, traces, dashboards y alertas en un solo contenedor
(El autor es maintainer principal de OpenObserve)
Es open source, se desarrolla activamente y la comunicación del equipo es buena
Muchos usuarios se están cambiando para evitar la complejidad de Grafana, donde hay que lidiar directamente con varios backends
(El autor es maintainer de SigNoz)
No entiendo por qué los desarrolladores cambian la configuración cada semana para perseguir la última tecnología
Yo uso la combinación Grafana + Prometheus desde 2017 y todavía funciona bien
Solo actualizo a versiones LTS una vez cada 1 o 2 años
Los dashboards siguen siendo perfectos y no hay ningún problema
Para la mayoría de la gente, esta combinación aburrida pero estable es la mejor opción
Quisiera preguntar si acaso siguen usando una versión vieja tal cual
¿Habrá algún constructor de dashboards open source que pueda reemplazar a Grafana? En la empresa también lo usamos ampliamente
O también se pueden usar las plantillas de consola de Prometheus o los dashboards integrados de VictoriaMetrics, aunque las funciones son mucho más limitadas
Los dashboards de Grafana en sí son bastante cómodos cuando se usan con la combinación VictoriaMetrics + ClickHouse
Apenas recuerdo nombres como RRD y Nagios
El cambio constante de Grafana más bien terminó por volverme inmune
En cada major release se rompen dashboards o cambia la UI, pero uno ya lo toma como algo normal
El verdadero problema es el lock-in de PromQL en Prometheus
Si cambias el nombre de una métrica, hay que modificar todas las reglas, alertas y dashboards
PromQL casi nunca arroja errores aparte de fallas de sintaxis, así que hay que validarlo con herramientas como pint
En despliegues de servidor único, suelo usar Prometheus Pushgateway + Grafana como plantilla de docker-compose
Es simple y funciona bien, pero cuando el volumen de métricas crece, la complejidad explota
Si Prometheus hubiera mantenido un formato de transporte más eficiente, este problema sería menor
Si hubiera existido un formato binario de métricas compacto en vez del formato de texto, habría podido manejar sin problemas millones de labels
SigNoz es una buena opción y se desarrolla activamente
Antes gastaba mucho en plataformas cloud de observabilidad, pero ahora levanto SigNoz self-hosted en una caja de Hetzner y resuelvo todo con $10 al mes
Tanto Prometheus como Grafana apuntaban a ser soluciones full-stack, y luego apareció OTEL y complicó el panorama
OTEL es un protocolo para métricas, traces y logs, pero no existe una sola base de datos que soporte todo eso
La mayoría termina combinando Prometheus (métricas) + OpenSearch (logs)
Al final, OTEL termina exigiendo reemplazar y reconfigurar recolectores