一、监控体系总览：为什么需要微服务监控？监控的三大支柱及核心目标
大家好，我是你们的老朋友。今天咱们聊聊微服务监控。
说实话，我刚入行那会儿，监控这事儿还没这么复杂。一个单机应用，看看CPU、内存，顶多再盯盯日志，基本就稳了。但到了微服务时代，情况完全变了。你想想看，一个请求从用户端进来，可能要经过网关、认证、订单、库存、支付……七八个服务，任何一个环节出问题，用户感知到的就是「系统挂了」。
所以，微服务监控不是「要不要做」的问题，而是「怎么做才能不背锅」的问题。
1.1 为什么需要微服务监控？
我见过太多团队，服务拆得飞起，但监控还停留在「看服务器负载」的阶段。结果呢？线上出了故障，排查起来像大海捞针。
微服务监控的核心价值，说白了就三点：
- 快速定位故障：服务多了，故障点也多了。没有监控，你连问题出在哪个服务都不知道。
- 保障SLA：用户可不管你是哪个服务挂了，他只关心「能不能用」。监控能帮你守住承诺的可用性指标。
- 辅助容量规划：流量涨了，是加机器还是优化代码？数据说话，别拍脑袋。
核心观点：微服务监控不是成本，而是保险。你永远不知道下一个故障什么时候来，但监控能让你在故障来临时，比别人快一步。
1.2 监控的三大支柱：指标、日志、链路追踪
聊到具体怎么做，就绕不开监控的三大支柱。我个人习惯把它们比作「体检报告」、「病历本」和「导航地图」。
1.2.1 指标（Metrics）—— 体检报告
指标是量化的、可聚合的数据。比如QPS、延迟、错误率、CPU使用率。它告诉你「系统现在状态怎么样」。
我在项目中遇到过，有一次线上告警说「订单服务响应时间飙升」。我一看指标面板，发现是数据库连接池被打满了。如果没有指标，我可能还在傻傻地看日志。
常用的指标工具：Prometheus + Grafana，几乎是标配。
# 一个典型的Prometheus指标采集配置
scrape_configs:
- job_name: 'order-service'
metrics_path: '/actuator/prometheus'
static_configs:
- targets: ['localhost:8080']小技巧：指标采集频率别太高。我一般设15秒一次，太频繁反而会消耗服务性能。
1.2.2 日志（Logs）—— 病历本
日志是离散的、带时间戳的事件记录。它告诉你「具体发生了什么」。
嗯，这里要注意：微服务架构下，日志必须带上请求ID或TraceID。否则你根本没法把一次请求的日志串起来。
我曾经排查过一个诡异的问题：用户支付成功，但订单状态没更新。最后靠日志发现，是支付回调的请求被负载均衡转发到了另一个实例，而那个实例的缓存是旧的。如果没有TraceID，这种问题查一天都不一定找得到。
日志管理工具：ELK（Elasticsearch + Logstash + Kibana）或 Loki + Grafana。
1.2.3 链路追踪（Traces）—— 导航地图
链路追踪记录一次请求在多个服务间的完整调用路径。它告诉你「请求到底走了哪些路，每段花了多久」。
为什么需要它？因为微服务调用链可能很长。一个请求经过5个服务，每个服务耗时100ms，总耗时就是500ms。但如果你只看单个服务的指标，每个都正常，你根本不知道瓶颈在哪。
链路追踪的核心概念：
- Span：一次调用的最小单元，比如调用数据库、调用下游服务。
- Trace：由多个Span组成的完整调用链。
- TraceID：唯一标识一次请求。
常用工具：Jaeger、Zipkin、SkyWalking。
避坑指南：我曾经在生产环境全量采集链路数据，结果导致服务吞吐量下降30%。后来改成采样策略——高流量服务采1%，低流量服务采10%，问题就解决了。
1.3 监控的核心目标
三大支柱讲完了，但光有工具还不够。你得知道监控到底要达成什么目标。
我个人总结为四个字：快、准、稳、省。
| 目标 | 说明 | 我的经验 |
|---|---|---|
| 快 | 故障发现快、定位快、恢复快 | 告警延迟超过1分钟，基本就等着被投诉吧 |
| 准 | 告警准确，不误报、不漏报 | 误报多了，团队会「狼来了」；漏报了，直接背锅 |
| 稳 | 监控系统本身要稳定，不能比业务先挂 | 我见过监控系统把自己搞崩了的…… |
| 省 | 资源消耗低，成本可控 | 全量采集一时爽，月底账单火葬场 |
1.4 三大支柱如何协同工作？
你可能会问：指标、日志、链路追踪，是不是选一个就够了？
答案是：缺一不可。
举个例子：
- 指标告警：订单服务错误率飙升 → 触发告警
- 链路追踪：查看具体调用链，发现是「订单服务→支付服务」的调用超时
- 日志分析：查看支付服务的日志，发现是第三方支付接口返回了500
你看，三个环节缺一个，排查效率都会大打折扣。
总结一下：指标告诉你「出事了」，链路追踪告诉你「在哪出的」，日志告诉你「为什么出」。三者配合，才能形成完整的监控闭环。
1.5 本章小结
这一章我们聊了：
- 为什么微服务需要监控：快速定位、保障SLA、辅助容量规划
- 三大支柱：指标（体检报告）、日志（病历本）、链路追踪（导航地图）
- 核心目标：快、准、稳、省
下一章，我会带你手把手搭建一套指标监控系统。到时候咱们聊聊Prometheus的实战配置，以及那些我踩过的坑。
记住一句话：没有监控的微服务，就像闭着眼睛开车——早晚要出事。