Prometheus+Grafana是最稳通用的服务监控方案，Prometheus专为服务指标设计，需应用自暴露/metrics，写PromQL要加流量过滤防误告警，推荐复用Node Exporter模板并用Grafana变量实现多服务/环境联动。
直接用 Prometheus + Grafana 是最稳、最通用的服务指标监控可视化方案，其他组合（如 InfluxDB）适合特定场景但生态适配成本更高。
选对数据源：Prometheus 是服务指标的默认事实标准
Prometheus 天然适配服务类指标（HTTP 请求量、错误率、延迟 P95、gRPC 状态码等），因为它的拉取模型、多维标签（job、instance、endpoint、status_code）和 PromQL 函数（rate()、histogram_quantile()、sum by()）专为这类时序服务指标设计。
- 别用 InfluxDB 直接对接应用埋点——InfluxQL 缺乏原生的 rate 计算和多维下钻能力，写个“过去 5 分钟 4xx 错误占比”要嵌套子查询，易错且难维护
- Node Exporter 只管主机层；服务指标必须由应用自己暴露
/metrics（如 Spring Boot Actuator + Micrometer、Go 的promhttp） - 确认你的服务已启用 Prometheus 格式指标端点，访问
http://your-service:8080/actuator/prometheus或类似路径，能看到形如http_requests_total{method="GET",status="200"} 12345的原始指标
写准 PromQL：避免错误率告警误触发的两个关键
服务监控最常踩的坑是错误率计算不加流量过滤，导致低流量时段一两个失败就触发告警。核心原则：只对有真实业务流量的系列做 rate 计算。
- ✅ 正确写法（带基数过滤）：
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])—— 但仅当整体请求量足够大时才可靠 - ✅ 更健壮写法（双重保护）：
(rate(http_requests_total{status=~"5.."}[5m]) > 0.1) and (rate(http_requests_total[5m]) > 10)—— 要求错误率 >10% 且 总请求速率 >10 QPS，两者同时满足才告警 - ❌ 危险写法：
sum(rate(http_requests_total{status=~"5.."}[5m])) by (job) / sum(rate(http_requests_total[5m])) by (job)—— 如果某个 job 某分钟只发了 1 个请求且失败了，结果就是 100%，但毫无业务意义
导入还是手搭？从 Node Exporter 全景模板起步，再叠加服务专用面板
别从零建 Dashboard。Grafana 官方模板 ID 1860（Node Exporter Full）已验证稳定，覆盖 CPU、内存、磁盘、网络基础项，可直接复用其变量（如 $instance、$job）和服务指标面板共用。
- 导入后，在「Variables」里检查
job变量 query 是否包含你的服务 job 名，例如：label_values(job)→ 若没显示，说明 Prometheus 还没抓到你的服务，回去检查prometheus.yml中的scrape_configs - 新增服务面板时，Metrics browser 输入框里先输
http_requests_total，回车看是否列出带job="my-api"的时间序列；没有就说明采集链断在 exporter 或网络层 - 高频操作：点击面板右上角
⋯ → Edit → Metrics → Add query，不要反复新建面板——一个 Dashboard 放 6–12 个相关面板即可，太多反而干扰判断
变量联动：让一个 Dashboard 同时查多个服务、多个环境
靠手动改 PromQL 里的 job="prod-api" 切换服务？太慢还易错。用 Grafana 变量实现一键切换。
- 新增变量 → Name 填
service→ Query 类型选Label values→ Label 填job→ Metric 填http_requests_total（确保该指标在所有目标服务中都存在） - 在所有 PromQL 中把硬编码替换为
{job=~"$service"}，支持多选（按住 Ctrl）；若只想单选，Variable 设置里勾选Multi-value和Include All option - 进阶：用
Query result类型变量做级联筛选，比如先选env="prod"，再自动列出该环境下所有job—— 查询写成：label_values(http_requests_total{env="$env"}, job)
真正难的不是画图，而是让每个指标背后都有明确的 SLO 意义：这个 P95 延迟超多少算影响用户体验？那个错误率持续多久才值得人半夜爬起来？可视化只是把问题摊开，决策依据得提前和业务方对齐。
