Есть продукты, которые становятся символами целой эпохи. В сфере мониторинга и наблюдаемости таким символом долгое время была Grafana — та самая оранжевая иконка, с которой начинались дашборды у половины DevOps-команд мира.
Но в 2025 году всё чаще звучит мысль: «что-то пошло не так». И статья Хенрика Гердеса стала квинтэссенцией боли инженеров, которые устали не столько от сложности мониторинга, сколько от бесконечно меняющегося стека Grafana Labs.
И вот о чём действительно важно поговорить.
🔥 Grafana перестала быть «надёжным выбором» — она стала быстро меняющимся экспериментом
Хенрик пишет о том, что продукты Grafana вводятся, устаревают и заменяются так быстро, что невозможно построить долгоживущий мониторинг, не переписывая его каждый год.
Это уже не просто раздражение — это объективная инженерная проблема.
Что вызывает наибольший «девопсовый шок»
- 🧨 Объявили Grafana Agent — через пару лет объявили устаревшим (deprecated).
У многих компаний только-только он сходил в прод… - 🔁 Agent Flow Mode — тоже deprecated через 2–3 года.
- 📦 OnCall закрыли, хотя команды уже внедрили его в свои инцидент-процессы.
- 🔄 Angular-дашборды удалили, ввели React — ломая существующие панели.
- 🏗️ Теперь Mimir 3.0 требует Kafka, без которой он просто не запускается.
То есть «легковесный Cortex-подобный storage» внезапно превратился в распределённое монстр-хранилище.
Такая стратегия приемлема для стартапа, но не для инфраструктурного продукта, на котором держатся тысячи кластеров.
🛠 Почему изменения кажутся не эволюцией, а хаосом
Главная проблема не в технологиях — они отличные. Loki, Mimir, Grafana UI сами по себе сильные инструменты.
Проблема — в менеджменте продуктов и темпах изменений, которые не соответствуют реальности продакшен-инфраструктур.
Компании хотят мониторинг, который:
- устанавливается один раз,
- стабильно работает годами,
- не требует каждые шесть месяцев менять конфиги, CRD, операторов и пайплайны.
Grafana Labs же, по ощущениям, живёт в режиме:
- 🧱 каждый квартал — новый инструмент,
- 🧪 каждый год — редизайн архитектуры,
- 🧩 каждая вторичная функция — своя DSL-конфигурация (в Alloy).
Это технически интересно, но производственно дорого.
📡 Alloy: отличный концепт, но не тот момент
Alloy — сильная идея: единый мультипротокольный агент, который покрывает всё:
- метрики
- логи
- трейсы
- OTEL
Но:
- свой DSL (похож на HCL) — ❌ усложняет обучение;
- несовместимость с PrometheusRule / AlertmanagerConfig — ❌ ломает существующие кластеры;
- разные версии Alertmanager у Mimir и Kube-stack — ❌ требуют ручных костылей.
То есть «единый агент для всего» превращается в «единый источник миграционных страданий».
⚙️ Kafka в Mimir: шаг вперёд, но впереди пропасть
С технической точки зрения требование Kafka для приема данных (ingestion) — оправдано: это увеличивает горизонтальное масштабирование и стабилизирует ingestion-pipeline под высокой нагрузкой.
Но ключевой вопрос — кому это нужно?
Большинство компаний используют Mimir/Loki не как гипермасштабируемое решение (hyperscale-решение), а как замену Thanos + Prometheus с удобной API.
Для «нормальных» продов Kafka — это:
- 🏗️ отдельный оператор
- 🎛️ отдельный уровень управления
- 🧰 отдельная зона отказа
- 📉 и лишняя сложность просто чтобы получить метрики.
Когда прометей был в виде одного исполняемого файла (single-binary) и жил на Node, всё было, как любит Хенрик: «скучно» и надёжно.
🧘 Почему инженеры снова уходят в «старые, но надёжные» решения
Хенрик не один — огромное количество DevOps-команд в 2025 году возвращаются к:
- kube-prometheus-stack
- Thanos
- Vector / Fluent Bit
- Alertmanager (нормальный, поддерживаемый)
- Tempo / Jaeger
Потому что это пусть и не так модно, но стабильно.
А стабильность — лучший друг мониторинга.
То, что пишет Хенрик — важный симптом: наблюдаемость перестала быть про «фичи» и стала про «надёжность и предсказуемость».
💬 Моё личное мнение: Grafana Labs попала в ловушку собственной амбициозности
Я вижу в этом типичный эффект продуктовых компаний, которые стремительно растут:
- нужно показывать рынку новые продукты;
- нужно расширять зону влияния;
- нужно захватывать сегменты конкурентов (Datadog, Elastic, New Relic);
- нужно повышать ARPU, а значит — толкать cloud-продукты.
Но главное теряется:
роль Grafana как инструмента для инженеров, который просто работает.
Monitoring — это не стартап-песочница.
Это то, что должно быть «🧱 скучным как бетон, надёжным как кирпич».
И пока Grafana Labs каждые полгода перетряхивает свой стек — доверие к ним будет падать.
🧭 Что будет дальше?
Я согласен с Хенриком: лучший путь — ждать, пока OTEL стабилизируется и станет «базовым стандартом», а не движущейся целью.
Тогда можно будет строить пайплайны, где backend выбирается свободно — от Thanos до ClickHouse или VictoriaMetrics.
А пока — многие команды предпочитают путь:
- 🧱 kube-prometheus-stack + Thanos
- 🎯 минимум кастомных CRD
- 💤 максимум предсказуемости
И честно — я понимаю почему.
Источники
🔗 Оригинальная статья:
https://henrikgerdes.me/blog/2025-11-grafana-mess/