北京
凌晨两点，PagerDuty突然炸响。你手忙脚乱登录服务器，tail -f 看日志，SSH 连了五台机器才定位问题——最后发现只是下游 API 超时。这种"盲修"经历，Eric Smith 在 Picnic Engineering 的博客里写得很直白：开发者花大量时间在可观测性上，不是为了炫技，是为了"消除谜团，给问题解决指明方向"。
可观测性（Observability）这个词近年被说烂了，但多数人理解的版本是"上线后加监控"。真相更残酷：分布式系统里，等 bug 发生再补观测能力，等于火灾发生后才装烟雾报警器。尤其是涉及边缘硬件的系统，节点可能直接"沉默消失"，连报错日志都发不出来。
这里有一份"Day Zero"底线清单——不是豪华全家桶，是能让系统从"猜"变成"知"的最小可行集合。
一、深度健康检查：200 OK 是谎言
标准健康检查只验证进程活着，不验证"有用"。/health 端点必须同时检查应用本身和依赖项：数据库连得上吗？缓存响应正常吗？消息队列没堵死吧？一个返回 200 但数据库挂掉的端点，只会让你在事故时浪费宝贵的排查时间。
二、集中日志：SSH 是最后的手段
还在用 SSH tail 日志？这是开发者的噩梦模式。用 Fluentd 或 Datadog Agent 这类日志收集器，把日志和指标持续泵到监控端。SSH 只留给网络分区这种极端场景——当节点连不上中心，你才需要"破窗"进去。
三、硬件指标：别让资源问题伪装成逻辑 bug
CPU 打满、内存泄漏、磁盘 I/O 饱和——这些会让系统"随机"卡顿的元凶，没有指标就看起来像代码逻辑错误。提前追踪资源曲线，你能在应用崩溃前几天就嗅到内存泄漏的味道。
四、告警：仪表盘是历史，告警是行动
持续高 CPU、内存飙高、应用层异常——这些需要推送到手机或 Slack 的实时信号。别等用户投诉才发现问题。
五、心跳监控：沉默是最常见的故障模式
分布式系统里，节点掉线往往不是"报错"，是"消失"。断网或断电时，节点连"我失败了"都发不出来。解法是心跳机制：每个节点定期向中心发送脉冲，脉冲停止即触发告警——你知道有网络分区或电源故障，哪怕节点本身无法告知。
这五件事不做，你就是在黑暗中调试。做了，至少手里有盏手电筒。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
