为什么要把剧本日志集中收
自动化剧本在每台受管机上都会留下执行痕迹：控制节点有剧本输出，受管机有模块执行与系统日志，作业平台还有一份任务记录。三处分散时，事后只能人工逐台翻文件。集中收集的真正目标是「按执行批次还原全过程」——谁在什么时候对哪台机器执行了哪个任务、结果如何。它同时是误操作追溯与安全审计的证据来源，也是用失败率、耗时反过来优化剧本的数据基础。
基本信息
| 收集对象 | 控制节点剧本输出、受管机执行痕迹、作业平台任务记录 |
|---|---|
| 核心关联键 | 执行批次编号、剧本版本、受管主机名、任务名 |
| 常见落点 | rsyslog 转发、filebeat/fluentd 采集、作业平台数据库与 API |
| 权限要求 | 读 /var/log 与平台日志需 root 或平台管理员 |
典型采集路径
- 控制节点单文件：配置 ansible.cfg 的日志路径，所有剧本输出落到同一文件，再交给采集器转发
- 回调插件分流：按任务或按主机把结构化事件写成 JSON，便于入库与检索
- 作业平台内置：AWX 类平台把任务输出落库，用 API 或导出功能取回，不直接读容器内文件
- 系统日志转出：受管机侧交给 rsyslog 或采集器，避免逐台登录取数
- 失败即取：剧本失败分支里自动抓取受管机必要日志并回传，减少事后补采
- 长期归档：按批次归档到对象存储，保留期限与合规要求一致
控制节点落地示例
控制节点落地示例
# 所有剧本输出落到同一文件
[defaults]
log_path = /var/log/ansible/ansible.log
# 打开结构化回调，供采集器按行解析 JSON
callbacks_enabled = json
# 回调插件目录按安装方式调整，以官方文档为准
callback_plugins = /etc/ansible/callback_plugins链路自检
链路自检
ansible-playbook -i hosts site.yml # 执行一次，产生一条完整批次记录
tail -n 50 /var/log/ansible/ansible.log # 确认控制节点日志已落盘
ls -l /var/log/ansible/hosts/ # 按主机拆分的回调会写到这里
logger -p local0.info 'log pipe test' # 反向验证转发链路连通
journalctl -u rsyslog --since '10 min ago' # 转发组件无输出先看它自身日志各来源采集对照
| 日志来源 | 默认位置 | 集中方式 |
|---|---|---|
| 控制节点剧本输出 | ansible.cfg 配置的日志路径 | 采集器读文件，按批次切分 |
| 受管机执行痕迹 | 系统日志与授权相关文件 | rsyslog 转发到集中端 |
| 平台任务输出 | 平台数据库 | 平台 API 拉取或平台外发 |
| 回调事件 | 回调配置的文件或套接字 | 按 JSON 逐行解析后入库 |
| 依赖与插件日志 | 标准错误输出 | 重定向到文件后再采集 |
回调插件一般分三类：写单文件的文本类、写 JSON 的结构化类、直接投递到消息队列或日志平台的转发类。选型只看两点——后续是否需要被机器检索（要结构化）、是否允许把受管机数据带出到外部平台。具体配置项随版本变化，以官方文档为准。
no_log 只能阻止任务结果进入默认输出，不能替代凭据治理：自研回调若在任务开始阶段直接读取参数，敏感值仍可能写进集中日志。口令与密钥应由凭据管理工具在源头注入，集中端再对已知敏感字段做二次脱敏。