为什么要把多链路日志集中起来

在传统部署方式下，Nginx 的访问日志与错误日志、应用服务日志、数据库错误日志和慢查询日志往往分别落在不同主机、不同目录中。业务一旦扩展为多节点、多实例甚至容器化部署，排错时需要在多台机器之间反复登录、grep、比对时间，效率低且容易遗漏关键线索。集中检索的核心目标，是把分散在不同链路的日志统一采集、统一字段、统一入口，让一次查询即可覆盖从接入层到数据层的完整过程。

多链路日志的典型来源

• 接入层：Nginx / OpenResty 的 access_log、error_log，以及负载均衡设备或云负载均衡的访问记录。
• 应用层：业务服务的运行日志、异常堆栈、框架访问日志。
• 数据层：MySQL 的 error log、slow query log，PostgreSQL 的服务器日志与慢查询记录，以及连接池、代理中间件的日志。
• 系统层：操作系统日志、内核日志、OOM 与磁盘告警记录。

这些日志格式各异、量级不同，直接混在一起检索会非常低效，因此采集阶段就需要做结构化处理。

采集与传输链路的组织方式

常见做法是在每台主机或每个容器节点部署轻量采集器，例如 Filebeat、Fluent Bit、Vector 或 Promtail，将原始日志解析为结构化字段后，写入缓冲层再进入存储与检索系统。缓冲层通常使用 Kafka、Pulsar 或 Redis 之类的消息队列，用于削峰填谷，避免日志洪峰直接冲击后端存储。存储侧可选择 Elasticsearch / OpenSearch、Loki、ClickHouse 等，并可将历史数据转存至对象存储以降低长期保存成本。

Nginx 日志的采集要点

• 通过 log_format 定义结构化字段，便于后续解析，例如请求时间、状态码、上游响应时间、上游地址等。
• 接入层建议输出 request_id，并通过请求头透传给上游服务，使同一次请求在各层日志中拥有相同的关联标识。
• access_log 与 error_log 建议分开采集与索引，二者量级和用途不同。

数据库日志的采集要点

• 数据库错误日志通常量小但价值高，建议全量采集。
• 慢查询日志需要谨慎设置阈值，阈值过低会显著增加日志量并影响 I/O。
• 通用查询日志（general log）对性能影响较大，生产环境如需开启应作为临时手段，用完及时关闭。
• 数据库日志一般不携带应用请求标识，可通过时间窗口、连接来源、执行语句指纹等方式与接入层日志做关联。

统一字段与关联标识

集中检索能否真正提效，取决于字段是否统一。建议至少约定以下字段：时间戳（统一时区）、主机或实例标识、服务名、环境标识、日志级别、请求标识、状态码、耗时、客户端地址、上游地址。其中请求标识是串联多链路的关键，接入层生成后需逐层透传，应用在写日志时输出，数据库侧可通过连接信息或业务字段间接对齐。

此外，各节点应启用时间同步服务，保证时间戳可比对。时间漂移会直接导致跨链路检索出现偏差，是最容易被忽视的排错障碍之一。

集中检索排错的标准流程

1. 明确现象与时间窗：确认是全局故障还是个别接口异常，锁定大致发生时间。
2. 从接入层切入：按时间范围和服务维度过滤 Nginx 日志，观察状态码分布、上游响应时间与错误日志。
3. 抽取关联标识：从异常请求中取出请求标识，作为后续全链路检索的线索。
4. 跨链路串联：用同一标识检索应用日志与相关数据层记录，还原完整调用过程。
5. 检查数据层状态：查看慢查询、锁等待、连接数是否异常，判断是否为数据库瓶颈。
6. 结合监控指标验证：将日志结论与 CPU、内存、磁盘 I/O、网络等指标对照，避免误判。
7. 沉淀与改进：记录排查结论，补充告警规则与日志字段，使同类问题下次能被更快发现。

常见排错场景与切入点

• 接入层返回 5xx：先看 Nginx 错误日志中与上游通信相关的条目，再确认上游服务是否存活、连接是否被拒绝或超时。
• 请求耗时偏高但状态码正常：对比接入层记录的上游响应时间与应用内部耗时，判断耗时发生在网络、应用还是数据库。
• 数据库连接异常：检查数据库错误日志与连接数上限相关记录，同时查看应用侧连接池配置与回收情况。
• 慢查询集中出现：关注慢查询日志中的执行语句与扫描行数，结合业务发布记录判断是否为新增逻辑导致。
• 锁等待与超时：通过数据库日志与应用异常堆栈交叉比对，定位争用的事务与表。

容量、成本与合规注意事项

日志量会随业务规模持续增长，建议按重要性分级保存：错误日志与关键链路日志保留较长时间，访问明细可缩短保留周期或降采样，历史数据转冷存储。同时，日志中可能包含 URL 参数、SQL 语句、客户端地址等敏感信息，采集与入库前应做脱敏处理，并通过权限控制限制检索范围，留存期限需符合相关法律法规与内部规范要求。

小结

多链路日志集中检索的价值，不在于把日志简单堆到一处，而在于统一字段、打通关联标识、建立固定排查路径。当 Nginx 接入日志与数据库系统日志能够在同一入口按时间与请求标识对齐时，排错就从“逐台机器找线索”变成“按链路还原事实”，定位时间与误判概率都会明显下降。