日志采集基础：日志格式标准与日志源分类

在云原生环境中，日志采集是链路的第一环，也是最容易出错的环节。理解日志的格式标准与日志源分类，是构建可靠日志平台的前提。本节将系统梳理这两大基础概念，并给出生产环境中的选型建议。

一、日志格式标准

日志格式决定了采集端如何解析、传输，以及存储端如何索引与检索。主流格式包括以下三种：

1. JSON 格式

JSON 日志是云原生应用的首选格式。每个日志条目是一个独立的 JSON 对象，包含时间戳、级别、消息体、上下文字段等。示例：

{
  "timestamp": "2025-03-21T10:15:30.123Z",
  "level": "ERROR",
  "logger": "com.example.order.Service",
  "message": "订单支付超时",
  "orderId": "ORD-20250321-001",
  "durationMs": 5023,
  "stackTrace": "java.lang.Exception: 支付超时\n\tat ..."
}

2. Syslog 格式

Syslog 是历史最悠久的日志协议之一，在 Linux 系统和网络设备中广泛使用。RFC 5424 格式包含 PRI（优先级）、版本、时间戳、主机名、应用名、进程 ID、消息 ID 和结构化数据。采集时通常需要正则解析：

<34>1 2025-03-21T10:15:30.123Z myhost myapp 1234 ID47 - [exampleSDID@32473 iut="3" eventSource="Application"] 用户登录失败

3. 多行日志

多行日志是采集中的难点。典型的 Java 异常堆栈跨越多行，采集器必须能识别起始行并合并后续行。常见的合并策略：

• 时间戳匹配：以 ISO 8601 时间戳开头的行为新日志条目起始。
• 正则匹配：以特定模式（如 ^ERROR、^Exception）触发合并。
• 行数限制：设置最大合并行数（如 100 行），防止内存溢出。

二、日志源分类

云原生环境中的日志源主要分为三大类：容器标准输出、文件日志和事件日志。每种日志源的采集方式、生命周期和典型场景均有差异。

1. 容器标准输出

Kubernetes 中最常见的日志源。容器将日志写入 stdout/stderr，容器运行时（Docker/Containerd）将其重定向到宿主机上的 JSON 文件（通常位于 /var/log/containers/）。采集器通过读取这些文件实现日志采集。

• 优点：无需修改应用代码，零侵入。
• 缺点：日志随容器销毁而丢失；无法控制日志格式（依赖应用输出）。
• 最佳实践：应用输出 JSON 格式到 stdout，并配置合理的日志轮转策略。

2. 文件日志

对于需要持久化或复杂日志管理的场景，应用直接写入文件。文件日志支持更精细的轮转策略（按大小、按时间）、压缩归档和权限控制。采集时需注意：

• 文件轮转：当日志文件被重命名或删除时，采集器需能跟踪新文件（如通过 inode 或文件路径模式）。
• 多行日志：文件日志中多行日志更常见，需配置合并规则。
• 挂载卷：在 Kubernetes 中，通常通过 emptyDir 或 hostPath 挂载日志目录。

3. 事件日志

事件日志是系统或平台产生的离散事件，而非连续流。典型事件包括：

• Kubernetes Events：Pod 创建、调度失败、节点异常等。
• 系统 Auditd：用户登录、文件访问、系统调用等安全事件。
• Docker Events：容器启动、停止、删除等。

事件日志通常通过 API 拉取或 Webhook 推送方式采集，而非文件 tail。采集后需进行去重和幂等处理，避免重复记录。

三、生产环境选型建议

结合日志格式与日志源，以下给出典型场景的选型矩阵：