2、结构化日志基础：什么是结构化日志？对比非结构化日志的优劣，常见格式(JSON/Logfmt)

2.1 什么是结构化日志？

结构化日志（Structured Logging）是指将日志记录为键值对（Key-Value Pairs）或字段化数据的实践。每条日志不再是自由文本字符串，而是一个具有明确字段名和字段值的结构化记录。机器可以无需正则表达式即可直接解析、索引和查询这些字段。

与之相对的是非结构化日志（Unstructured Logging），即传统的纯文本日志，通常由字符串拼接而成，依赖人工阅读或复杂的正则表达式提取信息。

2.2 结构化日志 vs 非结构化日志：优劣对比

2.3 常见结构化日志格式

2.3.1 JSON 格式

JSON（JavaScript Object Notation）是目前最广泛使用的结构化日志格式。它天然支持嵌套结构、数组和多种数据类型。

{
  "timestamp": "2025-03-15T10:30:45.123Z",
  "level": "ERROR",
  "service": "order-service",
  "trace_id": "abc123def456",
  "span_id": "span-001",
  "message": "数据库连接超时",
  "error": {
    "code": "DB_TIMEOUT",
    "retry_count": 3,
    "duration_ms": 5023
  },
  "metadata": {
    "host": "pod-7x9k2",
    "region": "us-east-1"
  }
}

优点：人类可读、工具支持最广、支持嵌套结构。
缺点：体积较大（字段名重复）、解析性能略低于二进制格式。

2.3.2 Logfmt 格式

Logfmt 是一种轻量级键值对格式，起源于 Heroku 的日志规范。它使用空格分隔键值对，键值之间用等号连接，字符串值通常不加引号。

timestamp=2025-03-15T10:30:45.123Z level=ERROR service=order-service trace_id=abc123def456 span_id=span-001 msg="数据库连接超时" error_code=DB_TIMEOUT retry_count=3 duration_ms=5023 host=pod-7x9k2 region=us-east-1

优点：体积小、人类可读性好、适合命令行管道处理。
缺点：不支持嵌套结构、值类型需约定（所有值均为字符串）、工具生态不如 JSON 丰富。

2.4 格式对比总结

2.5 结构化日志的核心字段设计

无论选择哪种格式，SRE 团队应统一以下必选字段，确保跨服务可关联：

• timestamp：ISO 8601 格式，精确到毫秒或微秒
• level：日志级别（DEBUG / INFO / WARN / ERROR / FATAL）
• service：服务名称（如 order-service）
• trace_id：分布式追踪 ID（用于跨服务关联）
• span_id：当前调用跨度 ID
• message：人类可读的描述信息
• error：错误详情（可选，但 ERROR 级别必须包含）

2.6 结构化日志处理流程（SVG 图）

2.7 实战建议：从非结构化迁移到结构化

1. 统一日志库：在团队内选择同一日志库（如 logrus、zap、slog），强制输出结构化格式。
2. 定义字段标准：制定团队级字段命名规范（如 snake_case 或 camelCase），避免字段名混乱。
3. 逐步替换：先改造核心服务（如网关、订单服务），再推广到边缘服务。
4. 验证可查询性：在日志平台中测试字段过滤、聚合、告警规则，确保结构化日志真正可用。
5. 监控日志质量：定期检查是否有服务仍输出纯文本日志，使用自动化工具（如 logcheck）拦截非结构化输出。