⚡

日志分析器Skill log-analyzer

日志分析器是一个用于解析和分析应用程序日志的技能，能够识别错误、检测模式、提供性能洞察和系统健康评估。关键词：日志分析、错误检测、性能监控、DevOps、应用日志管理、错误修复、监控建议。

DevOps 0 次安装 0 次浏览 更新于 3/11/2026

名称: 日志分析器 描述: 解析和分析应用程序日志，以识别错误、模式和见解。

日志分析器技能

解析和分析应用程序日志，以识别错误、模式和见解。

指令

您是一个日志分析专家。当被调用时：

  1. 解析日志文件:

    • 识别日志格式（JSON、syslog、Apache、自定义）
    • 从日志中提取结构化数据
    • 处理多行堆栈跟踪
    • 解析时间戳并标准化格式

  2. 分析模式:

    • 识别错误频率和趋势
    • 检测错误峰值或异常
    • 查找常见错误消息
    • 跟踪随时间变化的错误模式
    • 识别事件之间的相关性

  3. 生成见解:

    • 最频繁的错误
    • 错误率趋势
    • 来自日志的性能指标
    • 用户活动模式
    • 系统健康指标

  4. 提供推荐:

    • 根本原因分析
    • 常见错误的建议修复
    • 日志记录改进
    • 监控建议

日志格式检测

JSON 日志

{
  "timestamp": "2024-01-15T10:30:00.000Z",
  "level": "error",
  "message": "数据库连接失败",
  "service": "api",
  "userId": "12345",
  "error": {
    "code": "ECONNREFUSED",
    "stack": "错误: 连接 ECONNREFUSED..."
  }
}

标准格式（组合）

192.168.1.1 - - [15/Jan/2024:10:30:00 +0000] "GET /api/users HTTP/1.1" 500 1234 "-" "Mozilla/5.0..."

应用程序日志

2024-01-15 10:30:00 错误 [用户服务] 获取用户失败：用户未找到（ID: 12345）
  在 UserService.getUser (user-service.js:45:10)
  在异步 API.handler (api.js:23:5)

分析模式

错误频率分析

## 前10大错误（最近24小时）

1. **数据库连接超时** (1,234 次发生)
   - 首次发现: 2024-01-15 08:00:00
   - 最后发现: 2024-01-15 10:30:00
   - 峰值: 2024-01-15 09:15:00 (1分钟内234个错误)
   - 受影响服务: api, worker
   - 影响: 高

2. **用户未找到** (567 次发生)
   - 模式: 常规分布
   - 可能原因: 正常用户行为
   - 影响: 低

3. **速率限制超出** (345 次发生)
   - 来源IP: 192.168.1.100, 10.0.0.50
   - 模式: 突发流量
   - 影响: 中等

时间线分析

## 错误时间线

08:00 - 正常操作（每分钟5-10个错误）
09:00 - 数据库连接错误激增（每分钟200+个错误）
09:15 - 峰值错误率（每分钟234个错误）
09:30 - 数据库连接恢复
10:00 - 回归正常（每分钟8-12个错误）

## 相关性
- 流量在09:00增加300%
- 数据库CPU在事件期间达到95%
- 连接池耗尽

性能指标

## 响应时间（来自日志）

**平均**: 234ms
**P50**: 180ms
**P95**: 450ms
**P99**: 890ms

**慢请求** (>1s):
- /api/search: 2.3s 平均（45个请求）
- /api/reports: 1.8s 平均（23个请求）

**快速请求** (<100ms):
- /api/health: 5ms 平均
- /api/status: 12ms 平均

使用示例

@log-analyzer
@log-analyzer app.log
@log-analyzer --errors-only
@log-analyzer --time-range "last 24h"
@log-analyzer --pattern "database"
@log-analyzer --format json

报告格式

# 日志分析报告
**期间**: 2024-01-15 00:00:00 至 2024-01-15 23:59:59
**日志文件**: /var/log/app.log
**总条目**: 145,678
**错误**: 2,345 (1.6%)
**警告**: 8,901 (6.1%)

---

## 执行摘要

- **关键问题**: 3
- **高优先级**: 8
- **中等优先级**: 15
- **整体健康**: ⚠️ 降级（检测到数据库问题）

### 关键发现
1. 09:00-09:30数据库连接池耗尽
2. 2个IP地址触发速率限制
3. 搜索端点查询性能慢
4. 工作服务内存泄漏警告

---

## 关键问题

### 1. 数据库连接池耗尽
**严重性**: 关键
**发生次数**: 1,234
**时间范围**: 09:00:00 - 09:30:00
**影响**: 服务降级，请求失败

**错误模式**:

错误: 连接 ETIMEDOUT 错误: 连接过多 错误: 连接池超时


**根本原因分析**:
- 流量激增（增加300%）
- 连接池大小: 10（不足）
- 连接未正确释放
- 未配置连接超时

**推荐**:
1. 增加连接池大小至50
2. 实施连接超时（30秒）
3. 审查连接释放逻辑
4. 添加连接池监控
5. 实施断路器模式

**代码修复**:
```javascript
// 增加池大小
const pool = new Pool({
  max: 50,  // 之前: 10
  min: 5,
  acquireTimeoutMillis: 30000,
  idleTimeoutMillis: 30000
});

// 确保连接被释放
try {
  const client = await pool.connect();
  const result = await client.query('SELECT * FROM users');
  return result;
} finally {
  client.release(); // 总是释放！
}

2. 工作服务内存泄漏

严重性: 关键 首次检测: 06:00:00 模式: 内存使用每小时增加50MB

证据:

06:00 - 内存: 512MB
09:00 - 内存: 662MB
12:00 - 内存: 812MB
15:00 - 内存: 962MB（警告阈值）

可能原因:

  • 事件监听器未清理
  • 缓存数据未清除
  • 循环引用

推荐:

  1. 添加堆快照分析
  2. 审查事件监听器清理
  3. 实施缓存驱逐策略
  4. 使用堆分析器监控

高优先级问题

3. 慢搜索查询性能

严重性: 高 端点: /api/search 发生次数: 45个请求 平均响应: 2.3秒（目标: <500ms）

慢查询示例:

2024-01-15 10:15:23 警告 [搜索服务] 查询耗时 2,345ms
  SELECT * FROM products WHERE name LIKE '%keyword%'
  检查行数: 1,234,567

推荐:

  1. 添加全文搜索索引
  2. 实施分页（限制结果）
  3. 使用Elasticsearch进行搜索
  4. 添加查询结果缓存

4. 速率限制违规

严重性: 高 受影响IP: 2 被阻止请求: 345

详情:

  • IP: 192.168.1.100 (245个被阻止请求)

    • 模式: 自动化抓取
    • 推荐: 考虑永久阻止

  • IP: 10.0.0.50 (100个被阻止请求)

    • 模式: 来自合法用户的突发流量
    • 推荐: 增加认证用户的速率限制

错误分布

按严重性

  • 错误: 2,345 (1.6%)
  • 警告: 8,901 (6.1%)
  • 信息: 134,432 (92.3%)

按服务

  • api: 1,567个错误
  • worker: 456个错误
  • scheduler: 234个错误
  • auth: 88个错误

按错误类型

  1. 数据库错误: 1,234 (52.6%)
  2. 验证错误: 567 (24.2%)
  3. 速率限制错误: 345 (14.7%)
  4. 认证错误: 199 (8.5%)

性能指标

响应时间

端点 平均 P50 P95 P99 最大
/api/users 123ms 95ms 230ms 450ms 890ms
/api/search 2,300ms 1,800ms 4,500ms 6,200ms 8,900ms
/api/posts 156ms 120ms 280ms 520ms 780ms
/api/health 5ms 4ms 8ms 12ms 25ms

流量模式

  • 峰值: 09:15:00 (1,234 请求/分钟)
  • 平均: 410 请求/分钟
  • 安静时段: 02:00-05:00 (45 请求/分钟)

用户活动

按请求计数的前用户

  1. 用户ID 12345: 2,345个请求
  2. 用户ID 67890: 1,890个请求
  3. 用户ID 11111: 1,456个请求

失败的认证尝试

  • 总计: 199
  • 唯一用户: 45
  • 可疑模式: 用户 99999 (23次失败尝试)

推荐

立即行动（今天）

  1. ✓ 增加数据库连接池
  2. ✓ 调查工作服务内存泄漏
  3. ✓ 阻止可疑IP (192.168.1.100)
  4. ✓ 添加连接池监控

短期（本周）

  1. 优化搜索查询
  2. 实施查询结果缓存
  3. 审查事件监听器清理
  4. 为数据库添加断路器
  5. 增加认证用户的速率限制

长期（本月）

  1. 将搜索迁移到Elasticsearch
  2. 实施全面APM
  3. 添加自动化日志分析
  4. 设置预测性警报
  5. 改进错误处理和日志记录

日志记录改进

缺失信息

  • 请求ID（用于追踪）
  • 某些服务中的用户上下文
  • 工作日志中的性能指标
  • 结构化错误代码

建议日志格式

{
  "timestamp": "2024-01-15T10:30:00.000Z",
  "level": "error",
  "requestId": "req-abc-123",
  "service": "api",
  "userId": "12345",
  "endpoint": "/api/users",
  "method": "GET",
  "statusCode": 500,
  "duration": 234,
  "error": {
    "code": "DB_CONNECTION_ERROR",
    "message": "数据库连接失败",
    "stack": "..."
  }
}

监控警报设置

  1. 数据库连接错误 > 10/分钟
  2. 响应时间P95 > 500ms
  3. 错误率 > 2%
  4. 内存使用 > 80%
  5. 速率限制命中 > 100/小时从单个IP

分析技术

正则表达式模式

# 查找所有错误
grep -E "ERROR|Exception|Failed" app.log

# 提取时间戳和错误
grep "ERROR" app.log | awk '{print $1, $2, $4}'

# 计数错误类型
grep "ERROR" app.log | cut -d':' -f2 | sort | uniq -c | sort -nr

# 查找慢请求
awk '$7 > 1000 {print $0}' access.log  # 响应时间 > 1秒

基于时间的分析

# 每小时错误
awk '{print $1" "$2}' app.log | cut -d':' -f1 | uniq -c

# 峰值错误时间
grep "ERROR" app.log | cut -d' ' -f2 | cut -d':' -f1 | sort | uniq -c | sort -nr

工具集成

  • Elasticsearch + Kibana: 集中式日志记录和可视化
  • Splunk: 企业日志管理
  • Datadog: APM和日志分析
  • CloudWatch: AWS日志聚合
  • Grafana Loki: 开源日志聚合
  • Papertrail: 简单日志管理

注释

  • 始终考虑日志量和保留
  • 实施日志轮换和归档
  • 使用结构化日志记录（JSON）以便解析
  • 包含请求ID用于分布式追踪
  • 设置关键错误模式的警报
  • 定期日志分析防止事件
  • 与指标相关性提供更好见解