grafana 依赖 prometheus 等数据源展示指标，完整监控链路需三步：应用暴露符合规范的 prometheus 指标（通过客户端库或 exporter）；prometheus 正确抓取（配置 job 并热重载）；grafana 用 promql 可视化+告警（含变量、模板与 alertmanager 集成）。
Grafana 本身不采集数据，它靠连接 Prometheus 这类数据源来展示指标。要监控应用性能，关键不是“Grafana 怎么连 Prometheus”，而是整个链路怎么搭得准、查得清、看得懂——重点在指标暴露、配置对齐和可视化表达。
让应用把性能指标“说”出来
应用必须主动暴露符合 Prometheus 格式的指标（通常是 HTTP 接口，路径如 /metrics）。方式有几种：
-
集成客户端库：Java 用 Micrometer + Prometheus Registry，Go 用
promhttp，Python 用prometheus-client。埋点后启动应用，访问http://your-app:8080/metrics应能看到类似http_requests_total{method="GET",status="200"} 1245的原始指标。 -
使用 Exporter：如果应用本身不支持暴露指标（比如老系统或第三方服务），可部署对应 Exporter。例如：
redis_exporter抓取 Redis 的INFO输出，mysqld_exporter连接 MySQL 执行 SQL 获取 QPS、慢查询数等。 -
避免常见坑：确保应用防火墙放行 metrics 端口；指标命名遵循规范（小写字母+下划线，如
app_response_time_seconds）；标签不宜过多，否则 cardinality（基数）爆炸影响性能。
让 Prometheus 正确“听”到这些指标
修改 prometheus.yml，添加 job 抓取你的应用：
- 静态配置示例：
scrape_configs:- job_name: "my-app"static_configs:- targets: ["app-service:8080"] - 如果是 Kubernetes 环境，优先用 ServiceMonitor 或 PodMonitor（通过 Prometheus Operator 自动发现）。
- 配置后执行热重载：
curl -X POST http://localhost:9090/-/reload，然后去http://localhost:9090/targets页面确认状态为 UP。
在 Grafana 里把性能问题“画”出来
连好数据源后，核心是写好 PromQL 查询，并组织成有意义的面板：
-
响应时间：用
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))查 P95 延迟，搭配sum(rate(http_requests_total[5m])) by (path)看各接口流量。 -
错误率：
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])计算 5xx 错误占比。 -
资源瓶颈：若应用是 Java，加 JVM 指标如
jvm_memory_used_bytes{area="heap"}和jvm_gc_collection_seconds_total，观察内存增长与 GC 频次是否异常。 -
用变量和模板提升效率：在仪表盘加
instance或service变量，下拉切换不同实例；用legend={{instance}}自动标注图例。
让告警真正“管用”
光看图不够，得让问题主动找你：
- 在 Prometheus 中定义告警规则（
alert.rules），例如：expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[10m])) > 2for: 5mlabels: severity: warning - Alertmanager 负责去重、分组、静默，并把告警推送到飞书、钉钉或邮件——别只配个邮箱，生产环境建议至少接入一个即时通讯工具。
- 告警消息里带上关键上下文，比如
{{ $labels.instance }} 上 {{ $labels.path }} 接口 P99 延迟超 2s，当前值 {{ $value | printf "%.2f" }}s。
