尧图网页设计 
Wazuh DBSync 冒烟测试实战使用 dbsync_test_tool 验证 Insert / Update / Delete / Select 全流程【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh本文以 Wazuh 开源仓库中 InsertionUpdateDeleteSelect 冒烟测试文档 为主体完整讲解 DBSync 模块中最典型的一组数据库操作场景建库、插入、更新、删除与查询。读者将掌握dbsync_test_tool的配置文件结构、四类 action 输入文件JSON的编写要点、命令行执行方式以及从源码层面理解该工具内部如何通过 Action 工厂把 JSON 指令翻译为对 DBSync C 接口的调用从而能够独立运行并扩展自己的 DBSync 冒烟测试。1. 场景概览一个覆盖五种数据库操作的冒烟测试DBSyncDatabase Synchronization是 Wazuh 中的本地数据库同步模块负责在 Agent 侧维护本地 SQLite 数据如进程、网络套接字、硬件信息等并以增量同步的方式与 Manager 端保持一致。为了验证整个 DBSync 库的 API 都能被正确调用仓库在 src/shared_modules/dbsync/smokeTests/ 目录下提供了若干面向典型用例的冒烟测试每个子目录对应一个用例。InsertionUpdateDeleteSelect用例是其中最基础也最完整的一个它按以下五个步骤依次驱动数据库依据config.json中的sql_statement选项创建数据库含表结构与主键定义将inputSyncRowInsert.json中的数据插入数据库用inputSyncRowModified.json中的数据更新数据库中的既有行依据deleteRows.json中的数据删除部分数据库行依据inputSelectRows.json中的条件查询剩余行。该用例目录中共包含 5 个文件1 份说明文档与 4 份 JSON 输入文件插入、更新、删除、查询各一份数据库建表语句则由上一级目录 smokeTests/config.json 统一提供。2. 测试工具与执行前提该冒烟测试依赖dbsync_test_tool可执行文件。它属于 dbsync/testtool 组件定位是一个黑盒测试工具使用者通过命令行参数传入配置与动作文件工具依次执行并产出结果文件供人工或脚本分析。工具的整体工作流如下图所示从架构图可以看出用户向DBSync Test Tool提供config.json数据库初始化参数与一组 action 文件工具内部的Action Factory根据每个 action 文件中的指令实例化对应的IAction实现如deleteRows、singleRowInsert、singleRowModify、selectRows、createTxn/closeTxn等再调用底层DBSync接口执行真实数据库操作最终把结果写入输出目录。2.1 编译工具按 testtool 说明文档 的描述需要先以 release 或 debug 模式构建 Wazuh 目标make TARGETserver|agent DEBUG1构建完成后即可获得dbsync_test_tool二进制。构建相关细节还可参考 src/CMakeLists.txt 与 src/shared_modules/dbsync/CMakeLists.txt。2.2 命令行参数工具支持三个必选参数见 cmdArgsHelper.h 中的showHelp()参数含义示例-c指定用于初始化数据库的 JSON 配置文件-c config.json-a指定动作文件列表多个文件用英文逗号分隔按顺序执行-a a.json,b.json,c.json-o指定结果输出目录-o ./output3. 数据库初始化config.json 详解sql_statement字段决定数据库结构。冒烟测试目录本身没有config.json共用上层 src/shared_modules/dbsync/smokeTests/config.json{ db_name: temp.db, db_type: 1, host_type: 1, persistance: , sql_statement: CREATE TABLE processes(pid BIGINT, name TEXT, path TEXT, cmdline TEXT, state TEXT, cwd TEXT, root TEXT, uid BIGINT, gid BIGINT, euid BIGINT, egid BIGINT, suid BIGINT, sgid BIGINT, on_disk INTEGER, wired_size BIGINT, resident_size BIGINT, total_size BIGINT, user_time BIGINT, system_time BIGINT, disk_bytes_read BIGINT, disk_bytes_written BIGINT, start_time BIGINT, parent BIGINT, pgroup BIGINT, threads INTEGER, nice INTEGER, is_elevated_token INTEGER, elapsed_time BIGINT, handle_count BIGINT, percent_processor_time BIGINT, upid BIGINT HIDDEN, uppid BIGINT HIDDEN, cpu_type INTEGER HIDDEN, cpu_subtype INTEGER HIDDEN, phys_footprint BIGINT HIDDEN, PRIMARY KEY (pid)) WITHOUT ROWID;CREATE TABLE processes_sockets(socket_id BIGINT, pid BIGINT, PRIMARY KEY (socket_id)) WITHOUT ROWID; }各字段说明与 testtool 文档 一致db_name要使用的数据库名称此处为temp.dbdb_type数据库类型目前仅支持 SQLite3取值为1host_type宿主类型0表示 Manager1表示 Agentpersistance持久化类型。结合 main.cpp 的源码可见当persistance为1时调用dbsync_create_persistent(...)否则调用dbsync_create(...)。本配置为空字符串即创建非持久化数据库sql_statement建库 SQL 结构与后续 action 文件中的数据字段一一对应。sql_statement中同时创建了两张表主表processes以pid为主键WITHOUT ROWID与关联表processes_sockets以socket_id为主键。processes表字段与真实系统进程信息对应pid、name、path、cmdline、parent、threads等部分字段标记为HIDDEN如upid、uppid、cpu_type这类字段参与表结构定义但不会在普通查询结果中暴露。4. 四份动作文件逐一拆解动作文件最外层是action字段决定调用哪个 DBSync APIbody字段携带具体数据。工具在 factoryAction.h 中按action字符串将 JSON 映射到对应的IAction实现。4.1 插入inputSyncRowInsert.json文件inputSyncRowInsert.json{ action: dbsync_sync_row, body: { table: processes, data:[ { pid:4, name:System, path:, cmdline:, ... threads:164, ... }, { pid:5, name:System, path:/usr/lib, cmdline:whoami, ... }, { pid:6, name:User, path:/usr/lib, cmdline:nano, ... }, { pid:7, name:System, path:/usr/lib, cmdline:git, ... } ] } }要点action为dbsync_sync_row在工厂中对应SyncRowAction见 action.h最终调用dbsync_sync_row()body.table指明目标表processesbody.data是一个数组一次可携带多行每行数据的字段必须与config.json中sql_statement定义的列一一对应未提供的可选字段会以缺省值写入本文件一次性插入 pid 为 4、5、6、7 的四行进程数据其中 pid5 对应whoami命令、pid6 对应nano、pid7 对应git作为后续更新与删除的素材。dbsync_sync_row是一个按主键 upsert风格的同步接口若主键pid已存在则更新该行否则插入新行。这一点对理解第 4.2 节的更新方式至关重要。4.2 更新inputSyncRowModified.json文件inputSyncRowModified.json{ action: dbsync_sync_row, body: { table: processes, data:[ { pid:4, name:User, path:, cmdline:Guake, ... parent:1, ... } ] } }要点同样使用dbsync_sync_row但携带的主键pid4在第 1 步插入时已经存在因此不会新增行而是就地更新该行对比插入数据可见pid4 的name由System变为User、cmdline由空串变为Guake、parent由 0 变为 1其余字段保持不变这模拟了真实场景中同一进程的数据发生变化后重新上报的行为验证 DBSync 的 upsert 语义。4.3 删除deleteRows.json文件deleteRows.json{ action: dbsync_delete_rows, body: { table:processes, query: { data:[ { pid:4, name:System, path:, cmdline:, ... }, { pid:6, name:System, path:/usr/lib, cmdline:whoami, ... } ], row_filter_opt:pid4 } } }要点action切换为dbsync_delete_rows对应 action.h 中的DeleteRowsAction最终调用dbsync_delete_rows()body.table指定目标表body.query.data提供待删除行的字段快照此处给出 pid 4 与 pid 6 两行row_filter_opt提供附加的行过滤条件pid4用于与data中的字段共同限定删除范围该用例的意图是删除第 1 步插入的部分行pid4 与 pid6 两行从而让后续查询结果只包含未被删除的行pid5 与 pid7。4.4 查询inputSelectRows.json文件inputSelectRows.json{ action: dbsync_select_rows, body: { table:processes, query:{ column_list:[pid,name,path,cmdline], row_filter:WHERE pid5, distinct_opt:false, order_by_opt:, count_opt:100 } } }要点action为dbsync_select_rows对应 action.h 中的SelectRowsAction最终调用dbsync_select_rows()query.column_list指定要返回的列此处为pid、name、path、cmdline四列query.row_filterSQL WHERE 子句WHERE pid5意味着只返回主键大于 5 的行query.distinct_opt是否去重此处为falsequery.order_by_opt排序字段此处为空字符串即不排序query.count_opt返回行数上限此处为 100。预期结果推断经过插入pid 4、5、6、7→ 更新pid4 改为 User/Guake→ 删除pid4 与 pid6之后表中剩余 pid5 与 pid7 两行再叠加WHERE pid5过滤最终查询只应返回 pid7 的一行name为System、cmdline为git。这一结论完全由四份输入文件的内容推演得出可作为验证测试是否通过的判据。5. 执行命令与结果输出在拥有dbsync_test_tool二进制的前提下进入用例目录执行./dbsync_test_tool -c config.json -a inputSyncRowInsert.json,inputSyncRowModified.json,deleteRows.json,inputSelectRows.json -o ./output5.1 参数作用与执行顺序-c config.json指定 smokeTests/config.json据此完成建库-a按逗号分隔的顺序传入四份动作文件。工具在 main.cpp 中逐个解析文件提取action字段后交由FactoryAction::create()实例化对应动作并顺序执行——因此传入顺序即数据库操作顺序必须保持先插、再改、再删、最后查-o ./output指定结果输出目录。从源码看main.cpp还会把配置文件中的db_name、db_type、host_type、persistance、sql_statement一并解析并根据persistance是否等于1决定调用dbsync_create_persistent()还是dbsync_create()数据库创建成功后循环执行所有 action最后调用dbsync_teardown()释放资源。若配置有误返回句柄为 0工具会输出Something went wrong configuring the database...提示并退出。5.2 输出文件说明按 testtool 文档 的约定所有结果写入-o指定的输出目录命名格式为action_序号.json序号与-a传入顺序一一对应从 0 开始。以本用例为例输出文件对应动作内容action_0.json插入{dbsync_sync_row: 返回码}action_1.json更新{dbsync_sync_row: 返回码}action_2.json删除{dbsync_delete_rows: 返回码}action_3.json查询{dbsync_select_rows: 返回码}callback.action_3.json查询结果实际返回的行数据从 action.h 的源码可以看到插入、更新、删除类动作把 C 接口的返回值写入action_N.json而SelectRowsAction还额外注册了一个结果回调getCallbackCtx把查询到的行数据累积写入callback.action_N.json便于核对第 4.4 节的预期结果。工具执行完毕会打印Resulting files are located in the output folder。6. 扩展以本用例为模板编写自己的冒烟测试这个用例的结构完全可以当作模板复用。编写一个新的 DBSync 冒烟测试只需四步准备 config.json参照 smokeTests/config.json在sql_statement中定义目标表结构与主键编写动作文件参照本用例的四份 JSON按需组合dbsync_insert_data、dbsync_update_with_snapshot、dbsync_sync_row、dbsync_delete_rows、dbsync_select_rows等 action。工厂支持的全部 action 代码见 factoryAction.h除 C 风格命名如dbsync_insert_data外还提供等价的 C 风格命名如insertData按顺序执行-a中动作文件的顺序即执行顺序注意依赖关系先建表后插入、先插入后更新/删除核对输出通过action_N.json的返回码与callback.*.json的行数据验证结果。仓库中 snapshotsUpdate、triggerActions 与 txnOperation 三个用例还分别覆盖了快照更新、表关系联动与事务操作可作为进阶参考。整体冒烟测试的设计意图与目录结构见 smokeTests 总说明。7. 小结InsertionUpdateDeleteSelect冒烟测试以最小的文件集合串起了 DBSync 模块最核心的增、改、删、查能力config.json定义库结构四份 action 文件按序驱动dbsync_sync_row插入与更新、dbsync_delete_rows删除与dbsync_select_rows查询dbsync_test_tool则在Action Factory的调度下把这些 JSON 指令翻译为对底层 C 接口的调用并将返回码与查询结果落盘。理解这个用例就等于掌握了 DBSync 模块数据流转的主干路径也为阅读 src/shared_modules/dbsync 其余源码与测试提供了入口。【免费下载链接】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），仅供参考 Wazuh DBSync 冒烟测试实战：使用 dbsync_test_tool 验证 Insert / Update / Delete / Select 全流程
Wazuh DBSync 冒烟测试实战使用 dbsync_test_tool 验证 Insert / Update / Delete / Select 全流程【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh本文以 Wazuh 开源仓库中 InsertionUpdateDeleteSelect 冒烟测试文档 为主体完整讲解 DBSync 模块中最典型的一组数据库操作场景建库、插入、更新、删除与查询。读者将掌握dbsync_test_tool的配置文件结构、四类 action 输入文件JSON的编写要点、命令行执行方式以及从源码层面理解该工具内部如何通过 Action 工厂把 JSON 指令翻译为对 DBSync C 接口的调用从而能够独立运行并扩展自己的 DBSync 冒烟测试。1. 场景概览一个覆盖五种数据库操作的冒烟测试DBSyncDatabase Synchronization是 Wazuh 中的本地数据库同步模块负责在 Agent 侧维护本地 SQLite 数据如进程、网络套接字、硬件信息等并以增量同步的方式与 Manager 端保持一致。为了验证整个 DBSync 库的 API 都能被正确调用仓库在 src/shared_modules/dbsync/smokeTests/ 目录下提供了若干面向典型用例的冒烟测试每个子目录对应一个用例。InsertionUpdateDeleteSelect用例是其中最基础也最完整的一个它按以下五个步骤依次驱动数据库依据config.json中的sql_statement选项创建数据库含表结构与主键定义将inputSyncRowInsert.json中的数据插入数据库用inputSyncRowModified.json中的数据更新数据库中的既有行依据deleteRows.json中的数据删除部分数据库行依据inputSelectRows.json中的条件查询剩余行。该用例目录中共包含 5 个文件1 份说明文档与 4 份 JSON 输入文件插入、更新、删除、查询各一份数据库建表语句则由上一级目录 smokeTests/config.json 统一提供。2. 测试工具与执行前提该冒烟测试依赖dbsync_test_tool可执行文件。它属于 dbsync/testtool 组件定位是一个黑盒测试工具使用者通过命令行参数传入配置与动作文件工具依次执行并产出结果文件供人工或脚本分析。工具的整体工作流如下图所示从架构图可以看出用户向DBSync Test Tool提供config.json数据库初始化参数与一组 action 文件工具内部的Action Factory根据每个 action 文件中的指令实例化对应的IAction实现如deleteRows、singleRowInsert、singleRowModify、selectRows、createTxn/closeTxn等再调用底层DBSync接口执行真实数据库操作最终把结果写入输出目录。2.1 编译工具按 testtool 说明文档 的描述需要先以 release 或 debug 模式构建 Wazuh 目标make TARGETserver|agent DEBUG1构建完成后即可获得dbsync_test_tool二进制。构建相关细节还可参考 src/CMakeLists.txt 与 src/shared_modules/dbsync/CMakeLists.txt。2.2 命令行参数工具支持三个必选参数见 cmdArgsHelper.h 中的showHelp()参数含义示例-c指定用于初始化数据库的 JSON 配置文件-c config.json-a指定动作文件列表多个文件用英文逗号分隔按顺序执行-a a.json,b.json,c.json-o指定结果输出目录-o ./output3. 数据库初始化config.json 详解sql_statement字段决定数据库结构。冒烟测试目录本身没有config.json共用上层 src/shared_modules/dbsync/smokeTests/config.json{ db_name: temp.db, db_type: 1, host_type: 1, persistance: , sql_statement: CREATE TABLE processes(pid BIGINT, name TEXT, path TEXT, cmdline TEXT, state TEXT, cwd TEXT, root TEXT, uid BIGINT, gid BIGINT, euid BIGINT, egid BIGINT, suid BIGINT, sgid BIGINT, on_disk INTEGER, wired_size BIGINT, resident_size BIGINT, total_size BIGINT, user_time BIGINT, system_time BIGINT, disk_bytes_read BIGINT, disk_bytes_written BIGINT, start_time BIGINT, parent BIGINT, pgroup BIGINT, threads INTEGER, nice INTEGER, is_elevated_token INTEGER, elapsed_time BIGINT, handle_count BIGINT, percent_processor_time BIGINT, upid BIGINT HIDDEN, uppid BIGINT HIDDEN, cpu_type INTEGER HIDDEN, cpu_subtype INTEGER HIDDEN, phys_footprint BIGINT HIDDEN, PRIMARY KEY (pid)) WITHOUT ROWID;CREATE TABLE processes_sockets(socket_id BIGINT, pid BIGINT, PRIMARY KEY (socket_id)) WITHOUT ROWID; }各字段说明与 testtool 文档 一致db_name要使用的数据库名称此处为temp.dbdb_type数据库类型目前仅支持 SQLite3取值为1host_type宿主类型0表示 Manager1表示 Agentpersistance持久化类型。结合 main.cpp 的源码可见当persistance为1时调用dbsync_create_persistent(...)否则调用dbsync_create(...)。本配置为空字符串即创建非持久化数据库sql_statement建库 SQL 结构与后续 action 文件中的数据字段一一对应。sql_statement中同时创建了两张表主表processes以pid为主键WITHOUT ROWID与关联表processes_sockets以socket_id为主键。processes表字段与真实系统进程信息对应pid、name、path、cmdline、parent、threads等部分字段标记为HIDDEN如upid、uppid、cpu_type这类字段参与表结构定义但不会在普通查询结果中暴露。4. 四份动作文件逐一拆解动作文件最外层是action字段决定调用哪个 DBSync APIbody字段携带具体数据。工具在 factoryAction.h 中按action字符串将 JSON 映射到对应的IAction实现。4.1 插入inputSyncRowInsert.json文件inputSyncRowInsert.json{ action: dbsync_sync_row, body: { table: processes, data:[ { pid:4, name:System, path:, cmdline:, ... threads:164, ... }, { pid:5, name:System, path:/usr/lib, cmdline:whoami, ... }, { pid:6, name:User, path:/usr/lib, cmdline:nano, ... }, { pid:7, name:System, path:/usr/lib, cmdline:git, ... } ] } }要点action为dbsync_sync_row在工厂中对应SyncRowAction见 action.h最终调用dbsync_sync_row()body.table指明目标表processesbody.data是一个数组一次可携带多行每行数据的字段必须与config.json中sql_statement定义的列一一对应未提供的可选字段会以缺省值写入本文件一次性插入 pid 为 4、5、6、7 的四行进程数据其中 pid5 对应whoami命令、pid6 对应nano、pid7 对应git作为后续更新与删除的素材。dbsync_sync_row是一个按主键 upsert风格的同步接口若主键pid已存在则更新该行否则插入新行。这一点对理解第 4.2 节的更新方式至关重要。4.2 更新inputSyncRowModified.json文件inputSyncRowModified.json{ action: dbsync_sync_row, body: { table: processes, data:[ { pid:4, name:User, path:, cmdline:Guake, ... parent:1, ... } ] } }要点同样使用dbsync_sync_row但携带的主键pid4在第 1 步插入时已经存在因此不会新增行而是就地更新该行对比插入数据可见pid4 的name由System变为User、cmdline由空串变为Guake、parent由 0 变为 1其余字段保持不变这模拟了真实场景中同一进程的数据发生变化后重新上报的行为验证 DBSync 的 upsert 语义。4.3 删除deleteRows.json文件deleteRows.json{ action: dbsync_delete_rows, body: { table:processes, query: { data:[ { pid:4, name:System, path:, cmdline:, ... }, { pid:6, name:System, path:/usr/lib, cmdline:whoami, ... } ], row_filter_opt:pid4 } } }要点action切换为dbsync_delete_rows对应 action.h 中的DeleteRowsAction最终调用dbsync_delete_rows()body.table指定目标表body.query.data提供待删除行的字段快照此处给出 pid 4 与 pid 6 两行row_filter_opt提供附加的行过滤条件pid4用于与data中的字段共同限定删除范围该用例的意图是删除第 1 步插入的部分行pid4 与 pid6 两行从而让后续查询结果只包含未被删除的行pid5 与 pid7。4.4 查询inputSelectRows.json文件inputSelectRows.json{ action: dbsync_select_rows, body: { table:processes, query:{ column_list:[pid,name,path,cmdline], row_filter:WHERE pid5, distinct_opt:false, order_by_opt:, count_opt:100 } } }要点action为dbsync_select_rows对应 action.h 中的SelectRowsAction最终调用dbsync_select_rows()query.column_list指定要返回的列此处为pid、name、path、cmdline四列query.row_filterSQL WHERE 子句WHERE pid5意味着只返回主键大于 5 的行query.distinct_opt是否去重此处为falsequery.order_by_opt排序字段此处为空字符串即不排序query.count_opt返回行数上限此处为 100。预期结果推断经过插入pid 4、5、6、7→ 更新pid4 改为 User/Guake→ 删除pid4 与 pid6之后表中剩余 pid5 与 pid7 两行再叠加WHERE pid5过滤最终查询只应返回 pid7 的一行name为System、cmdline为git。这一结论完全由四份输入文件的内容推演得出可作为验证测试是否通过的判据。5. 执行命令与结果输出在拥有dbsync_test_tool二进制的前提下进入用例目录执行./dbsync_test_tool -c config.json -a inputSyncRowInsert.json,inputSyncRowModified.json,deleteRows.json,inputSelectRows.json -o ./output5.1 参数作用与执行顺序-c config.json指定 smokeTests/config.json据此完成建库-a按逗号分隔的顺序传入四份动作文件。工具在 main.cpp 中逐个解析文件提取action字段后交由FactoryAction::create()实例化对应动作并顺序执行——因此传入顺序即数据库操作顺序必须保持先插、再改、再删、最后查-o ./output指定结果输出目录。从源码看main.cpp还会把配置文件中的db_name、db_type、host_type、persistance、sql_statement一并解析并根据persistance是否等于1决定调用dbsync_create_persistent()还是dbsync_create()数据库创建成功后循环执行所有 action最后调用dbsync_teardown()释放资源。若配置有误返回句柄为 0工具会输出Something went wrong configuring the database...提示并退出。5.2 输出文件说明按 testtool 文档 的约定所有结果写入-o指定的输出目录命名格式为action_序号.json序号与-a传入顺序一一对应从 0 开始。以本用例为例输出文件对应动作内容action_0.json插入{dbsync_sync_row: 返回码}action_1.json更新{dbsync_sync_row: 返回码}action_2.json删除{dbsync_delete_rows: 返回码}action_3.json查询{dbsync_select_rows: 返回码}callback.action_3.json查询结果实际返回的行数据从 action.h 的源码可以看到插入、更新、删除类动作把 C 接口的返回值写入action_N.json而SelectRowsAction还额外注册了一个结果回调getCallbackCtx把查询到的行数据累积写入callback.action_N.json便于核对第 4.4 节的预期结果。工具执行完毕会打印Resulting files are located in the output folder。6. 扩展以本用例为模板编写自己的冒烟测试这个用例的结构完全可以当作模板复用。编写一个新的 DBSync 冒烟测试只需四步准备 config.json参照 smokeTests/config.json在sql_statement中定义目标表结构与主键编写动作文件参照本用例的四份 JSON按需组合dbsync_insert_data、dbsync_update_with_snapshot、dbsync_sync_row、dbsync_delete_rows、dbsync_select_rows等 action。工厂支持的全部 action 代码见 factoryAction.h除 C 风格命名如dbsync_insert_data外还提供等价的 C 风格命名如insertData按顺序执行-a中动作文件的顺序即执行顺序注意依赖关系先建表后插入、先插入后更新/删除核对输出通过action_N.json的返回码与callback.*.json的行数据验证结果。仓库中 snapshotsUpdate、triggerActions 与 txnOperation 三个用例还分别覆盖了快照更新、表关系联动与事务操作可作为进阶参考。整体冒烟测试的设计意图与目录结构见 smokeTests 总说明。7. 小结InsertionUpdateDeleteSelect冒烟测试以最小的文件集合串起了 DBSync 模块最核心的增、改、删、查能力config.json定义库结构四份 action 文件按序驱动dbsync_sync_row插入与更新、dbsync_delete_rows删除与dbsync_select_rows查询dbsync_test_tool则在Action Factory的调度下把这些 JSON 指令翻译为对底层 C 接口的调用并将返回码与查询结果落盘。理解这个用例就等于掌握了 DBSync 模块数据流转的主干路径也为阅读 src/shared_modules/dbsync 其余源码与测试提供了入口。【免费下载链接】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），仅供参考