安全事件复盘往往卡在没证据：误删的工单、异常的大流量下载、被悄悄改掉的对象，事后要查谁、什么时间、从哪台机器、动了哪个键，对象存储默认只管存不管记。合规与审计留存的要求，把这件事从「能存」推到了「能查」。RustFS 的审计目标（Audit Targets）把集群里每一次请求和 API 活动投递到外部系统，SIEM、合规留存、调查取证一条链打通。
审计目标不是事件通知
先分清楚：审计目标和事件通知是两件事。事件通知是按桶配置的，每条规则挑一个目标，还支持事件类型、前缀、后缀筛选，服务于应用工作流和数据管道。审计目标则是整个集群的请求与 API 活动，没有按目标的事件筛选器，它要的是全量流水，不是挑出来的事件。
所以选型逻辑很简单：要驱动下游业务（比如对象一落桶就触发处理）用事件通知；要安全监控、合规、调查取证，用审计目标。两者可以并存，互不影响。
支持往哪送
RustFS 的审计目标支持一大家族目的地：webhook、Kafka、MQTT、MySQL、PostgreSQL、NATS、Redis、AMQP、Pulsar。每个启用的目标都会独立收到审计流，RustFS 把每条记录扇出到所有已启用的目标，一个目标挂了不会阻断往其他目标的投递尝试。
对大多数团队，webhook 是最快落地的，给个 HTTPS 端点，RustFS 就把 JSON 审计条目 POST 过去，后面接个轻量收集器或 SIEM 的 HTTP 摄入接口都行。
九类目标怎么配
列得出家族容易，真正上手卡在「每个目标用什么变量」。审计目标支持 WEBHOOK、KAFKA、MQTT、MYSQL、POSTGRES、NATS、REDIS、AMQP、PULSAR 九类，统一命名是RUSTFS_AUDIT_<TARGET>_<KEY>，目标实例名放在后缀（比如PRIMARY、ARCHIVE），各目标再带自己的开关与配置键。常用键如下，完整清单以官方《环境变量》参考页为准：
| 目标 | 配置键（RUSTFS_AUDIT_<TARGET>_*） |
|---|---|
| WEBHOOK | ENDPOINT/AUTH_TOKEN/QUEUE_DIR/QUEUE_LIMIT/CLIENT_CERT/CLIENT_KEY/CLIENT_CA/SKIP_TLS_VERIFY |
| KAFKA | BROKERS/TOPIC |
| MQTT | BROKER/TOPIC |
| MYSQL | DSN_STRING |
| POSTGRES | DSN_STRING |
| NATS | ADDRESS |
| REDIS | URL |
| AMQP | URL |
| PULSAR | BROKER |
开关是各目标的ENABLE键（webhook 即RUSTFS_AUDIT_WEBHOOK_ENABLE_PRIMARY），实例后缀换一套大写就是第二个并行目标。
用环境变量把一个 webhook 目标配起来
审计投递默认是关的。下面这组环境变量会启用模块，并创建一个名叫primary的 webhook 目标（目标名就是环境变量后缀的小写，_PRIMARY变成primary）：
exportRUSTFS_AUDIT_ENABLE="true"exportRUSTFS_AUDIT_WEBHOOK_ENABLE_PRIMARY="on"exportRUSTFS_AUDIT_WEBHOOK_ENDPOINT_PRIMARY="https://audit.example.com/rustfs"exportRUSTFS_AUDIT_WEBHOOK_AUTH_TOKEN_PRIMARY="<你的-webhook-token>"exportRUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY="/var/lib/rustfs/audit-primary"exportRUSTFS_OUTBOUND_ALLOW_ORIGINS="https://audit.example.com"（注：RUSTFS_OUTBOUND_ALLOW_ORIGINS未收录在官方《环境变量》参考页，作用与配置详见官方「出站连接策略 / Outbound Connection Policy」文档。它决定审计与通知的出站端点是否放行：私有网络、Docker Compose 服务名、RFC 1918 内网地址若不在列表里会被拦截。）
改完由环境管理的目标后重启 RustFS 才生效。注意这类目标无法通过控制台或管理 API 增删改，要换就改环境变量再重启。想再开一个并行目标，换个大写后缀即可，比如RUSTFS_AUDIT_WEBHOOK_ENABLE_ARCHIVE配一套_ARCHIVE设置，就会多出一个archivewebhook 和primary同时收流。
接收方要先验，再收流
webhook 的投递有个细节容易踩：RustFS 向端点源的根路径发HEAD健康检查（比如https://audit.example.com/），再向完整配置的端点发 JSONPOST。所以源必须响应HEAD，投递路径还得接受带Authorization: Bearer <token>的POST。上线前先验可达性和令牌：
curl--fail--headhttps://audit.example.com/健康检查不含 webhook 授权令牌，只测源可达性，令牌得单独确认。目标持续离线时，按 DNS、防火墙、RUSTFS_OUTBOUND_ALLOW_ORIGINS、证书信任、源对HEAD /的响应逐层排查。
那条审计记录长这样，字段因操作而异，空的可选字段可能省略：
{"version":"1","time":1719331200000,"event":"s3:ObjectCreated:Put","trigger":"s3","api":{"name":"PutObject","bucket":"my-bucket","object":"hello.txt","status":"OK","statusCode":200},"remotehost":"192.0.2.10","requestID":"<id>","userAgent":"aws-cli","requestPath":"/my-bucket/hello.txt","accessKey":"<你的-access-key>"}把它当可扩展模式解析：只取需要的字段，对未知或缺失字段留好容错，收集器才能扛住后续版本。
几个运维要盯的边界
投递是至少一次，不是恰好一次。接收方处理完、RustFS 观察到响应之前可能超时，所以按需用requestID等稳定字段去重。接收方只有真正持久收到记录才该回 ACK，否则 RustFS 没法恢复被静默丢弃的记录。
配了RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY后，RustFS 会把待发记录落盘，瞬时投递失败会重放，按预期中断时长定队列目录大小和RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY，同时盯磁盘用量和目标健康。队列目录必须让 RustFS 服务账户可写：官方容器里 RustFS 以非 root 用户 rustfs（UID 10001）运行，用-v挂载的主机目录要先chown -R 10001:10001 /var/lib/rustfs/audit-primary，否则会权限拒绝、写不进队列。
远程收集器应一律走 HTTPS，证书验证保持开启，Bearer 令牌别进源码库，用 mTLS 时把客户端证书和私钥一起给。端点本身接受 HTTP 或 HTTPS，走 HTTPS 是运维要求而非产品限制。审计负载可能含安全敏感的请求和身份元数据，目标位置要按保留和合规要求管好访问。
最后提醒：rc命令行目前没有创建、列出、移除审计目标的命令，审计目标以环境变量配置为主（环境管理的目标不能在控制台增删改），rc bucket event只管存储桶通知规则，不碰审计投递。
落地动作清单
- 区分需求：业务触发走事件通知，安全、合规、取证走审计目标。
- 环境变量开
RUSTFS_AUDIT_ENABLE与RUSTFS_AUDIT_WEBHOOK_ENABLE_PRIMARY等，配端点、令牌、队列目录。 - 改完环境变量重启 RustFS，环境管理的目标不能从控制台改。
- 上线前
curl --head验源可达，单独验 Bearer POST。 - 收集器按可扩展模式解析 JSON，用
requestID去重，开 HTTPS 加 mTLS。
官方入口：审计目标文档 docs.rustfs.com/zh/security-compliance/audit-logs，环境变量参考 docs.rustfs.com/zh/reference/environment-variables，可观测性 docs.rustfs.com/zh/operations/observability，源码在 GitHub。
