“代码在我的机器上能运行"和"代码在生产环境中能运行"之间有一道鸿沟。监控本应弥合这道鸿沟，但大多数时候做不到——因为它被当作运维工具来搭建，而不是开发者遇到问题时会用的工具。
糟糕的监控长什么样#
不是没有工具，而是：
- 盲目调试：如果能看到生产日志，5分钟就能解决的bug，开发者花了3小时
- 客户先发现bug：不是通过告警，而是通过工单才知道出了故障
- 告警疲劳：一天200条告警，大部分不相关，所以所有人都忽略所有告警
- 缓慢的事件响应：出了问题，头30分钟不是在修复而是在搞清楚到底发生了什么
模式每次都一样——监控存在，但和开发者实际的工作方式脱节。
真正需要什么#
指标、日志、链路追踪——要打通#
- 指标告诉你有问题（错误率飙升、延迟突增）
- 日志告诉你发生了什么（堆栈跟踪、请求内容、错误信息）
- 链路追踪告诉你问题在哪里（哪个服务、哪个接口、哪个数据库调用）
这些只有关联起来才有用。告警触发时，你应该能从指标点击到相关日志再到链路。如果开发者需要在三个不同工具之间手动对比时间戳，说明这套方案没有真正起作用。
开发者会打开的仪表板#
大多数监控仪表板展示的是CPU使用率、内存、磁盘I/O。这些对容量规划有用，但对调试500错误没帮助。
构建展示以下内容的仪表板：
- 技术指标旁边放业务指标（错误率旁边放每小时注册数）
- 时间轴上标注最近的部署
- 最近一小时的前5个错误，附带日志链接
- 延迟百分位数（p50、p95、p99），不只是平均值
如果开发者不会主动打开仪表板，说明它还不够有用。
告诉你该怎么做的告警#
每条告警应该回答两个问题：
- 什么坏了？
- 从哪里开始排查？
坏的告警：“web-server-3 CPU高”
好的告警：“14:32起 /api/payments 错误率 > 5%。最近一次部署：14:15 @sarah。[查看日志] [查看链路]”
其他有帮助的做法：
- 基线优于阈值：当行为偏离正常时告警，而不是超过某个随意设定的数字
- 按归属路由：支付错误发给支付团队，不是全组织
- 分组：一组相关错误发一条Slack消息，不是50条单独的告警
快速反馈#
从"出问题了"到"开发者知道了"的时间应该在一分钟以内。这意味着：
- 实时日志流，不是每5分钟批处理
- 仪表板上有部署标记，能看出是不是某次发布导致的问题
- 跨服务边界的分布式追踪
为开发者搭建监控，不是为运维#
DevOps团队最大的错误：为自己搭建监控。
和开发者聊聊#
选工具之前：
- 在调试过程中坐在开发者旁边。观察他们做什么、搜索什么、在哪里卡住。
- 问他们在事件中有什么问题。“哪个服务？““什么变了？““请求长什么样？”
- 找出对产品真正重要的指标。不是CPU——而是结账完成率、搜索延迟、文件上传成功率这些。
消除阻力#
如果给一个新服务加监控需要一天工作量，开发者不会去做。提供：
- 自动检测常用框架（Django、Express、Spring）的库
- 仪表板和告警的复制粘贴模板
- 不用提工单就能让开发者自己加指标的自助工具
保持可维护性#
- 监控配置纳入版本管理
- 测试告警规则——验证告警在应该触发时确实触发
- 如果要做多区域，从一开始就规划
按团队规模选择工具#
AWS上的小团队：从CloudWatch开始#
如果你的团队不到50个工程师并且运行在AWS上，CloudWatch是正确的起点。
零配置的基础设施指标：EC2、Lambda、RDS、ECS都自动向CloudWatch上报。不用写检测代码就有可见性。
低成本：小团队月费$10-50。没有固定平台费用。
都在一个地方：指标、日志、链路追踪（通过X-Ray）、告警。工具散乱少。
快速搭建：几小时而不是几周就能建立有意义的告警和仪表板。
把CloudWatch用好#
- CloudWatch Logs Insights被低估了。不用搭ElasticSearch就能查询日志：
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)复合告警减少噪音。错误率高且响应时间下降时才告警，不是分别告警每个条件。
自定义指标才是价值所在。用CloudWatch SDK把业务指标（注册、交易、功能使用）和基础设施指标一起追踪。
CloudWatch Synthetics按计划运行模拟用户旅程的金丝雀测试。在用户之前发现关键路径的问题。
X-Ray集成以最少的配置实现分布式追踪。对大多数微服务架构够用。
什么时候该换#
CloudWatch开始露出短板的时候：
- 转向多云
- 需要高级异常检测
- 仪表板定制变得困难
- 50+工程师需要更好的协作功能
大团队：DataDog#
DataDog很贵（大型组织年费$20-100K+），但在规模上物有所值。
跨平台：AWS、Azure、GCP、本地、容器、Serverless、数据库、前端——全在一个视图里监控。
自动异常检测：Watchdog无需手动设阈值就能标记异常模式。你不可能手动看管几千个服务。
团队协作：团队专属仪表板、RBAC、共享调查笔记本、PagerDuty/Opsgenie集成。
高级告警：多条件告警、预测（预测何时会突破阈值）、适应流量模式的异常检测、维护窗口。
深度APM：代码级性能分析、关联到追踪的安全监控、按服务的成本归因、自动生成的服务拓扑图。
DataDog推行策略#
从小处开始：先检测关键服务。用标签按团队和环境组织。
尽早定标准：指标命名规范、仪表板模板、告警严重级别、SLO定义。这能省去后面大量的麻烦。
和所有工具集成：CI/CD部署标记、事件管理、Slack通知、ITSM工单。
培训团队：内部文档、团队负责人、APM和性能分析的工作坊。DataDog很强大但有学习曲线。
关注成本：过滤噪音指标，高流量服务中对追踪采样，定期审计功能使用，所有东西打标签做成本分摊。
替代方案#
- New Relic：和DataDog类似，高流量追踪有时更便宜
- Dynatrace：AI/AIOps很强，金融行业流行
- Splunk：日志分析顶级，尤其是已经在用Splunk做安全的话
- Grafana Cloud：开源友好，已经用Prometheus/Loki的团队首选
混合方案#
很多团队组合使用：
- AWS原生服务用CloudWatch（自动、便宜）
- 应用和跨平台可见性用DataDog
- DataDog采集CloudWatch指标提供统一视图
这通常是最务实的方案。
常见陷阱#
工具过多：能配合的3个工具胜过不能配合的6个。不要什么监控产品都上。
没有上下文的指标：展示"每秒请求数"的图表如果没有基线就毫无意义。500 rps是正常还是10倍的突增？
没人用：开发者不打开仪表板的话，监控就没在发挥作用。让它成为工作流的一部分，不是一个独立系统。
监控了错误的东西：追踪对用户和业务结果重要的指标。“无状态容器的磁盘I/O"大概率不需要。
没给监控系统做监控：如果告警系统在事件期间挂了，你在最需要的时候什么都看不到。要有冗余。
入门#
从零搭建监控或修复现有问题：
- 先和开发者聊。了解他们在事件中遇到什么困难。
- 定义SLO。对最重要的用户流程来说，“正常工作"意味着什么？设定目标。
- 先检测关键路径。从最重要的用户旅程开始——登录、结账、搜索，驱动业务的那些。
- 加上链路追踪。分布式追踪在微服务架构中提供最大的调试投资回报。
- 写运维手册。每条告警都应该链接到一个文档，说明该检查什么、常见原因怎么修。
- 每季度回顾。删除过期告警，更新阈值，确认仪表板反映当前架构。
好的监控不是拥有最花哨的工具，而是给开发者提供快速解决问题所需的信息。