Grafana 是什么：多数据源统一查询与可视化
Grafana 是什么：多数据源统一查询与可视化
Grafana 是一个把「多个数据源」聚到同一块画布上做查询、可视化与告警的前端平台。它自己不存指标，也不负责采集：指标由 exporter 暴露、Prometheus 抓取，日志由 Loki 或 Elasticsearch 存，链路数据由 Tempo 或 Jaeger 存；Grafana 负责向这些系统发查询、把结果画成面板、在阈值越界时把通知发出去。它的价值不在于某个单一功能，而在于用一个界面、一套变量、一套告警，把散落在不同系统里的可观测数据串成同一个上下文。
它解决的问题很具体：一次线上故障，你可能要同时看 QPS 曲线、错误率、P95 延迟、机器 CPU、容器重启次数、以及出错那几分钟的日志。如果这些数据分属五个不同的界面，排障时就要来回切换、手动对齐时间范围。Grafana 把这些面板放在同一张大盘上，共用一个时间轴与一组变量，切换环境或服务时所有面板一起联动。
| 方案 | 定位 | 优势 | 局限 |
|---|---|---|---|
| Grafana | 多数据源可视化 + 统一告警 | 数据源生态最广、变量与模板能力强、告警与通知渠道完整 | 自身不存储数据，依赖后端数据源；复杂关联分析能力弱于专业 BI |
| Kibana | Elasticsearch 专属可视化 | 日志场景开箱即用、Discover 全文检索体验好 | 基本绑定 Elastic 生态，跨数据源能力有限 |
| Prometheus 自带 UI | 临时查询与调试 | 零部署成本、表达式调试直观 | 没有仪表盘管理与告警通知体系，无法团队协作 |
| Datadog | 商业 SaaS 一体化可观测 | 开箱即用、APM 与日志打通、无运维负担 | 按主机与数据量计费，成本高，数据在第三方 |
| Zabbix | 传统主机与网络监控 | Agent 体系成熟、阈值告警稳定、老牌企业级 | 界面偏传统，时序数据模型与现代云原生场景有落差 |
取舍建议：已经在用 Prometheus 的团队基本没有理由不配 Grafana，因为指标一旦有了标签体系，Grafana 的变量与面板就是最省力的消费方式；日志为主、指标为辅的场景，Kibana 更顺手；预算充足且不想运维，Datadog 省心；纯主机与网络监控，Zabbix 依然够用。
核心术语表
| 术语 | 含义 |
|---|---|
| Data Source（数据源） | 一个可查询的后端，如 Prometheus、Loki、Elasticsearch、MySQL、ClickHouse |
| Dashboard（大盘） | 一组面板的集合，对应一个 JSON 定义，可导入导出 |
| Panel（面板） | 大盘上的单个可视化单元，由查询、类型、阈值、单位组成 |
| Query（查询） | 发给数据源的语句，PromQL、LogQL、SQL 各自不同 |
| Variable（变量） | 可复用的占位符，如 $env、$service，切换后全盘联动 |
| Transformation（转换） | 在面板内对查询结果做二次加工，不改变数据源 |
| Annotation（标注） | 在时间轴上打点，用于对齐发布、变更、故障时间 |
| Alert Rule（告警规则） | 定时执行查询并判断条件，触发后按策略通知 |
| Contact Point（通知点） | 告警的发送目标，如邮件、企业微信、钉钉、Webhook、PagerDuty |
| Notification Policy（通知策略） | 决定哪类告警走哪个通知点，含分组与静默规则 |
| Mute Timing / Silence | 前者是周期性静默窗口（如每周发布窗口），后者是临时静默某组告警 |
| Folder（文件夹） | 大盘与告警的权限与分组单位 |
| Provisioning（配置即代码） | 用 YAML 文件声明数据源与大盘，随版本发布而非手工点击 |
| Explore | 临时查询页面，用于调表达式，不影响大盘 |
