3. 日志采集层:Filelog Receiver 配置详解

在 OpenTelemetry Collector 的日志采集架构中,Filelog Receiver 是负责从文件系统读取日志数据的核心组件。它支持从容器标准输出(stdout/stderr)和普通日志文件尾部实时采集,是云原生日志平台的第一道入口。

3.1 Filelog Receiver 工作原理

Filelog Receiver 基于 opentelemetry-log-collection 库实现,采用“文件指纹 + 偏移量”机制确保日志不重不漏。其核心流程如下:

  1. 文件发现:通过 glob 模式匹配日志文件路径,支持动态发现新文件。
  2. 指纹识别:读取文件头部内容生成唯一指纹,用于区分文件重命名或轮转。
  3. 偏移量管理:记录当前读取位置(offset),支持持久化到文件,重启后断点续采。
  4. 多行聚合:支持根据正则表达式合并多行日志(如 Java 异常栈)。
  5. 日志解析:将原始文本转换为结构化日志记录,添加时间戳、文件路径等元数据。
关键特性:Filelog Receiver 不依赖任何外部 Agent,完全由 Collector 进程管理,适合作为 Sidecar 或 DaemonSet 部署在 Kubernetes 集群中。
Filelog Receiver 内部处理流程 Filelog Receiver 内部处理流程 文件发现 指纹识别 偏移量管理 多行聚合 日志解析 输出到 Pipeline 说明:偏移量持久化到文件(如 file_storage 扩展),确保 Collector 重启后不丢失读取位置。

3.2 容器标准输出日志采集

在 Kubernetes 环境中,容器标准输出日志由容器运行时写入宿主机的特定路径。Filelog Receiver 通过读取这些文件实现采集。

3.2.1 标准输出日志路径

容器运行时 日志路径模式 说明
Docker /var/lib/docker/containers/<container_id>/*.log JSON 格式,每行一条日志
containerd /var/log/pods/<namespace>_<pod_name>_<pod_uid>/<container_name>/0.log CRI 格式,包含 stream 字段
CRI-O /var/log/pods/<namespace>_<pod_name>_<pod_uid>/<container_name>/*.log 与 containerd 类似

3.2.2 配置示例

receivers:
  filelog/stdout:
    include:
      - /var/log/pods/*/*/*.log
    exclude:
      - /var/log/pods/kube-system/*/*.log
    start_at: beginning
    include_file_name: false
    include_file_path: true
    operators:
      - type: container
        id: container-parser
      - type: regex_parser
        id: cri-parser
        regex: '^(?P<time>\S+) (?P<stream>stdout|stderr) (?P<log>.*)$'
        timestamp:
          parse_from: attributes.time
          layout: '%Y-%m-%dT%H:%M:%S.%L%z'
        severity:
          parse_from: attributes.stream
          mapping:
            error: stderr
            info: stdout
最佳实践:使用 operators 中的 container 类型自动解析 CRI 格式日志,提取 stream 字段映射日志级别。建议排除 kube-system 命名空间以减少系统日志干扰。

3.3 文件尾部日志采集

对于应用写入固定路径的日志文件(如 /var/log/app/*.log),Filelog Receiver 支持从文件尾部实时跟踪新写入内容。

3.3.1 配置示例

receivers:
  filelog/app:
    include:
      - /var/log/app/*.log
    exclude:
      - /var/log/app/*.gz
    start_at: end
    poll_interval: 200ms
    max_log_size: 10MiB
    encoding: utf-8
    operators:
      - type: regex_parser
        id: app-parser
        regex: '^(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d{3}) \[(?P<level>\w+)\] (?P<message>.*)$'
        timestamp:
          parse_from: attributes.timestamp
          layout: '%Y-%m-%d %H:%M:%S,%L'
        severity:
          parse_from: attributes.level
          mapping:
            error: error
            warn: warn
            info: info
            debug: debug

3.4 关键参数对比

参数 默认值 说明 推荐场景
start_at end 从文件开头或尾部开始读取 新文件用 beginning,已有文件用 end
poll_interval 200ms 轮询文件变更的间隔 高吞吐场景可降至 50ms
max_log_size 10MiB 单条日志最大长度,超长截断 根据业务日志最大行调整
encoding utf-8 文件编码格式 中文日志建议保持 utf-8
fingerprint_size 1KiB 用于文件识别的头部字节数 日志文件头部固定时保持默认
multiline.line_start_pattern 空 多行日志起始行正则 Java 异常栈、SQL 多行语句

3.5 多行日志聚合配置

对于跨多行的日志(如 Java 异常栈、Python traceback),需要配置多行聚合规则,避免将一条日志拆分为多条记录。

receivers:
  filelog/java:
    include:
      - /var/log/app/java-app.log
    start_at: beginning
    operators:
      - type: regex_parser
        id: multiline
        multiline:
          line_start_pattern: '^\d{4}-\d{2}-\d{2}'
        regex: '^(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2},\d{3}) (?P<level>\w+) (?P<logger>\S+) (?P<message>[\s\S]*)'
注意:多行聚合的正则表达式必须精确匹配日志行的起始特征。如果匹配过于宽泛,可能导致大量日志被错误合并;如果过于严格,则无法正确聚合。建议先在测试环境验证正则效果。

3.6 文件轮转处理机制

Filelog Receiver 通过指纹和 inode 双重机制处理日志文件轮转(log rotation):

  • 重命名轮转:文件被重命名(如 app.log → app.log.1),Receiver 通过指纹识别继续读取原文件内容,同时发现新创建的 app.log 并开始跟踪。
  • 复制截断轮转:文件被复制后清空(如 logrotate copytruncate),Receiver 检测到文件大小减小或 inode 变化,重新从头部读取。
  • 删除重建轮转:旧文件被删除,新文件创建,Receiver 自动切换到新文件。
文件轮转处理流程 文件轮转处理流程 初始:app.log 轮转触发 重命名:app.log.1 创建新 app.log 继续读取旧文件 跟踪新文件 指纹 + inode 双重校验确保轮转过程中日志不丢失、不重复。

3.7 性能与可靠性建议

场景 建议 说明
高吞吐日志 增加 poll_interval 到 50ms,启用 max_concurrent_files 减少轮询延迟,提升采集吞吐
大量小文件 使用 include 精确匹配,避免 glob 过度泛化 减少文件发现开销
日志丢失敏感 设置 start_at: beginning,启用持久化偏移量 确保重启后从断点续采
磁盘 I/O 敏感 增大 poll_interval 到 500ms,使用 read_buffer_size 降低磁盘读取频率
生产部署要点:Filelog Receiver 建议与 file_storage 扩展配合使用,将偏移量持久化到 PVC 或 hostPath 卷中。同时,通过 memory_limiter 处理器控制内存使用,避免日志突增导致 OOM。