3. 日志采集层:Filelog Receiver 配置详解
在 OpenTelemetry Collector 的日志采集架构中,Filelog Receiver 是负责从文件系统读取日志数据的核心组件。它支持从容器标准输出(stdout/stderr)和普通日志文件尾部实时采集,是云原生日志平台的第一道入口。
3.1 Filelog Receiver 工作原理
Filelog Receiver 基于 opentelemetry-log-collection 库实现,采用“文件指纹 + 偏移量”机制确保日志不重不漏。其核心流程如下:
- 文件发现:通过 glob 模式匹配日志文件路径,支持动态发现新文件。
- 指纹识别:读取文件头部内容生成唯一指纹,用于区分文件重命名或轮转。
- 偏移量管理:记录当前读取位置(offset),支持持久化到文件,重启后断点续采。
- 多行聚合:支持根据正则表达式合并多行日志(如 Java 异常栈)。
- 日志解析:将原始文本转换为结构化日志记录,添加时间戳、文件路径等元数据。
关键特性:Filelog Receiver 不依赖任何外部 Agent,完全由 Collector 进程管理,适合作为 Sidecar 或 DaemonSet 部署在 Kubernetes 集群中。
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 自动切换到新文件。
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。