日志在可观测体系中扮演着“证据链”的核心角色，它记录系统全量行为，是故障排查时唯一能还原现场、定位根因的可靠依据。
日志在可观测性中的作用
日志是系统运行产生的原始文字记录，它不依赖采样，也不依赖预设规则，所有行为都被如实写入，这种“无差别记录”的特性,让日志在可观测体系的三大支柱中扮演最基础的排查角色。
日志是故障现场的“全景记录者”
当指标显示CPU飙升、链路追踪标记出慢调用时，只有日志能告诉你具体发生了什么，例如一个订单丢失问题，指标可能显示接口成功率下降，链路追踪找到异常的服务实例，但日志会记录下请求参数、数据库返回值、异常堆栈等完整信息，排查人员可以沿着时间线，逐行查看日志,还原出错前的一连串操作。
- 记录请求体、响应体、耗时、状态码
- 支持自定义字段，业务上下文可追踪
- 异常堆栈直接指向代码行号
日志在根因分析中的不可替代性
多数情况下，指标和链路追踪只能帮你缩小范围，但最终确认根因需要依赖日志，业内专家指出，大约七八成的故障排查最终都要通过日志才能锁定问题，比如内存泄漏问题，链路追踪无法直接反映GC是否频繁，而日志中GC详情、线程堆栈、内存分配记录会暴露异常模式，日志是排查的“最终裁判”，其他数据源提供线索,日志提供证据。
日志与链路追踪对比：排查场景下的优劣势
在可观测体系里，日志和链路追踪常被拿来做对比，两者都能帮助排查，但数据粒度、查询效率和成本各不相同，理解这些差异,才能在不同场景下用对工具。
数据粒度与成本对比
| 对比维度 | 日志 | 链路追踪 |
|---|---|---|
| 数据机构 | 结构化/非结构化文本 | 结构化的span调用链 |
| 存储粒度 | 全量记录，每个请求可产生多条日志 | 采样记录，默认只记录1%-10%的请求 |
| 查询效率 | 全文检索较慢，需索引支持 | 按traceId快速关联，查询延迟低 |
| 存储成本 | 高，需大量磁盘或SaaS存储 | 低，采样后数据量可控 |
| 排查深度 | 能还原完整操作细节，包括业务参数 | 聚焦调用路径，缺乏业务上下文 |
从表格可以看出，日志在细粒度排查上具有明显优势，但代价是存储和查询成本，链路追踪适合快速定位哪个环节出错，而日志适合深挖具体原因，行业共识认为，两者结合是最佳实践：先用链路追踪缩小范围,再用日志确认根因。
典型场景下的选择逻辑
- 慢调用排查，链路追踪能快速找出耗时最长的服务，日志则能提供慢的具体原因，比如SQL执行计划耗时、外部服务超时参数。
- 业务逻辑错误，日志直接记录异常码和错误消息，链路追踪可能只记录调用失败状态,无法提供业务细节。
- 安全审计，日志必须保留全量访问记录,链路追踪的采样模式无法满足合规要求。
日志排查故障的步骤与实操技巧
日志排查不是盲目翻文件，而是有章可循的流程，掌握日志排查故障的步骤,能帮助你在告警时快速定位问题。
四步排查法
- 确认异常时间范围：从告警或监控看板中获取首次异常出现的时间点,精确到秒。
- 提取相关日志片段：根据服务名、实例ID、日志文件路径,用grep或日志平台搜索该时间段的日志。
- 关联上下文线索：如果系统支持traceId，直接搜索traceId，将请求的全链路日志串起来，如果无traceId，则通过请求ID、用户ID、订单号等业务字段关联。
- 定位根因并验证：找到异常日志后，分析错误类型、堆栈、参数,复现并验证修复方案。
实操命令：用grep和awk快速过滤
在Linux服务器上直接排查时,使用以下命令组合：
- 搜索错误日志：
grep "ERROR" /var/log/app/logfile.log | grep "订单超时"
- 提取时间戳和错误信息：
grep "ERROR" logfile.log | awk '{print $1, $2, $NF}' - 查看某个traceId的完整日志：
grep "traceId=abc123" logfile.log | less
如果日志文件过大，可以用tail -n 1000限制范围,避免全量加载。
利用日志级别控制排查粒度
生产环境通常只记录INFO及以上级别，排查时可以将特定服务的日志级别临时调整为DEBUG，获取更多细节，操作方式：通过配置中心动态修改logback或log4j的级别，无需重启服务，调整后，重新触发异常，DEBUG日志会打印出完整的参数、SQL、外部调用参数,帮助定位。
日志分析平台选型：价格与功能对比
随着业务规模增长，自建日志平台或采购SaaS服务成为刚需，日志分析平台价格直接影响选型决策,需要结合功能需求和预算综合考虑。
开源与商业方案的价格差异
国内日志分析平台价格差异较大，主要取决于存储量、查询并发和运维成本。
| 方案 | 功能特点 | 费用模式 | 适合场景 |
|---|---|---|---|
| ELK (Elasticsearch + Logstash + Kibana) | 功能全面，自定义能力强 | 机器成本+运维人力，大量存储时ES资源消耗高 | 自建团队，有运维能力 |
| Loki (Grafana Loki) | 轻量，只索引元数据，查询成本低 | 存储成本低，但需搭配Grafana | 轻量级监控，日志量不大 |
| 简米云日志服务 (SLS) | 云原生，实时分析，支持sql | 按存储量+读写流量计费，国内日志分析平台价格较透明 | 大流量，免运维 |
| 酷番云日志服务 (CLS) | 类似SLS，集成生态 | 按量付费，初期成本低 | 酷番云用户，中小规模 |
| Splunk | 企业级功能，机器学习和报表 | 按索引量许可，费用高 | 大型企业，对合规要求高 |
从对比可以看出，开源方案前期机器成本低，但运维人力不容忽视；商业SaaS方案按量付费，门槛低，但长期存储成本高，选型时需要根据日志量、查询频率、团队规模做出权衡。
选型建议：根据场景匹配
- 小团队或初创公司：日志量在每天几十GB以内，选择ELK自建在ECS上，成本可控，但需要管理ES集群，如果不想运维，可直接用Loki，搭配Grafana，查询简单,存储成本低。
- 中等规模业务：日均日志量百GB以上，建议使用SaaS服务，如简米云SLS或酷番云CLS，国内日志分析平台价格在百GB级别每月约三千到五千元,相比自建节省人力成本。
- 大型企业或合规要求强：考虑Splunk或ELK定制化部署，虽然价格高,但安全和权限控制更完善。
日志在可观测体系中的排查角色始终是“底牌”，它不追求实时性，但追求完整性；它不擅长快速定位，但擅长确认细节，无论可观测技术如何演进，日志始终是故障排查时最值得信赖的依赖，掌握日志的排查方法和平台选型思路,能让你在故障面前更从容。
日志在可观测性排查中的常见问题
日志与指标在排查故障时哪个更关键？
指标提供宏观趋势，能快速发现异常，但无法解释原因，日志提供微观细节，能定位根因，两者互相补充，缺一不可，排查时通常先看指标缩小范围,再用日志深挖根因。
日志分析平台的价格差距大，如何选择？
价格主要受存储量和查询并发影响，开源方案机器成本低但运维人力高，商业SaaS方案按量付费免运维，选择时需评估团队运维能力和日志量，国内日志分析平台价格在月存储百GB量级时，SaaS费用约三千到五千元,自建则需考虑ES集群的机器成本。
日志排查时如何快速关联上下文？
团队需在日志中统一注入traceId或requestId，并在请求入口生成唯一标识，贯穿所有下游服务，排查时搜索该ID即可聚合全链路日志，如果系统未实现，可通过业务字段如用户ID、订单号进行关联，但效率较低,建议优先实现traceId透传。