作者因Grafana产品体验不佳而不再推荐使用。他最初在小公司工作时选择了Grafana配合Loki/Prometheus搭建监控系统，当时这套方案轻量易用。但后来Grafana在功能扩展过程中逐渐变得臃肿复杂，且存在信任问题，导致作者改变了对该产品的评价。

标题：Grafana的信任危机

发布日期：2025/11/14
阅读时长：约6分钟

我不再推荐使用Grafana

免责声明：本文仅基于我个人使用Grafana产品的经历，部分内容涉及客观事实，但您的体验可能完全不同，欢迎分享您的观点。

初识Grafana的美好时光

我职业生涯始于大学附近的一家小型软件公司，那里需要为多个客户开发、运营网站和网络服务。作为实习生，我承担了寻找监控解决方案的任务。当时Zabbix已无法满足容器化（Docker）的声明式需求，经过对比Elastic（过于笨重复杂）后，我选择了Loki/Prometheus+Grafana组合。

通过简单的docker-compose.yaml配置，我们快速搭建了监控栈：Grafana通过SSH隧道暴露，Loki和Prometheus共享本地卷挂载，负载极低。这一时期我还发现Grafana Labs提供优质的免费云服务，甚至将其用于个人项目，体验良好。

技术演进与Grafana的频繁变革

随着工作变动和技术升级（转向Kubernetes），我们面临长期存储（13个月）和跨节点存储的挑战。基于对Grafana产品的信任，我选择了其开源项目Mimir（基于Cortex架构），并采用Grafana Agent统一处理日志和指标传输。

然而Grafana开始加速转型： - 推出自主监控平台对标DataDog - 开发独立告警系统Grafana OnCall - 大力投入Helm模板（默认生成6千行配置） - 推出Grafana Operator管理部署 - 两年内相继淘汰Grafana Agent/Flow模式 - 仪表盘框架从Angular迁移到React导致兼容性问题

现状：Alloy的妥协与Mimir 3.0的激进

最新推出的"万能解决方案"Grafana Alloy虽支持日志/指标/追踪（包括OTEL），但存在明显缺陷： - 采用自研类HCL配置语言（非YAML） - 对Prometheus生态CRD支持不完整（如缺失AlertmanagerConfig） - 需额外配置才能兼容PrometheusRules

更令人担忧的是Mimir 3.0强制依赖Apache Kafka，且Grafana Cloud的接入点被刻意隐藏以推广其新配置管理服务。这种频繁变更已形成模式：每12-18个月就需要重构监控架构。

反思与启示

虽然Loki/Mimir/Grafana本身技术优秀，但管理方式令人质疑： 1. 稳定性缺失：监控系统本应"枯燥稳定"，但Grafana持续颠覆性更新 2. 复杂度失控：企业用户难以跟上其职业驱动型开发节奏 3. 生态割裂：逐渐偏离Prometheus等成熟标准

或许采用ELK栈或OpenShift+kube-prometheus+Thanos组合会是更持久的选择。当前我只期待OTEL标准尽快成熟，让监控回归其本质——作为基础设施而非产品存在。毕竟对大多数企业而言，监控只是保障业务运行的手段，而非需要持续投入的技术秀场。

（全文在保留核心叙事的基础上，删减了部分技术细节和个人经历描述，聚焦产品策略与用户体验的矛盾）

以下是评论内容的总结：

1. Grafana的使用体验与优势

   • 用户认为Grafana在开源世界中是构建仪表盘的最佳选择，支持多种数据源。
     • "Not sure what's an alternative for Grafana in the open source world..." (评论3)
     • "Grafana is used very extensively in my company..." (评论3)
   • 部分用户对其易用性和功能表示满意，尤其是在单节点部署时。
     • "It works well and is trivial to setup..." (评论12)

2. 对技术债务和复杂性的担忧

   • 用户批评监控工具过于复杂，依赖项过多，违背了其可靠性初衷。
     • "Monitoring should be the most boring tool in the stack..." (评论8)
     • "Building an elaborate pile of technical debt..." (评论5)
   • 行业普遍存在“简历驱动开发”问题，导致工具频繁更换。
     • "This isn't a Grafana problem, this is an industry wide problem..." (评论10)

3. 对Prometheus的批评与替代方案

   • Prometheus的Pushgateway实现被认为存在问题，部分用户选择自建解决方案。
     • "Prometheus pushgateway is such a bad implementation..." (评论7)
   • 用户讨论替代方案如SigNoz、Vector和Clickhouse。
     • "Signoz is good, and active development..." (评论13)
     • "We use Vector and Clickhouse for logging..." (评论16)

4. 对Grafana未来发展的质疑

   • 用户担心Grafana的商业化可能损害其开源本质。
     • "This sounds less like a technical evolution and more like the classic VC-funded push..." (评论8)
   • 部分用户认为其复杂性增加，可能不适合小规模部署。
     • "Mimir is just architected for a totally different order of magnitude..." (评论15)

5. 对轻量级替代方案的需求

   • 用户寻求轻量级的日志和监控工具替代方案。
     • "what are tested and fairly lightweight alternatives for Loki?" (评论11)
     • "elastic stack is so heavy it's out of question for smaller clusters..." (评论11)