Wazuh Logcollector 日志采集器详解:六种 log_format 的配置与底层实现
发布时间:2026/9/14 15:55:55 作者:尧图编辑部 阅读量:1,286

Wazuh Logcollector 日志采集器详解六种 log_format 的配置与底层实现【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuhLogcollector 是 Wazuh Agent 侧的日志采集引擎负责从受监控端点的不同日志源读取事件并转发给 Manager 进行分析。本文以 docs/ref/modules/logcollector/collectors.md 为核心逐一对比syslog、json、eventchannel、eventlog、macos、journald六种日志采集器的适用平台、配置写法和行为差异并结合src/logcollector/下的源码印证其实现机制帮助你在跨平台部署时正确选型并排查采集问题。日志采集器总览每个日志源通过ossec.conf中的一个localfile块声明其中log_format决定使用哪一个采集器。六种采集器的平台适用性如下Format操作系统说明syslogLinux、macOS、Windows纯文本日志文件每行一个事件jsonLinux、macOS、WindowsJSON 编码日志文件每行一个对象eventchannelWindows基于 EventChannel API 的 Windows 事件日志Vista 及以上eventlogWindows基于OpenEventLog/ReadEventLogAPI 的 Windows 事件日志macosmacOSmacOS 统一日志系统ULSjournaldLinuxsystemd journal从源码结构看每种格式在 src/logcollector/src/ 下都有独立的读取实现read_syslog.c、read_json.c、read_win_event_channel.c、read_win_el.c、read_macos.c、read_journald.c它们在 src/logcollector/src/logcollector.c 中按log_format分发到对应的读取函数。例如在 src/logcollector/src/logcollector.c 中当格式为eventchannel但当前 Windows 版本不支持该 API 时Logcollector 会打印警告eventchannel not available on this version of Windows并跳过该采集器这就是旧版 Windows 上必须回退到eventlog的原因。完整的配置项参考包括socket段与logcollector.*内部选项见 配置参考。syslog — 纯文本文件采集syslog是最通用的格式逐行读取纯文本日志文件是大多数 Linux/macOS 日志文件的标准格式localfile location/var/log/auth.log/location log_formatsyslog/log_format /localfilelocation字段支持三类写法静态路径如/var/log/auth.log基于日期的模式使用strftime格式如/var/log/application-%y-%m-%d.log会匹配application-26-07-03.log这类按天滚动的文件通配符模式如/var/log/app*.log可配合exclude正则与age时间间隔如7d缩小扫描范围localfile location/var/log/app*.log/location log_formatsyslog/log_format exclude\.old$/exclude age7d/age /localfileWindows 平台还允许在路径中使用环境变量例如%WINDIR%\System32\LogFiles\Firewall\pfirewall.log。json — JSON 日志文件采集json采集器同样逐行读取但要求每一行都是一个合法的 JSON 对象解析失败的行会被静默丢弃。若配置了labels标签会在事件转发前被注入到每个 JSON 对象中localfile location/var/log/app.json/location log_formatjson/log_format labels label keyappmyapp/label label keyenvironmentproduction/label /labels /localfile对非 JSON 格式labels则以元数据方式附加到日志事件中。这一行为对应 src/logcollector/src/read_json.c 中对逐行 JSON 解析的实现意味着生产环境中若混入非法 JSON 行不会导致采集中断但那些行不会出现在告警数据中——排查日志丢失时应先确认该特性。eventchannel — Windows 事件通道采集eventchannel采集器使用 Windows EventChannel APIEvtSubscribe/EvtRender订阅事件通道适用于 Windows Vista 及以后版本。默认监控System、Application、Security三个通道Windows 暴露的任何自定义通道都可以添加localfile locationSecurity/location log_formateventchannel/log_format /localfile事件可以用 XPath 查询通过query元素过滤localfile locationSystem/location log_formateventchannel/log_format queryEvent/System[EventID7040]/query /localfile也支持完整的 QueryList XML 格式例如只采集错误与严重级别Level ≤ 3的事件localfile locationSystem/location log_formateventchannel/log_format query QueryList Query Id0 PathSystem Select PathSystem*[System[(Levellt;3)]]/Select /Query /QueryList /query /localfile事件输出格式Wazuh 5.0 的重大变更Wazuh 4.x中Agent 将每个事件包装为包含人类可读消息与原始 XML 的 JSON 对象{Message: Event description., Event: Event.../Event}Wazuh 5.0起Agent 直接转发EvtRender()返回的原生 Windows 事件 XML与 Windows 事件查看器的导出格式一致Event xmlnshttp://schemas.microsoft.com/win/2004/08/events/event System Provider NameMicrosoft-Windows-Security-Auditing Guid{54849625-5478-4994-a5ba-3e3b0328c30d}/ EventID4624/EventID ChannelSecurity/Channel ComputerHOST/Computer Security/ /System EventData Data NameSubjectUserNameSYSTEM/Data Data NameLogonType5/Data ... /EventData /Event与旧格式的关键差异不再带有?xml version1.0 encodingUTF-8?声明根元素直接是Event命名空间与属性由 EventChannel API 原样保留。这一点在源码中可以得到印证src/logcollector/src/read_win_event_channel.c 通过EvtRender(..., EvtRenderEventXml, ...)两次调用先取缓冲区大小再渲染得到事件 XML 原文后直接下发而 src/logcollector/src/read_win_event_channel.c 中通过EvtSubscribeToFutureEvents/EvtSubscribeStartAfterBookmark标志控制是否只订阅未来事件——这正对应配置项only-future-events默认yes设为no时处理通道中全部历史事件。注意该输出格式变更仅影响 Windows Agentlog_formateventchannel/log_format配置写法不变。若下游有依赖 4.x 包装格式的解码器或规则需要在 5.0 上核对兼容性。eventlog — Windows 传统事件日志采集eventlog采集器使用传统的OpenEventLog/ReadEventLogAPI兼容所有 Windows 版本覆盖Application、Security、System三个日志localfile locationApplication/location log_formateventlog/log_format /localfile建议在 Windows Vista 及以上系统上优先使用eventchannel它能访问更多通道且事件元数据更丰富eventlog主要作为旧系统的兜底方案。其实现位于 src/logcollector/src/read_win_el.c。macos — macOS 统一日志系统ULSmacos采集器通过logCLI 从 macOS Unified Logging System 采集事件每个 Agent 只允许一个log_format为macos的localfile块这一点在 src/config/src/localfile-config.c 的 journald/macOS 配置校验中体现为严格的格式互斥检查localfile locationmacos/location log_formatmacos/log_format query typelog,trace levelinfoprocess sshd/query /localfilequery元素说明type属性逗号分隔的日志条目类型列表取值为activity、log、tracelevel属性最低日志级别取值为default、info、debug查询主体为 predicate 表达式可使用process、subsystem、category、message等字段。采集 macOS 认证相关事件的完整示例localfile locationmacos/location log_formatmacos/log_format query typetrace,log,activity levelinfo (process sudo) or (process sessionlogoutd and message contains logout is complete.) or (process sshd) /query /localfile按子系统过滤localfile locationmacos/location log_formatmacos/log_format query typelog levelinfo (subsystem com.apple.securityd) or (subsystem com.apple.opendirectoryd) /query /localfile实现上src/logcollector/src/read_macos.c 与 src/logcollector/src/macos_log.c 负责维护log show/log stream子进程流type属性会在配置解析阶段被w_logcollector_get_macos_log_type()见 src/config/src/localfile-config.c翻译成对应的日志类型标志。macOS 下读取 ULS 还需要授予 Agent完整磁盘访问权限否则采集会静默失败。journald — systemd journal 采集journald采集器读取 Linux 上的 systemd journal 条目支持通过filter元素按 journal 字段过滤。过滤值按PCRE2 正则表达式编译精确匹配需使用锚点^、$localfile locationjournald/location log_formatjournald/log_format filter fieldSYSLOG_IDENTIFIER^sshd$/filter /localfile可以用多个filter组合条件。从源码结构看过滤条件在配置解析阶段由 src/config/src/localfile-config.c 的journald_add_condition_to_filter()逐个加入过滤器数组而 src/logcollector/src/read_journald.c 维护全局 journal 上下文它检测 journal 文件轮转w_journal_rotation_detected、按过滤器获取最新条目w_journal_context_next_newest_filtered并以 syslog 风格 dump 条目内容。此外 src/config/src/localfile-config.c 中的w_logreader_journald_merge()表明多个 journald 配置块会被合并处理这与每 Agent 仅一个 ULS/journal 数据源的设计相呼应。典型用法——监控 SSH 认证localfile locationjournald/location log_formatjournald/log_format filter fieldSYSLOG_IDENTIFIER^sshd$/filter /localfile监控 Docker 容器日志按容器名localfile locationjournald/location log_formatjournald/log_format filter fieldCONTAINER_NAME^my-container$/filter /localfile监控全部通过 journal 传输的 Docker 日志localfile locationjournald/location log_formatjournald/log_format filter field_TRANSPORT^journal$/filter /localfile关键行为差异与排查要点Windows 通道订阅时机only-future-events默认yes即 Agent 启动后只采集新事件。需要回补历史事件时显式设置为nolocalfile locationSecurity/location log_formateventchannel/log_format only-future-eventsno/only-future-events /localfilejson 的静默丢行非法 JSON 行不会报错、不会转发排查事件缺失时先人工校验每行是否为合法 JSON 对象。journald 过滤是正则而非子串匹配过滤值按 PCRE2 编译写sshd会匹配所有包含sshd的SYSLOG_IDENTIFIER精确匹配请写^sshd$。macOS 单实例限制与权限只允许一个macos采集块采集失败时先确认 Agent 拥有完整磁盘访问权限并可用log show --predicate process sshd --info手动验证 predicate 语法。状态与调试查看采集状态文件/var/ossec/var/run/wazuh-logcollector.stateWindows 下为C:\Program Files (x86)\ossec-agent\wazuh-logcollector.state可了解当前活跃日志源在/var/ossec/etc/local_internal_options.conf中临时加入logcollector.debug2并重启 Agent 可获得完整调试输出便于定位事件未转发类问题。性能与吞吐调优高日志量场景可通过内部选项调优如logcollector.input_threads8、logcollector.queue_size4096、logcollector.max_lines50000文件数量多时相应调大logcollector.max_files与logcollector.rlimit_nofile后者必须高于前者。全部logcollector.*选项的取值范围与默认值见 配置参考。参考Log Collector 格式说明Logcollector 完整配置参考Logcollector 模块概述源码src/logcollector/src/logcollector.c、src/logcollector/src/read_win_event_channel.c、src/logcollector/src/read_journald.c、src/config/src/localfile-config.c【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考