日志与监控入门：让系统的问题看得见

系统上线之后，最怕的不是出问题，而是出了问题却不知道问题出在哪里。用户说“页面打不开了”，运维说“服务器看着正常”，开发说“我本地是好的”——三方各执一词，排障只能靠猜。日志与监控，就是为了让系统的问题“看得见”。

一、先把日志记好

日志是系统留下的脚印。出了问题，第一件事往往不是重启服务，而是去查日志。好的日志有三个特点：

第一，分级要清晰。DEBUG 记录排查细节，INFO 记录关键流程节点，WARN 记录“现在还能跑、但不太对劲”的信号，ERROR 只记录真正失败的操作。级别滥用等于没有级别：满屏 ERROR 里找不到真正的错误，满屏 INFO 里也翻不到关键信息。

第二，一条日志要自带上下文。时间、服务名、请求编号、用户标识、关键参数，缺一不可。没有请求编号，几百个并发请求交织在一起，根本分不清哪条日志属于哪一次调用。

第三，别记敏感信息。密码、令牌、身份证号、银行卡号都不应该出现在日志里。日志会被很多人看到，也会被长期保存，记进去就是留下了隐患。

另外建议用结构化日志，也就是把日志写成 JSON 这样的固定格式。机器读起来方便，按字段检索也比全文翻找快得多。

{"level":"ERROR","time":"2026-11-09T00:30:00","service":"order","traceId":"a1b2c3","msg":"创建订单失败","reason":"库存服务超时"}

二、监控看什么

如果说日志是事后翻看的“黑匣子”，监控就是实时盯着仪表盘。刚开始做监控，不必贪多，盯住四个信号就够了：延迟、流量、错误率、饱和度。接口变慢了、请求量突增了、错误率抬头了、CPU 或内存快满了——这四个信号里，藏着绝大多数线上问题。

日志、指标、链路追踪是三件不同的工具：日志回答“发生了什么”，指标回答“现在怎么样”，链路追踪回答“一次请求在各个服务之间花了多少时间”。三者配合起来，才能完整还原一次故障。

三、告警要克制

监控配上告警才有意义，但告警太多比没有告警更糟。半夜被无关紧要的告警吵醒几次之后，人就会对所有告警麻木，真正的大故障反而被忽略。

我的做法是：只对“需要有人立刻处理”的事情发告警；判断标准不只是超过阈值，还要“持续一段时间”，避免一次抖动就报警；告警按严重程度分级，致命问题电话通知，一般问题白天处理。收到告警后，先看指标确认影响范围，再去日志里找具体原因，最后才动手修。

四、从小处落地

给想从零开始的同学一个可执行的顺序：第一步，把各服务的日志集中到一处，能按关键字和时间检索；第二步，给核心接口加上延迟、请求量、错误率三个指标；第三步，只配三到五条最重要的告警；第四步，每周固定看一次仪表盘，熟悉“正常”长什么样——只有知道正常，才能一眼认出异常。

还可以定期做一次故障演练：模拟一个服务变慢，看看告警能不能及时响、日志能不能定位到原因。演练中发现的盲点，就是下一步要补的地方。

日志与监控不是为了“显得专业”，而是为了在问题发生时少猜一次、少熬一夜。把脚印留好、把仪表盘盯住，系统出了问题，你才有据可查、有数可依。