当前位置:首页 >专题 >OpenTelemetry File Log Receiver 日志采集可靠性工程专题
OpenTelemetry File Log Receiver 日志采集可靠性工程专题
官方入口、组件文档与 SDK
先建立 receiver、operator、storage 和日志信号的边界
OpenTelemetry File Log Receiver 官方文档
File Log Receiver 的配置、组件状态与实现入口。
File Log Receiver Operators 官方文档
Stanza operators 的解析、路由、multiline 与字段映射文档。
OpenTelemetry Collector Storage Extension
Collector 持久化队列、重启恢复与可靠性配置官方入口。
File Log Receiver 官方配置示例
包含 include、exclude、start_at、encoding、operators 和 storage 的配置示例。
OpenTelemetry Logs 数据模型规范
定义 LogRecord、Body、Attributes、Resource 与时间字段。
OpenTelemetry Go 官方文档与 API/SDK
Go 语言 API、SDK、日志、指标与链路官方入口。
OpenTelemetry Collector Contrib Releases
核对 File Log Receiver、Stanza 和 storage 相关版本变更。
File Log receiver protobuf checkpoint 更新
官方说明 File Log receiver 使用 protobuf checkpoint 的动机和收益。
File Log Receiver 常见问题
围绕 checkpoint、轮转、重复、权限和性能做上线判断
File Log Receiver 重启后会不会重复采集?
是否重复取决于 checkpoint 持久化位置、文件身份识别和写入时机。应启用受支持的 storage 配置,演练正常退出、强杀和断电恢复,并用唯一事件 ID 对输入输出做差异核对。
日志轮转用 rename 还是 copytruncate?
优先使用能保留文件身份和写入语义清晰的 rename 方案;copytruncate 可能在复制与截断之间产生竞态,必须结合采集器 inode、offset 和应用写入方式做压测,不可只看文件名。
解析失败的日志应该丢弃还是进入死信?
生产上不应静默丢弃。应保留原始 body、错误原因和源文件元数据,路由到隔离文件或专用 exporter,并设置失败率告警;修复 parser 后再回放,而不是盲目重启采集器。
File Log Receiver 如何验证没有漏采?
用带单调序号或事件 ID 的固定日志样本覆盖启动、追加、轮转、重启、权限变化和磁盘压力,比较源文件、checkpoint、Collector 输出和下游落库四端数量,分别统计丢失、重复和延迟。
相关专题
继续查看相近方向内容
-
- Go SQLX 怎样把多个结果行扫描成字符串切片
- 2小时前 169浏览
-
- 手机壁纸提示词:奶油色石膏洞穴映着浅蓝天光
- 2小时前 119浏览
-
- 手机壁纸提示词:雨滴压弯的透明水晶麦穗
- 2小时前 269浏览
-
- 手机壁纸提示词:绒面橄榄绿波浪托起乳白月牙
- 2小时前 367浏览
-
- 手机壁纸提示词:浮石小岛上弯曲的白色蒲草
- 2小时前 328浏览
-
- 手机壁纸提示词:纸浆山谷里流淌的银灰色细河
- 2小时前 101浏览
-
- 手机壁纸提示词:薄荷冰雾包围的珊瑚粉贝塔
- 2小时前 258浏览
-
- 手机壁纸提示词:靛蓝陶土裂缝间的细金色光
- 2小时前 260浏览

