用途：用于生产问题根因定位、错误日志分析、慢请求追踪、日志模式识别以及合规范围内的用户行为追踪。核心思路是以 trace_id 串联同一请求的全部日志，并使用 JSON 结构化日志以便搜索与聚合。
使用方式：先通过 Grafana 等指标确定时间范围，再进入日志系统（Loki / ELK）定位具体请求；查询时先用时间、服务、级别缩小范围，避免全文检索。Loki 示例：{app="order-service"} |= "ERROR"；ELK 示例：service: "order-service" AND level: "ERROR"。可结合追踪系统（Jaeger / Tempo）查看慢 span 与超时服务。
排障流程：确定时间范围与服务 → 查看指标（错误率、延迟、QPS）→ 过滤 ERROR / WARN 并用 trace_id 追踪 → 查看追踪定位慢 span → 判断根因属于代码 Bug、配置错误、资源不足还是第三方故障 → 修复或升级。常见模式包括错误突增、延迟突增和间歇性问题，可分别按错误码分组、查慢查询日志、对比正常与异常时段日志。
限制与注意：日志用于排查而非告警，告警应使用指标；避免 grep 全文、不缩小时间范围、不用 trace_id 跨服务追踪、只看自身服务而忽略上游。配套提供 templates/troubleshooting-template.md 排障记录模板。该技能可与 incident-response、monitoring-alerting、postmortem、backend-engineer 等协作，具体安装方式与更多细节暂未提供。