二十个容器里的报错
线上报错,老王开一个终端逐个容器 kubectl logs,grep 关键词,时间对不上就按本地时钟加减时区——二十个容器查一遍,半小时过去了,报错还没串起来。单体时代"登机器看日志"的排障方式,在微服务时代彻底失效:日志不统一,等于没有日志。
规范:让机器可读
统一日志第一步是统一格式——人靠肉眼读日志的时代过去了,采集与检索都靠机器。推荐 JSON 结构化日志,每行必含五个字段:时间戳(统一 UTC 或带时区)、级别、服务名、TraceId、消息。级别使用要有纪律:ERROR 必须可行动(看到就要处理,配告警)、WARN 表示可自动恢复的异常(观察趋势)、INFO 讲清楚业务动作。满屏 ERROR 的系统,真正的事故告警会被淹没。
<encoder>
<pattern>{"ts":"%d{yyyy-MM-dd HH:mm:ss.SSS}","level":"%level","svc":"order","traceId":"%X{traceId}","msg":"%replace(%msg){'\n',' '}"%n</pattern>
</encoder>
// 五要素齐全的日志,检索时才有威力:
// service=order AND level=ERROR AND traceId=abc123TraceId:把散落的日志串成一条线
结构化解决"格式统一",TraceId 解决"串成一条线":请求入口从链路上下文取 TraceId,放进 MDC,日志模板输出 %X{traceId},异步任务用装饰器透传 MDC。排障路径从此反转:不再是"逐个服务找线索",而是"拿 TraceId 一次捞出八条日志,按时间排好"。日志与链路追踪在此合流——Trace 告诉你哪一跳慢,日志告诉你那一跳里发生了什么。
采集链路的选择
两条主流路线:ELK 系——Filebeat 采集进 Kafka 缓冲,Logstash 加工后入 ES,检索能力强、生态成熟,成本也高;Loki 系——只索引标签不索引正文,存对象存储,成本省一个数量级,检索靠标签过滤加正文扫描。选型看查询模式:日志主要按"服务 + 时间 + TraceId"定位(大多数场景)选 Loki 也够;要全文检索与复杂分析上 ELK。
成本治理
日志是典型的"写的人随手,存的人肉疼":DEBUG 级别生产默认关,需要时动态开(配置中心控制);大报错堆栈去重,同一异常 5 分钟内只记一次完整堆栈;保留期分级——ERROR 30 天、INFO 7 天,冷数据转对象存储;入 Kafka 前在采集端做一次过滤,别把没用的全推进存储。下一篇把可观测的第三块拼上:指标监控与告警的四大黄金指标。
评论 (0)