日志收集Agent选型与配置，是监控系统建设中最容易被低估的环节。许多团队在对比吞吐量、内存占用后选定工具，却在接入时发现应用日志与系统日志的采集逻辑完全不同，安全日志的合规要求也未纳入考虑。本文先明确边界，再给出可执行的选型与配置方案，帮助你避开常见误区。
先明确边界：应用日志与系统日志是两回事
日志收集Agent要处理的数据源大致分为两类：一类是操作系统、网络设备、Web服务器等基础设施产生的日志，通常以文本文件或syslog形式存在；另一类是应用自身通过日志库输出的日志，例如Python的logging模块。OWASP日志安全速查表指出，许多系统启用了网络设备、操作系统、Web服务器和数据库服务器的日志，但自定义应用事件日志常常缺失、未启用或配置不当——这恰恰是问题所在。
应用日志与基础设施日志的采集方式不同：应用日志往往需要嵌入代码或通过SDK输出结构化数据，而系统日志则更适合用轻量级Agent直接读取文件。选型前，先盘点你的日志源属于哪一类，再决定Agent的形态。
选型核心：现有生态与集成能力
日志收集Agent的选型不是看基准测试数字，而是看它能否融入你现有的技术栈。OpenTelemetry日志规范明确表示：为了在日志领域取得成功，需要支持现有日志和日志库的遗产，同时尽可能提供改进和与可观测性世界更好的集成。这意味着，如果团队已采用OpenTelemetry做追踪和指标，选择支持OpenTelemetry的Agent能减少割裂；反之，如果只是单纯收集Nginx访问日志，轻量级Agent如Filebeat可能更合适。
判断过程可以这样：列出你已有的日志产生方式（文件、syslog、Kafka、云服务），再列出目标存储（Elasticsearch、Loki、S3、自建数据库），然后检查Agent的输入输出插件是否覆盖这些路径。没有插件的Agent，再快也白搭。
主流Agent对比与选择建议
Filebeat：轻量采集，适合文件日志
Filebeat专为文件日志设计，资源占用低，配置简单。如果你的日志主要是Nginx访问日志、应用输出到文件的日志，且目标存储是Elasticsearch或Logstash，Filebeat是稳妥选择。它支持多行日志合并、字段处理，但扩展性不如Fluentd。
Fluentd/Fluent Bit：数据管道能力强
Fluentd和Fluent Bit适合需要复杂路由、过滤、缓冲的场景，插件生态丰富，能从Kafka、HTTP等源采集。Fluent Bit更轻量，适合边缘节点。若日志需要转发到多个目的地（如同时送Elasticsearch和S3），这类Agent优势明显。
Vector：高性能与可编程性
Vector采用Rust编写，性能高，配置使用TOML，支持单元测试。适合对吞吐量有极高要求、且需要复杂转换的场景。但社区相对较小，遇到问题时排查成本可能更高。
OpenTelemetry Collector：融入可观测性生态
OpenTelemetry Collector是官方推荐的日志采集组件，与OpenTelemetry的追踪、指标无缝衔接。它支持通过接收器（如filelog、otlp）接收日志，并通过处理器进行解析、过滤。如果团队已经使用OpenTelemetry，这是最自然的选择。但需注意，OpenTelemetry日志规范强调“拥抱现有日志解决方案”，因此它更适合作为统一可观测性数据入口，而非单纯的文件采集工具。
配置步骤：以Filebeat采集Nginx日志为例
以下配置步骤适用于大多数文件型日志Agent，以Filebeat为例：
- 安装Filebeat，确认版本与Elasticsearch兼容。
- 在filebeat.yml中定义输入：指定日志路径，如
/var/log/nginx/access.log，设置multiline规则处理堆栈信息。 - 配置输出：指向Elasticsearch或Logstash，设置索引模板。
- 启动并验证：
filebeat -e查看启动日志，确认无权限或路径错误。 - 检查数据是否到达：在Kibana中创建索引模式，确认字段正确解析。
失败条件很常见：路径权限不足导致Agent无法读取文件；日志格式不匹配导致解析失败；Agent版本与Elasticsearch版本不兼容。这些都可以通过查看Agent自身日志和Elasticsearch的索引映射来排查。
如果你管理多台服务器，建议结合Linux日志轮转logrotate配置，避免Agent读取已轮转的旧文件，造成重复或遗漏。相关实践可参考Linux日志轮转logrotate配置与磁盘占用排查指南。
安全日志的合规要求
安全事件日志必须纳入采集范围。OWASP日志安全速查表强调，应用日志应始终包含安全事件，并且日志记录应保持一致性、遵循行业标准，以便被各类系统消费、关联和分析。这意味着日志收集Agent需要支持结构化输出（如JSON）、时间戳标准化、以及敏感信息脱敏。
配置时注意：安全日志不能仅仅依赖Web服务器访问日志，必须包含认证失败、权限变更、异常请求等应用级事件。如果Agent不支持字段脱敏，应在采集端过滤或遮蔽敏感数据，避免日志泄露。
常见误区与取舍
- 盲目追求高性能：吞吐量不是唯一指标，Agent的稳定性、可维护性、插件生态更重要。
- 忽略日志规范：Python官方文档指出，日志系统需要配置才能发挥作用，且建议使用模块级logger实现分层记录。如果应用日志不规范，Agent再强也无济于事。
- 只采集不处理：日志采集只是第一步，后续的解析、关联、告警才是价值所在。选择Agent时考虑其与下游系统的集成。
- 忽视轮转与保留：磁盘占用是常见问题，参见Linux日志轮转logrotate配置与磁盘占用排查指南。
实时日志流式处理框架的对比与选型，可参考实时日志流式处理框架对比与选型。
配置后的验证与持续优化
配置完成后，不要直接上线。先在小流量环境验证：检查Agent的吞吐量、错误率、延迟，确保数据完整到达。使用测试日志模拟异常场景，确认Agent不会崩溃或丢失数据。定期审查Agent配置，随着日志量增长调整缓冲区和批量大小。
对于应用日志，建议采用结构化日志（如JSON），并统一字段命名，这样Agent的解析规则可以复用。Python的logging模块支持自定义Formatter，可实现JSON输出，但需注意性能影响，可在生产环境评估。
参考资料
延伸阅读