关键是要用syslog/fluentd/loki等支持远程的驱动，配全syslog-address、tag、env、label等参数，确保日志带容器元数据和审计上下文，并在堡垒机侧配置对应接收通道（如next terminal开syslog监听、jumpserver用filebeat中转），最后通过抓包、inspect和界面实时流三重验证。
直接用 Docker 日志驱动把容器安全审计日志秒级同步到堡垒机，关键不是“能不能传”，而是“传什么、怎么传、谁来收、如何验”。堡垒机本身不主动拉日志，它只接收结构化、带上下文、可归属的审计流——所以必须由容器侧主动推送，且驱动选型 + 参数配置 + 堡垒机端适配三者缺一不可。
必须用支持远程输出的驱动，不能用 json-file 或 journaldjson-file 只写本地磁盘，journald 依赖宿主机 systemd，二者都不走网络，无法直连堡垒机。真正可用的是：
-
syslog：最稳，UDP/TCP/TLS 全支持，堡垒机（如 Next Terminal、Jumpserver）普遍内置 syslog 接入点 -
fluentd：适合已有 Fluentd 集群的环境，可通过 forward 协议将日志打到堡垒机所在网络的 fluentd agent -
loki（Docker 24.0+ 原生支持）：轻量，标签天然可映射堡垒机会话 ID 或用户 UID，但需堡垒机侧部署 Loki gateway 或 Grafana Agent 中转
每条命令都要带审计元数据，否则堡垒机收了也白收
光指定 --log-driver=syslog 不行，必须注入可追溯字段：
-
--log-opt syslog-address=tcp://:514：强制走 TCP，避免 UDP 丢包；若堡垒机启用了 TLS syslog，地址要写tls://...并挂载证书 -
--log-opt tag="{{.Name}}|{{.ImageName}}|{{.ID}}"：让每条日志开头自带容器名、镜像、短 ID，堡垒机解析时可自动绑定会话 -
--log-opt env=USER_ID,TRACE_ID,SESSION_ID：把应用层透传的审计上下文带上，例如SESSION_ID可与堡垒机生成的会话 ID 对齐，实现命令→操作人→目标资产全链路闭环 -
--label io.bastion.session-id=abc123：用 label 显式绑定堡垒机会话 ID，该字段会进入日志 attrs，被 syslog 或 fluentd 自动提取为 structured field
堡垒机侧必须提前配好接收通道并验证通路
不同堡垒机接入方式不同，不能“发了就完事”：
-
Next Terminal：在「系统设置 → 审计日志」中开启 Syslog 接收，填入监听地址（如
0.0.0.0:514），协议选 TCP，保存后检查/var/log/nextterminal/syslog.log是否有新条目 -
Jumpserver：不原生收 syslog，需通过
rsyslog或filebeat中转写入 MySQL 的audits_sessionlog表；或启用其内置的 API 接收模式，再用 fluentd 的 http output 插件 POST 到/api/v1/audits/command-logs/ -
阿里云 Bastionhost：支持直接对接 SLS，但需先在堡垒机控制台开通「审计日志归档」，再用
loki-docker-driver将日志推至 SLS 的 Loki 兼容接口（Endpoint 形如https://<region>.sls.aliyuncs.com/logstores/<store>/loki/api/v1/push</store></region>）
验证是否真同步成功，别只看 docker run 返回 success
- 在堡垒机服务器上抓包确认：
tcpdump -i any port 514 -A -c 5 | grep -E "(myapp|abc123)" - 查容器实际生效配置：
docker inspect myapp --format='{{.HostConfig.LogConfig}}'，确认SyslogAddress和Tag已写入 - 登录堡垒机 Web 界面，打开「会话审计 → 实时日志流」，筛选
container_name: myapp，看是否有带SESSION_ID=abc123的条目持续刷出
不复杂但容易忽略
