Wazuh Logging 模块配置详解log_format 参数与 daemon 日志 plain/JSON 双输出实现【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuhWazuh 的 Logging 模块通过一个顶层loggingXML 配置块控制 Manager 与 Agent 上所有 daemon的内部日志格式支持纯文本plain、结构化 JSON 以及两者同时输出plain,json三种模式。本文基于配置参考文档 configuration.md结合仓库中的默认配置文件与 C 语言源码实现debug_op.c完整讲解log_format参数的取值与校验规则、双输出机制、两种格式的真实输出样例以及日志写入底层的锁、文件截断与权限处理等实现细节。一、Logging 模块的定位与作用范围Logging 模块决定 Wazuh daemon 日志的格式与输出位置同时适用于 manager 和 agent 两端。其核心特性如下见 Logging 模块 READMEplain 文本格式人类可读便于排障与手工查看JSON 格式结构化输出便于接入日志聚合工具Elasticsearch、Splunk 等双输出同时产生两种格式兼顾支持排障与 SIEM 接入全局作用域从源码结构看所有 daemonremoted、analysisd、logcollector 等共用同一套日志实现因此该配置一次生效、全局生效。关键定位信息汇总项目ManagerAgent配置文件/var/wazuh-manager/etc/wazuh-manager.conf/var/ossec/etc/ossec.confXML 配置块logging顶层块logging顶层块plain 日志文件/var/wazuh-manager/logs/wazuh-manager.log/var/ossec/logs/ossec.logJSON 日志文件启用时同路径加.json扩展名同路径加.json扩展名Internal Options无无日志文件名的定义可以直接在 debug_op.h 中确认manager 端LOGFILE为logs/wazuh-manager.log、LOGJSONFILE为logs/wazuh-manager.jsonagent 端分别为logs/ossec.log与logs/ossec.jsonWindows agent 则为相对路径ossec.log/ossec.json。这与文档中JSON 日志与 plain 日志同目录、仅扩展名不同的说明完全一致。二、核心参数log_formatlogging块中当前唯一的参数是log_format默认值plain源码中当配置缺失时显式置为log_plain 1; log_json 0允许取值plain、json、plain,json逗号分隔表示同时输出两种格式语义说明plain— 人类可读文本格式默认json— 结构化 JSON 格式面向日志聚合工具plain,json— 同时输出两种格式非法值行为触发mlerror_exitdaemon 直接启动失败详见第三节源码分析。仓库中的 Manager 默认配置 wazuh-manager.conf 就包含了该配置块默认使用plain!-- Choose between plain or json format (or both) for internal logs -- logging log_formatplain/log_format /logging各发行版模板 logging.template 中也内置了同样的默认块!-- Choose between plain, json, or plain,json for the format of internal logs -- logging log_formatplain/log_format /logging三、完整配置示例三种模式以下示例继承自配置参考文档覆盖全部三种合法取值。注意 manager 默认配置文件的根元素为wazuh_config见 wazuh-manager.confagent 侧根元素为ossec_config修改时请保持与既有文件一致。1. 默认配置纯文本标准 plain 文本日志面向人工排障ossec_config logging log_formatplain/log_format /logging /ossec_config2. 仅 JSON 输出为接入日志聚合系统Elasticsearch、Splunk 等提供结构化日志ossec_config logging log_formatjson/log_format /logging /ossec_config3. 双输出Plain JSON同时输出 plain 与 JSON 日志ossec_config logging log_formatplain,json/log_format /logging /ossec_config典型使用场景既保留人类可读日志用于故障排查与支持工单又将结构化 JSON 持续喂给 SIEM / 日志聚合平台。四、两种格式的实际输出样例Plain 格式2026/07/06 12:34:56 wazuh-remoted: INFO: (1409): Reading authentication keys file. 2026/07/06 12:34:56 wazuh-analysisd: INFO: Started (pid: 12345). 2026/07/06 12:34:57 wazuh-remoted: INFO: Listening on port 1514 (TCP).格式为时间戳 标签: 级别: 消息。JSON 格式{timestamp:2026-07-06T12:34:560000,tag:wazuh-remoted,level:info,description:Reading authentication keys file.} {timestamp:2026-07-06T12:34:560000,tag:wazuh-analysisd,level:info,description:Started (pid: 12345).} {timestamp:2026-07-06T12:34:570000,tag:wazuh-remoted,level:info,description:Listening on port 1514 (TCP).}对照 _log_function 的 JSON 构造代码可以确认 JSON 行由cJSON生成字段包括字段含义来源timestampISO 风格时间戳如2026-07-06T12:34:560000w_get_timestamp(time(NULL))tag产生日志的 daemon 名wazuh-remoted等调用方传入level小写级别debug/info/warning/error/criticalstrleveljson[level]description日志正文经vsnprintf格式化调用方传入另外从源码结构看当以调试模式dbg_flag 0运行时JSON 输出会额外附带pid、file、line、routine四个诊断字段plain 输出也会相应变为tag[pid] file:line at func():的前缀形式。这对定位多进程环境下的日志来源非常有用。五、源码级实现剖析1. 配置解析与校验os_logging_config()配置解析入口是 debug_op.c 中的 os_logging_config()。其处理逻辑可以归纳为一条清晰的分支链读取主配置通过OS_ReadXML(WAZUHCONF, xml)读取主配置文件并以{config 根元素, logging, log_format}的元素路径提取log_format的内容元素缺失若log_format不存在或为空回退默认值log_plain 1, log_json 0并打印 debug 级别提示不报错按逗号拆分使用OS_StrBreak(,, logformat, 2)将取值拆成最多两个部分逐段w_strtrim去空白后匹配——plain→flags.log_plain 1json→flags.log_json 1其他任何值 → 先复位为默认plain随后调用mlerror_exit(LOGLEVEL_ERROR, XML_VALUEERR, log_format, part)终止进程、阻止 daemon 启动状态暴露getLoggingConfig() 会把两个标志导出为{logging:{plain:yes,json:no}}形式的 JSON可供控制/查询命令读取当前生效的日志模式。log_plain与log_json是 debug_op.c 顶部的位域标志unsigned int log_plain:1; unsigned int log_json:1;。这也解释了为什么双输出是两种格式标志独立置位的自然结果——两者互不排斥因此plain,json无需特殊处理。2. 日志写入路径_log_function()真正写日志的函数是 _log_function()每条日志的处理顺序为惰性初始化若模块尚未初始化首次日志调用会自动触发w_logging_init()→os_logging_config()即首次写日志时才解析配置。若调用方带plain_only标记用于避免在早期阶段再回调 XML 解析与 cJSON 等外部库则只置 plain 标志JSON 输出!plain_only flags.log_json时写入LOGJSONFILE用cJSON_PrintUnformatted生成单行 JSONfflush落盘。Linux 端有一个值得注意的实现细节文件已存在时以w模式截断重开并umask(0006)且在 root 运行时通过Privsep_GetGroup将文件属组修正为 Wazuh 运行组ossec全局组Windows 端则始终以追加a模式打开。从源码结构看这一存在即截断的行为意味着每次 daemon 重启时主日志会被重新建立实际滚动/归档由 monitord 模块负责Plain 输出flags.log_plain时写入LOGFILE先按dbg_flag决定是否附带file:line at func()调试前缀再输出级别与消息并发安全两个文件的写入都用同一个logging_mutex串行化w_mutex_lock/unlock避免多进程/多线程并发写文件造成的行交错前台模式回显daemon_flag 0前台运行时日志额外通过print_stderr_msg打印到 stderr方便直接观察启动过程。代码中一处注释印证了plain_only设计意图The plain_only flag allows to bypass the JSON output even when its enabled to avoid the call to external libraries like cJSON——即在初始化早期路径中刻意绕过 JSON 输出防止日志函数自身引发递归依赖。3. 与文档结论的对应关系文档中的实现说明源码印证位置解析器位于src/shared/src/debug_op.c的os_logging_config()debug_op.c#L280-L333非法log_format触发mlerror_exit阻止启动debug_op.c#L318-L322Manager 默认配置含plain块etc/wazuh-manager.conf#L13-L16全局作用于所有 daemon所有 daemon 共用src/shared中的日志实现配置读取同一主配置文件JSON 日志与 plain 同位置、扩展名为.jsondebug_op.h#L32-L40六、实操建议与相关文档排障优先日常运维保持默认plain即可需要向 SIEM 采集 Wazuh 自身运行日志时切换为json或plain,json变更生效方式该配置在 daemon 初始化阶段读取一次修改logging块后需要重启对应的 Wazuh 服务才能生效校验预检由于非法取值会导致进程直接退出修改配置后建议先在前台或以调试参数启动验证确认无XML_VALUEERR后再转为常驻服务与 monitord 配合日志轮转rotate策略由 Monitord 模块管理与本模块的格式控制互补可参考 Monitord Configuration完整的 manager / agent 配置总览分别见 Manager 配置参考 与 Agent 配置参考本模块的原始参考文档位于 docs/ref/modules/logging/configuration.md。【免费下载链接】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），仅供参考