log-analysis

name log-analysis version 1.0.0 last_updated 2026-04-08T00:00:00.000Z repository https://github.com/312362115/claude description 日志分析技能：从日志中快速定位异常、统计错误分布、提取关键时间线。 支持各种日志格式（JSON、纯文本、结构化、非结构化）。 触发词：帮我看看日志、这段日志什么意思、找找报错、日志分析、error log。 触发场景：线上问题排查、错误日志分析、用户反馈复现、性能问题排查。 即使用户没有说"日志分析"，只要给了一段日志让你看，都应触发此技能。 日志分析（Log Analysis） 日志是系统说的话。大部分时候它在说废话，但出问题时，答案就藏在那些废话里。 分析流程 拿到日志 │ ├─ 1. 识别日志格式和结构 ├─ 2. 定位异常和错误 ├─ 3. 构建时间线 ├─ 4. 分析根因 └─ 5. 给出结论和建议 第一步：识别日志格式 格式 特征 处理方式 JSON 结构化 每行一个 JSON 对象 解析 JSON，按字段筛选 标准日志格式 [时间] [级别] [模块] 消息 正则提取字段 纯文本 无固定格式 按关键词和时间戳模式匹配 堆栈跟踪 Error + at file:line 识别错误类型和调用栈 如果日志太长（>500 行），先问用户： 大概什么时间段出的问题？ 有没有相关的错误关键词？ 受影响的用户/请求 ID？ 第二步：定位异常 2.1 错误级别扫描 按优先级从高到低扫描： FATAL / CRITICAL → ERROR → WARN → 异常模式（超时、重试、拒绝） 2.2 关键模式识别 模式 关键词 可能的问题 异常/错误 Error , Exception , FATAL , panic 代码错误 超时 timeout , ETIMEDOUT , deadline exceeded 网络/依赖慢 连接失败 ECONNREFUSED , connection reset , ECONNRESET 服务不可达 资源耗尽 OOM , too many open files , pool exhausted 资源泄漏 权限问题 403 , permission denied , unauthorized 权限配置 数据问题 null , undefined , NaN , invalid 数据质量 重试/降级 retry , fallback , circuit breaker 依赖不稳定 2.3 统计错误分布 ## 错误统计 | 错误类型 | 次数 | 首次出现 | 最后出现 | |---------|------|---------|---------| | ConnectionTimeout | 45 | 14:23:01 | 14:28:33 | | NullPointerError | 3 | 14:25:12 | 14:25:14 | | AuthTokenExpired | 12 | 14:20:00 | 14:30:00 | 第三步：构建时间线 将关键事件按时间排列，还原问题发生经过： ## 事件时间线 14:20:00 [正常] 服务启动，连接数据库成功 14:23:01 [异常] 首次出现 ConnectionTimeout，目标：redis:6379 14:23:15 [异常] ConnectionTimeout 频率上升，10s 内 15 次 14:24:00 [告警] Redis 连接池耗尽，开始排队 14:25:12 [错误] NullPointerError — getUserSession() 返回 null ↑ 因为 Redis 不可用，session 查询失败 14:25:30 [降级] 熔断器触发，Redis 请求直接返回 fallback 14:28:33 [恢复] Redis 连接恢复，ConnectionTimeout 消失 14:30:00 [正常] 错误率归零 第四步：分析根因 分析方法 从结果倒推 ：用户看到的问题 → 直接原因 → 根本原因 时间相关性 ：问题开始时间前后，有没有部署/配置变更/流量突增？ 5 Whys ：连续追问"为什么"直到找到根因 输出格式 ## 根因分析 ### 现象 用户登录页报 500 错误 ### 直接原因 getUserSession() 返回 null，后续代码未做空值处理导致 NullPointerError ### 根本原因 Redis 实例在 14:23 出现网络抖动（可能是运维变更）， 导致连接超时 → 连接池耗尽 → session 查询失败 → 空值未处理 → 500 ### 因果链 Redis 网络抖动 → 连接超时 → 连接池耗尽 → session 查询失败 → 返回 null → 未做空值检查 → NullPointerError → 500 响应 第五步：结论和建议 ## 结论 1. **根因** ：Redis 网络抖动导致连接超时，session 查询失败 2. **影响面** ：14:23-14:28 期间约 200 个请求受影响 3. **恢复方式** ：Redis 连接自动恢复后问题消失 ## 建议 ### 短期（立即修复） - getUserSession() 增加空值检查，返回 null 时走降级逻辑而非抛异常 ### 中期（防止复发） - Redis 连接池增加健康检查和自动重连机制 - 添加 Redis 连接状态监控告警 ### 长期（提升韧性） - session 查询增加本地缓存兜底 - 考虑 Redis Sentinel 或 Cluster 提高可用性 分析准则 先全局后细节 ：先扫一遍日志全貌（错误分布、时间范围），再深入具体错误 关注时间相关性 ：问题前后有什么变化？部署？配置？流量？ 区分因果和巧合 ：两个事件时间接近不代表有因果关系 不猜测 ：日志里没有的信息就说"需要进一步确认"，不编原因 给可执行建议 ：不只是"加个日志"，而是"在 src/services/auth.ts:45 的 getUserSession() 返回值后加空值检查"