服务监控方案？

本文目录导读：

1. 监控的核心目标与层次
2. 核心监控维度与关键指标
3. 主流技术选型（开源 vs 商业）
4. 推荐的现代监控栈
5. 实施监控方案的步骤
6. 常见陷阱与最佳实践
7. 总结方案框架

这是一个比较宽泛但非常核心的问题,服务监控方案是保障系统稳定性、可用性和性能的基础设施，一个好的监控方案不仅仅是“装个软件看图表”，而是一套从数据采集到告警通知再到故障定位的完整闭环体系。

下面为你梳理一份通用的、企业级的服务监控方案，涵盖了核心思路、技术选型、关键指标和实施步骤。

监控的核心目标与层次

监控不是为了看数据,而是为了快速发现问题、定位问题和解决问题，通常分为四个层次（从上到下）：

1. 用户体验监控：用户端真实感受如何？（页面加载慢？下单失败？）
2. 应用性能监控：业务程序运行正常吗？（API响应时间？数据库查询慢？错误率？）
3. 系统资源监控：服务器资源够用吗？（CPU、内存、磁盘、网络？）
4. 基础设施监控：底层硬件/云服务正常吗？（交换机、路由器、云厂商服务？）

核心监控维度与关键指标

你需要从不同角度去定义“什么是正常的”，以下是每个维度的关键指标：

基础设施层

• 主机：CPU使用率、内存使用率、磁盘空间（使用率、IOPS、吞吐量）、网络带宽（流入/流出）、系统负载（Load Average）。
• 网络：连通性（Ping）、延迟、丢包率、TCP连接数。

中间件/数据库层

• 数据库：连接数、慢查询数量、QPS/TPS、复制延迟、缓存命中率。
• 消息队列：积压数量、生产/消费速率、连接数。
• 缓存：命中率、内存使用率、key数量、过期策略。

应用/业务层

• 请求量：QPS（每秒查询数）、RPS（每秒请求数）。
• 成功率：HTTP 2xx/4xx/5xx比例，或业务逻辑失败率。
• 响应时间：P50、P95、P99延迟（99%的请求在200ms内完成）。
• 异常：应用日志中的Error/Exception计数、代码调用栈。
• 业务指标：订单创建量、用户注册量、支付成功率、漏斗转化率。

主流技术选型（开源 vs 商业）

数据采集

• Metrics（指标）：
  • Prometheus：云原生时代的事实标准，Pull模式，生态强大（CNCF项目），强烈推荐。
  • Telegraf：插件丰富，适合采集系统、数据库等指标。
  • StatsD：旧时代标准，简单，但功能有限。
• Logs（日志）：
  • Filebeat / Fluentd：轻量级日志采集器，将日志发送到中心化存储。
• Traces（链路追踪）：
  • OpenTelemetry：新一代标准，统一了Metrics、Logs、Traces的采集，支持多语言SDK。
  • Jaeger / Zipkin：老牌分布式追踪系统，常与OpenTelemetry配合使用。

数据存储 & 可视化

• 指标：Prometheus (Server + TSDB) + Grafana（可视化）。
• 日志：Elasticsearch（存储+搜索） + Kibana（可视化+分析） — ELK/EFK栈。
• 链路：Jaeger (UI) 或 Grafana Tempo。
• 全栈整合：Grafana可以同时查询Prometheus、Elasticsearch、Tempo等数据源，是目前最主流的前端。Grafana Loki 还可作为日志存储，与Grafana完美集成。

告警与通知

• Alertmanager：与Prometheus配合，负责告警的分组、抑制、静默和路由。
• OpsGenie / PagerDuty：商业告警管理平台，支持排班、升级、多通道通知。
• 各IM的Webhook：直接推送到钉钉、飞书、Slack、企业微信等。

推荐的现代监控栈

这是目前最主流、社区最活跃的组合，适合大多数互联网公司和云原生环境：

Prometheus + Grafana + AlertManager + Loki (日志) + Tempo (链路) (又称 PGALT 或 OpenTelemetry + Grafana Stack)

• 采集：使用OpenTelemetry SDK埋点，或使用Prometheus Exporter / Node Exporter。
• 架构：
  • 应用暴露 /metrics 端点，Prometheus定期拉取。
  • 日志通过Promtail发送到Loki。
  • 链路通过OpenTelemetry Collector转发到Tempo。
  • 告警规则在Prometheus中配置,由Alertmanager处理。
  • 所有数据最终在Grafana一个平台上进行关联查询和可视化。

实施监控方案的步骤

1. 需求调研与目标定义（1-2周）

   • 梳理核心业务,确定最重要的“黄金指标”（延迟、流量、错误、饱和度）。
   • 确定告警责任人（谁是SRE？谁是开发？）。

2. 基础监控覆盖（1-2周）

   • 在所有服务器和K8s节点上部署Node Exporter。
   • 对所有核心中间件（MySQL、Redis、MongoDB、Kafka等）部署对应的Exporter。
   • 接入Prometheus,配置基本采集。
   • 搭建Grafana,创建基础的“仪表盘”（如：主机总览、数据库总览）。

3. 应用监控接入（持续，按服务优先级）

   • 最简方式：在应用代码中集成Prometheus客户端库，暴露HTTP请求数、延迟、错误率等指标。
   • 进阶方式：使用OpenTelemetry SDK，增加链路追踪，记录每个请求的调用链。
   • 搭建日志采集管道（Filebeat -> Elasticsearch 或 Promtail -> Loki）。

4. 配置告警与通知（1-2周）

   • 定义告警规则：
     • 紧急（P0/P1）：服务不可用、重要接口P99延迟 > 5秒、错误率 > 10%、磁盘满。必须立即响应。
     • 警告（P2/P3）：CPU > 80%（持续10分钟）、慢查询增多。工作时间处理。
   • 配置通知渠道：短信、电话、IM机器人。
   • 避免告警风暴：使用Alertmanager的分组、抑制功能，如果数据库挂了，所有依赖它的服务告警可以暂时静默，仅通知数据库问题。

5. 建立SLO/SLI与可观测性文化

   • SLI（服务等级指标）：你实际测量的东西（如：P99延迟、成功率）。
   • SLO（服务等级目标）：你承诺的目标（如：99.9%的请求延迟 < 200ms）。
   • 错误预算：基于SLO计算可以容忍多少故障。
   • 将SLO完成情况做成仪表盘,驱动日常的On-Call和事后复盘。

常见陷阱与最佳实践

• 不要为了监控而监控：指标太多会导致告警疲劳，只监控对业务和稳定性有直接影响的关键指标。
• 告警要有Actionable信息：告警信息中直接告诉On-Call人员“XXX服务CPU高，请检查代码逻辑优化”或“请扩容”。
• 重视Dashboard的“易读性”：Grafana面板不要堆砌，按逻辑分组（业务层、中间件层、系统层），使用红线标记阈值。
• 关注黄金信号：Google的“四大黄金信号”（Latency, Traffic, Errors, Saturation）是普适起点。
• 数据保留策略：原始指标（如1秒粒度）通常保留几天到两周；聚合指标（如5分钟、1小时粒度）保留数月或更久，使用Prometheus的retention和remote write到长期存储（如Cortex、Thanos、Mimir）。

总结方案框架

[用户/客户端]
    |
    v
[负载均衡 / API Gateway]  ----> (Nginx Ingress Controller + OpenTelemetry)
    |
    v
[业务服务 A] ----> (Prometheus SDK / OTEL SDK + 日志)
    |
    v
[数据库 / 缓存] ----> (MongoDB / Redis Exporter)
    |
    v
[采集层]  <---  Prometheus Server (Pull) | Promtail (Push Logs) | OTEL Collector (Push Traces)
    |
    v
[存储层]  <---  Prometheus TSDB | Elasticsearch | Loki | Tempo
    |
    v
[可视化 & 告警]  <---  Grafana (Dashboard) + Alertmanager (Alert Rules -> 通知)
    |
    v
[通知]  <---  钉钉/飞书/Slack/PagerDuty/电话

一句话总结： 先覆盖主机和中间件（基础），再深耕业务代码（应用），最后建立基于SLO的告警文化（持续改进）。 推荐使用 Prometheus + Grafana + Alertmanager 作为核心组合，逐步引入链路追踪和日志分析，形成完整的可观测性体系。

标签： 服务监控