“在我机器上能跑"和"在生产环境能跑"之间有一道鸿沟，监控本该把它填上。可大多数时候填不上，因为监控往往被当成运维工具来建，而不是开发者出事时会伸手去拿的东西。
我最近开始以自由职业身份做 DevOps 和基础设施的活儿，每到一个新环境，最先看的东西之一就是监控配置——它比 README 更能说明一个团队的真实状态。失败的方式几乎千篇一律：工具都在，但和开发者的实际工作方式是脱节的。有人在一个 bug 上耗了三小时，其实能看生产日志的话五分钟就完事；故障不是靠告警发现的，是靠客服工单；或者反过来，一天 200 条告警，绝大部分是噪音，于是所有人干脆全部无视，每次出事的前半小时都花在搞清"到底坏了什么"上，而不是修它。
指标、日志、链路：打通了才有用#
指标告诉你出问题了（错误率飙升、延迟突增），日志告诉你发生了什么（堆栈、请求内容、报错信息），链路告诉你问题在哪（哪个服务、哪个接口、哪次数据库调用）。这些都是常识。关键在于三者有没有打通：告警一响，你应该能从指标一路点到相关日志，再点到链路。如果开发者还得在三个工具之间手动比对时间戳，那不管每个工具单看多漂亮，这套方案就是失败的。
仪表板也用同一条标准检验。CPU、内存、磁盘 I/O 对容量规划很重要，但对排查一个 500 错误毫无帮助。大家会主动打开的仪表板，上面放的是：技术指标旁边摆着业务指标（错误率旁边是每小时注册数）、时间轴上叠加的最近部署、最近一小时的前五个错误（带日志链接），以及延迟百分位——p50、p95、p99——而不只是平均值。一个没人主动打开的仪表板，就是没有证明自己的价值。
告警同理。每条告警都该回答两个问题：坏了什么？从哪开始查？
坏告警：“web-server-3 CPU 高”
好告警：“14:32 起 /api/payments 错误率 > 5%。最近部署：14:15，@sarah。[查看日志] [查看链路]”
往第二种靠拢有几个办法：按基线偏离告警，而不是按拍脑袋定的阈值；按归属路由（支付的错误发给支付团队，别全组织广播）；相关错误合并成一条 Slack 消息，别发 50 条。反馈环也要收紧——从"出事了"到"开发者知道了"应该在一分钟以内，这意味着实时日志流而不是五分钟一批、每个仪表板都有部署标记、以及跨服务边界不断链的分布式追踪。
为用它的人而建#
运维团队最大的错误，是给自己建监控。解决办法一点也不高深：在开发者调试的时候坐到旁边，看他们在哪卡住；问问事故当中大家在问什么——“哪个服务？““什么变了？““请求长什么样？"；再搞清楚对产品真正要紧的指标是什么。基本不会是 CPU，多半是结账完成率、上传成功率这类东西。
然后是消除阻力。给新服务接监控要花一整天的话，没人会做。要提供能自动接入你们在用框架（Django、Express、Spring）的库、可以直接复制的仪表板和告警模板，以及不用提工单就能自己加指标的自助工具。整套东西还要当代码来管：配置进版本控制，告警规则要测试（该响的时候真的会响），要做多区域的话一开始就规划进去。
AWS 上的小团队？先用 CloudWatch#
不到 50 个工程师、又跑在 AWS 上的话，CloudWatch 就是正确起点，第一天就想买更高级工具的冲动最好忍住。EC2、Lambda、RDS、ECS 全都自动上报 CloudWatch，不写一行埋点代码就有了可见性；小团队每月 10~50 美元，没有固定平台费；指标、日志、链路（走 X-Ray）、告警都在一个地方。像样的告警和仪表板，一个下午就能搭出来，用不了几周。
最被低估的是 CloudWatch Logs Insights——不用架 Elasticsearch 就能查日志：
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)其他几点：
- 复合告警能压噪音：错误率高"且"响应时间劣化时才告警，别每个条件单独响。
- 真正的价值在自定义指标。用 CloudWatch SDK 把业务指标（注册、交易、功能使用）和基础设施指标放在一起。
- CloudWatch Synthetics 能按计划跑金丝雀测试，模拟真实用户路径，让你赶在用户之前发现结账坏了。
- X-Ray 用极少的配置就能拿到分布式追踪，对大多数微服务架构够用了。
什么时候该毕业也很清楚：要上多云了、想要正经的异常检测了、仪表板定制开始难受了，或者团队过了 50 人、需要真正的协作功能了。
团队大了：DataDog#
DataDog 很贵——大组织一年 2 万到 10 万美元以上很正常——但到了规模就值回票价。AWS、Azure、GCP、本地机房、容器、Serverless、数据库、前端，一个视图全看到。Watchdog 不用手动调阈值就能标记异常模式，这点很关键，因为几千个服务是不可能靠人盯的。它还补上了 CloudWatch 缺的协作层：团队仪表板、RBAC、共享调查笔记本、PagerDuty/Opsgenie 集成、多条件告警、阈值突破预测、维护窗口，以及能下钻到代码级性能分析的 APM 和自动生成的服务拓扑图。
推行顺序我大致会这么排：先给关键服务接入，第一天就按团队和环境把标签打全；指标命名规范、仪表板模板、告警级别、SLO 定义要趁早定好——事后补标准是苦役；接入 CI/CD 部署标记、事件管理和 Slack；给培训留出时间，DataDog 强归强，不是看看就会的；最后盯紧账单：过滤噪音指标、大流量服务对链路采样、定期盘点到底在为哪些功能付费。
签约之前值得比较一下：New Relic（定位类似，大流量追踪有时更便宜）、Dynatrace（AIOps 很强，金融行业常见）、Splunk（日志分析顶级，安全团队已经在用的话更合适）、Grafana Cloud（已经在用 Prometheus/Loki 的话是自然归宿）。
实践中很多团队最后落在混合方案上：AWS 原生服务交给自动又便宜的 CloudWatch，应用层交给 DataDog，再让 DataDog 采集 CloudWatch 指标拼出统一视图。不花哨，但好使。
从零开始的话#
我的顺序是：先找开发者聊，问清事故当中什么最痛；给要紧的流程定义 SLO——对登录、结账、搜索来说，“正常"到底是什么意思；从这条关键路径开始埋点；接着加分布式追踪，在微服务架构里它的排障回报率最高；给每条告警配一份运维手册，让凌晨三点的自己知道该查什么；然后在日历上排一个季度回顾，删掉过期告警、修正漂移的阈值、确认仪表板还对得上现在的架构。
再列几个我反复把团队从里面捞出来的坑：工具太多（能配合的 3 个胜过各自为战的 6 个）；图表没有基线（500 rps 是正常水位还是十倍突增？）；监控了用户根本感知不到的东西（无状态容器的磁盘 I/O）；还有监控系统本身没有冗余——告警系统在事故中间挂掉，你就在最不能瞎的时候瞎了。
这些没有一件需要最花哨的工具。需要的只是：让开发者在他们真正会看的地方，快速拿到需要的信息。