log-analysis-parsing

日志分析与解析

使用正则表达式模式、解析引擎、日志分析工具和数据处理技术，解析、分析、搜索、筛选日志数据并从中提取洞见，将原始日志转化为可执行的信息。

何时使用我

使用此技能的场景：

• 需要从非结构化日志文件中提取特定信息
• 为可观测性平台构建日志解析流水线
• 在大量日志中搜索特定模式或错误
• 根据日志内容创建仪表板和告警
• 分析日志数据以调查安全事件或性能问题
• 将旧版文本日志转换为结构化格式
• 构建自定义日志分析工具或脚本
• 调试需要关联多个日志源的复杂问题
• 对历史日志数据进行取证分析

我能做什么

1. 日志解析技术

• 正则表达式模式匹配：从非结构化日志中提取结构化数据
• Grok 模式解析：使用命名捕获组和可复用模式
• JSON 解析：解析已有的结构化日志格式
• 键值对提取：从分隔格式的日志中提取键值对
• 多行日志处理：处理堆栈跟踪和异常详情
• 时间戳解析：解析各种日期和时间格式
• 日志格式推断：推断未知日志格式

2. 日志分析方法

• 模式识别：识别常见日志消息类型
• 异常检测：检测异常日志模式或数量
• 趋势分析：分析日志量、错误率和性能指标
• 关联分析：关联多个日志源中的信息
• 序列分析：理解事件流程
• 统计分析：分析日志属性和指标
• 机器学习方法：对日志进行分类和预测

3. 搜索与筛选操作

• 全文搜索：搜索日志消息和字段
• 字段专属查询：查询结构化日志数据
• 布尔运算（AND、OR、NOT）：构建复杂查询
• 时间范围筛选：进行时间分析
• 正则表达式搜索：匹配特定模式
• 模糊搜索：进行近似匹配
• 已保存的搜索和查询模板：重复执行分析

4. 洞见提取

• 根据日志模式计算错误率
• 提取性能指标（延迟、耗时、吞吐量）
• 根据应用程序日志分析用户行为
• 根据访问日志和审计日志检测安全事件
• 根据事务日志推导业务指标
• 根据基础设施日志提取系统健康指标
• 根据服务交互日志评估依赖项健康状况

5. 可视化与报告

• 用于展示日志量和错误率的时间序列图表
• 用于展示模式频率的热力图
• 用于展示最常见错误或用户的 Top-N 列表
• 用于展示性能指标的分布图表
• 用于展示相关事件的相关矩阵
• 用于实时监控的告警仪表板
• 支持导出到外部分析工具

解析模式

常见日志格式

Apache/Nginx 访问日志

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

解析模式：

^(?P<ip>\S+) \S+ (?P<user>\S+) \[(?P<timestamp>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) (?P<protocol>\S+)" (?P<status>\d+) (?P<size>\d+)

JSON 日志（结构化）

{
  "timestamp": "2026-02-26T18:00:00Z",
  "level": "ERROR",
  "service": "api-service",
  "message": "Database connection failed",
  "error": {
    "code": "DB_CONN_001",
    "message": "Connection timeout"
  }
}

**解析方法：**直接解析 JSON 并提取字段

键值日志

timestamp=2026-02-26T18:00:00Z level=ERROR service=api-service message="Database connection failed" error_code=DB_CONN_001

解析模式：

(\w+)=("[^"]*"|\S+)

多行堆栈跟踪

ERROR 2026-02-26 18:00:00 - Database connection failed
java.sql.SQLException: Connection timeout
    at com.example.Database.connect(Database.java:123)
    at com.example.Service.process(Service.java:456)
    ...

**解析方法：**将第一行作为标头捕获，将后续行作为 stack_trace 字段

Grok 模式

Grok 提供可复用的命名正则表达式模式，用于匹配常见日志组件。

常见 Grok 模式：

• %{TIMESTAMP_ISO8601:timestamp}
• %{IP:client_ip}
• %{WORD:http_method}
• %{URIPATHPARAM:request_path}
• %{NUMBER:response_status}
• %{NUMBER:response_size}
• %{GREEDYDATA:message}

Apache 日志的 Grok 模式示例：

%{IP:client_ip} %{USER:ident} %{USER:auth} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{URIPATHPARAM:request} HTTP/%{NUMBER:http_version}" %{NUMBER:response_status} %{NUMBER:bytes_sent}

分析技术

模式频率分析

识别最常见的日志消息、错误类型或用户操作。

分析示例：

Top 5 Error Messages (last 24 hours):
1. "Database connection timeout" (1,234 occurrences)
2. "Invalid API key" (987 occurrences)
3. "Rate limit exceeded" (654 occurrences)
4. "File not found" (543 occurrences)
5. "Memory allocation failed" (432 occurrences)

时间序列分析

跟踪指标随时间的变化，以识别趋势和异常。

要跟踪的指标：

• 每分钟／每小时／每天的日志量
• 错误率占日志总量的百分比
• 根据访问日志计算的平均响应时间
• 使用高峰时段和模式
• 季节性趋势（每天、每周、每月）

关联分析

关联不同日志来源中的相关事件。

关联示例：

• 将应用程序错误与基础设施警报关联起来
• 将用户操作与性能下降关联起来
• 关联多个系统中的安全事件
• 跟踪请求在微服务中的流转

异常检测

识别可能表明存在问题的异常模式。

异常类型：

• 错误率突然上升
• 异常的访问模式
• 意外的服务交互
• 异常的资源使用模式
• 地理位置访问异常

示例

# Parse Apache access logs and extract statistics
npm run log-analysis:parse -- --format apache --file access.log --output stats.json

# Search for error patterns in application logs
npm run log-analysis:search -- --pattern "ERROR.*timeout" --files "app*.log" --time-range "last-24h"

# Analyze log trends over time
npm run log-analysis:trends -- --metric "error_rate" --window "7d" --granularity "1h"

# Create parsing pipeline for custom log format
npm run log-analysis:pipeline -- --input-format "custom" --output-format "json" --mapping mapping.yaml

# Perform correlation analysis across log sources
npm run log-analysis:correlate -- --sources "app.log,nginx.log,db.log" --time-window "5m"

输出格式

解析配置：

parsing:
  format: "apache_access"
  pattern: '^(?P<ip>\S+) \S+ (?P<user>\S+) \[(?P<timestamp>[^\]]+)\] "(?P<method>\S+) (?P<path>\S+) (?P<protocol>\S+)" (?P<status>\d+) (?P<size>\d+)'
  timestamp_format: "%d/%b/%Y:%H:%M:%S %z"
  fields:
    - name: "ip"
      type: "string"
    - name: "timestamp"
      type: "datetime"
    - name: "method"
      type: "string"
    - name: "status"
      type: "integer"
    - name: "size"
      type: "integer"
  
  processing:
    - transform: "status >= 400 => error"
    - transform: "size > 1000000 => large_response"
    - enrich: "geoip(ip)"
    - enrich: "user_agent_parse(user_agent)"
  
  output:
    format: "json"
    include_fields: ["timestamp", "ip", "method", "path", "status", "size", "error"]

日志分析报告：

Log Analysis Report
───────────────────
Source: payment-service logs
Period: 2026-02-25 to 2026-02-26
Total logs analyzed: 1,234,567

Parsing Summary:
✅ Successfully parsed: 1,200,123 logs (97.2%)
⚠️  Partially parsed: 23,456 logs (1.9%)
❌ Failed to parse: 10,988 logs (0.9%)

Common Patterns Identified:
1. "Payment processed" (45,678 occurrences)
2. "Database query executed" (32,456 occurrences)
3. "API call to gateway" (28,901 occurrences)
4. "Validation error" (12,345 occurrences)
5. "Cache hit/miss" (9,876 occurrences)

Error Analysis:
- Total errors: 15,678 (1.27% error rate)
- Top error: "Payment gateway timeout" (4,567 occurrences)
- Error trend: Increasing over last 24 hours (+15%)
- Peak error time: 14:00-15:00 (1,234 errors/hour)

Performance Metrics:
- Average response time: 245ms
- 95th percentile: 567ms
- 99th percentile: 1,234ms
- Slowest endpoint: /api/v1/reports (avg 890ms)

Security Insights:
- Unusual access patterns detected: 12
- Failed authentication attempts: 456
- Suspicious user agents: 23
- Geographic anomalies: 5

Recommendations:
1. Investigate increasing error rate trend
2. Optimize /api/v1/reports endpoint performance
3. Review 12 unusual access patterns
4. Consider adding more context to validation errors
5. Implement parsing for currently failed logs

注意事项

• 解析性能很重要——低效的正则表达式会拖慢日志处理速度
• 妥善处理解析失败——不要因解析错误而丢失数据
• 在各个应用程序之间统一日志格式，以简化解析
• 考虑日志量——解析数百万条日志需要高效的算法
• 缓存解析结果，以便重复分析相同的日志
• 验证解析后的数据——确保提取的字段准确且一致
• 记录解析规则——尤其是自定义或复杂的日志格式
• 使用来自所有日志源和格式的样例数据测试解析
• 监控解析成功率——解析成功率突然下降时发出警报
• 为日志格式变更做好准备——为解析规则添加版本管理，并处理迁移