Grafana 可观测性实战：Dashboard、PromQL、告警与代码化配置

DevOps运维

Grafana 为什么是可观测性的中枢

Metrics、Logs、Traces 三足鼎立（可观测性三大支柱），但真正把它们串起来的往往是 Grafana。它的价值不在「画图」，而在把分散的信号聚合成一个能回答「现在系统怎么了」的界面。

支柱 数据源 回答的问题
Metrics Prometheus 系统整体上健康吗？
Logs Loki 出错时具体发生了什么？
Traces Tempo 一次请求慢在哪个服务？

构建高效的 Dashboard

好 Dashboard 的原则：一张图只讲一件事，自上而下由粗到细。典型布局：

  1. 顶部：全局 SLO（错误率、P99 延迟、QPS）。
  2. 中部：按服务/实例拆分的细分面板。
  3. 底部：原始日志与单条 trace 链接。
{
  "panels": [
    {
      "title": "P99 延迟",
      "type": "timeseries",
      "targets": [
        { "expr": "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))" }
      ]
    }
  ]
}

Dashboard JSON 通常很大，编辑前先用 JSON 格式化 工具展开，避免改错嵌套层级。

写好 PromQL：可观测性的语言

率（rate）优于原始计数

# 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)

分位数用 histogram_quantile

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

标签对比

# 各实例 QPS
sum(rate(http_requests_total[5m])) by (instance)

变量与模板化：一个 Dashboard 看全部

用模板变量让同一张图按 service、env 动态切换，避免复制粘贴几十张面板。

{
  "templating": {
    "list": [
      {
        "name": "service",
        "type": "query",
        "datasource": "Prometheus",
        "query": "label_values(http_requests_total, service)"
      }
    ]
  }
}

面板里引用：sum(rate(http_requests_total{service="$service"}[5m]))。

多数据源：Metrics + Logs + Traces

Grafana 的强项是关联。例如从 Metrics 面板点开「Explore」，用同一 trace_id 跳到 Tempo，再用 service + 时间窗跳到 Loki 日志。

# 在 Loki 中按标签过滤
{service="checkout", level="error"} |= "timeout"

告警：从「看见」到「被通知」

告警规则建议基于「症状」而非「原因」：

groups:
  - name: api-alerts
    rules:
      - alert: HighErrorRate
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
              / sum(rate(http_requests_total[5m])) by (service) > 0.05
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "服务 {{ $labels.service }} 错误率超过 5%"

for: 10m 能过滤瞬时抖动，避免告警风暴。

排查告警触发的接口返回码时，可用 HTTP 状态码 工具快速对照 5xx 含义。

注解与代码化配置

注解（Annotation）

把部署、回滚等事件标到时间轴上，出问题一眼看出「是不是刚发版引起的」。

Provisioning：Dashboard 即代码

不要手动点出来的 Dashboard——用文件声明，随 Git 管理：

apiVersion: 1
providers:
  - name: default
    folder: ""
    type: file
    options:
      path: /etc/grafana/provisioning/dashboards

这样 Dashboard 可评审、可回滚、可复制，符合 GitOps 实践。

常见问题 FAQ

Q1：P99 算出来是 NaN 怎么办？

多半是 histogram bucket 没上报，或 rate 时间窗内无数据。先确认指标存在再用 histogram_quantile。

Q2：变量下拉为空？

检查变量 query 的数据源是否正确，以及 label_values 的 metric 名是否真实存在。

Q3：告警老是误报？

加 for 持续时间、提高阈值、或用 absent() 处理指标消失的情况。

Q4：Grafana 和 Prometheus 告警啥关系？

Prometheus 负责「算 + 触发」，Grafana 负责「展示 + 路由通知」。也可直接用 Grafana 托管告警。

Q5：定时任务指标怎么看？

配合 Cron 说明 工具核对调度周期，再对照指标时间窗判断是否按时跑。

工具推荐

在 Grafana / 可观测性建设中，以下 工具库 能帮上忙：

Grafana 不是「画图工具」，而是把 Metrics/Logs/Traces 编织成「系统当下状态」的叙事层。把 Dashboard 代码化、告警基于症状、变量驱动复用，可观测性才真正落地为生产力。

本站提供浏览器本地工具，免注册即可试用 →

#Grafana#可观测性#PromQL#监控#告警#Dashboard#Loki