核心监控指标
无论你使用的是什么架构（微服务、单体还是云原生），这四个指标都必须优先监控：
延迟： 服务发出请求到收到响应所需的时间（例如：API 响应时间）
注意： 不要只看平均值，必须监控 P95、P99 分位数（即 95% 或 99% 的请求都在该时间以内），因为平均值会掩盖极端卡顿的问题
流量： 对系统的需求量，用以衡量系统的负载
示例： 每秒 HTTP 请求数 (QPS/RPS)、网络吞吐量、并发连接数
错误： 请求失败的比率
示例： HTTP 5xx 状态码错误率、代码异常抛出率、超时次数。错误率飙高通常意味着系统已经或即将崩溃
饱和度： 系统资源利用率，衡量系统有多“满”
示例： 内存使用率、CPU 使用率、磁盘 I/O 瓶颈。当饱和度达到 80%-90% 时，延迟通常会开始剧烈飙升
分层监控指标体系
基础设施
CPU 利用率 & 负载： CPU 是否长期满载
内存使用率： 是否存在内存泄漏（Memory Leak），关注交换区（Swap）是否被频繁使用
磁盘空间 & I/O： 磁盘是否写满（日志塞满是常见故障原因），IOPS 是否达到读写瓶颈
网络带宽： 带宽是否跑满，是否存在大量丢包
运行环境和中间件
JVM： GC（垃圾回收）暂停时间、GC 频率、堆内存分配
数据库（MySQL/PostgreSQL等）： 慢查询数量、活跃连接数、主从同步延迟（Replication Lag）、锁等待时间
缓存（Redis/Memcached等）： 缓存命中率（Hit Rate）、内存碎片率、连接数
消息队列（Kafka/RabbitMQ等）： 消息堆积量（Lag，这是衡量消费能力的关键指标）、生产/消费速率
业务与用户体验指标
用户侧体验（前端/客户端）： 首屏加载时间、前端错误率、应用崩溃率
业务健康度： 下单量、支付成功率、登录失败率。如果五分钟内下单量跌零，即使 CPU 正常，系统也一定出了大问题
如何让监控真正发挥作用？
建立动态告警： 不要所有的指标都报同一个级别的警。
- P0（灾难）： 核心业务受损（如支付失败率 > 1%），需要立即电话通知 oncall
- P1（警告）： 资源即将耗尽（如磁盘空间剩余 < 15%），工作时间排查即可
可观测性建设： 指标只能告诉你“系统生病了”，你还需要配合 日志 和 链路追踪 来精准定位“病因在哪里”。
开源工具推荐：
指标收集与告警： Prometheus + Grafana
Prometheus（普罗米修斯）： 负责收集数据和触发告警。它像一个定时检查员，每隔几秒钟就去各个服务器和应用上抓取数字（比如：CPU使用率 85%、内存剩余 10%、每秒请求数 500）。如果发现数字异常，它会发出告警通知
Grafana： 负责数据可视化。Prometheus 收集到的都是枯燥的数字，Grafana 则把这些数字变成炫酷、直观的图表（折线图、仪表盘），通常大屏幕上放的监控看板就是用它做的
日志系统： ELK Stack (Elasticsearch, Logstash, Kibana)
ELK Stack： 传统且功能强大的老牌组合
- Elasticsearch： 核心搜索引擎，负责把海量日志存起来并提供超快的搜索功能
- Logstash： 传送带和加工厂，负责收集、清洗和格式化日志
- Kibana： 图形界面，让你能在网页上像用百度一样搜索和分析日志
应用性能监控 (APM)：SkyWalking
SkyWalking 是一款专门为微服务、云原生和基于容器（如 Kubernetes）架构设计的开源应用性能监控（APM）系统，它核心关注的是分布式系统的可观测性。
核心功能特性有
- 服务拓扑图
- 分布式链路追踪
- 指标分析与告警
