每个请求都有日志吗“这个问题在 RustFS 上要拆成两半回答。安全侧的答案是肯定的审计目标Audit Targets把请求级记录投递给外部系统文档写得很全。但如果你想要的是传统 HTTP 访问日志那类东西——每次请求一行、带耗时和字节数、能算 p99那要分另一条路走因为 S3 桶访问日志这个特性在 RustFS 的兼容矩阵里还标在计划中”。两条路各管一段接法不一样。先把审计目标接上审计目标默认关闭用环境变量开启。最小配置是这四行exportRUSTFS_AUDIT_ENABLEtrueexportRUSTFS_AUDIT_WEBHOOK_ENABLE_PRIMARYonexportRUSTFS_AUDIT_WEBHOOK_ENDPOINT_PRIMARYhttps://audit.example.com/rustfsexportRUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY/var/lib/rustfs/audit-primaryRustFS 会对端点的源站根路径发 HEAD 健康检查源站必须响应。文档对这次检查的定位是确认源可达性投递失败的兜底路径是队列重放别把这次 HEAD 当成运行时存活探针用接收端挂没挂要靠自己的监控去看。目标名由变量后缀决定_PRIMARY创建名为 primary 的目标换后缀可以并列多个每条审计记录扇出给所有启用的目标一个目标失败不影响其他。除了 webhook还支持 Kafka、MQTT、MySQL、PostgreSQL、NATS、Redis、AMQP、Pulsar 九类目标族接 SIEM 或日志平台都有现成的路。它和事件通知Bucket Notifications容易混通知按桶配规则支持事件和前后缀筛选服务的是上传完成就触发解析这类应用流程审计目标没有按目标的筛选器全集群的请求活动一视同仁地投。一个是给程序的事件流一个是给安全的记录流别混着配。两个细节决定审计靠不靠谱。一是队列目录配上QUEUE_DIR后投递失败有落盘重放兜底不配则没有官方审计文档明说这是决定 replay 能力是否启用的开关。二是环境变量管理的目标改不了通过环境变量定义的目标不能在控制台或管理 API 里编辑删除要变更就改变量重启进程运维流程要按这个来。监控侧给审计链路配两个信号就够队列目录的磁盘占用有QUEUE_LIMIT兜底但别让它真用上和接收端的健康探测任何一个持续异常都说明投递链路出了问题比 SIEM 那头发现日志断了早得多。审计记录里有什么请求路径、查询参数、选定的请求头、身份声明、access key 标识、来源主机、User-Agent、响应状态和错误。字段面向安全调查裁剪够 SIEM 用。目标侧还有几个可配项值得知道RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY限定队列里最多攒多少条记录内网部署可以配客户端证书三件套CLIENT_CERT、CLIENT_KEY、CLIENT_CA走双向 TLS比单靠 Bearer token 多一层身份校验。审计不覆盖的那段HTTP 层的性能账审计的定位是安全与合规它不承诺给你算性能的东西单请求耗时、响应字节数、按客户端统计的延迟分布这些字段不在设计目标里。做容量规划、查慢请求都集中在哪个桶要的是另一种日志。这一段在网关层补。生产部署前面本来就该有 NginxTLS 终结、限流都在那访问日志顺路就有了log_format s3ops $remote_addr [$time_local] $request $status $body_bytes_sent $http_user_agent rt$request_time urt$upstream_response_time bucket_host$host; access_log /var/log/nginx/rustfs_access.log s3ops; location / { proxy_pass http://rustfs_backend; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }$request_time是 Nginx 侧看到的总耗时$upstream_response_time是 RustFS 的处理耗时两者一减就是网关自身的开销。有个例外要认识客户端提前断开时状态码是 499此时 Nginx 已经断开了与后端的连接$upstream_response_time会是空值请求甚至可能压根没转到 RustFS。这类日志是客户端放弃的信号排查时别把它归到存储头上。顺手再配两件小事。一是请求 ID加一行proxy_set_header X-Request-Id $request_id把网关生成的 ID 带给 RustFS同一次请求在两份日志里就有了对得上的锚点查慢请求先在网关日志定位再拿 ID 对审计记录里的身份和操作。这行写法顺带解决了一个隐患proxy_set_header是替换语义客户端就算自带同名请求头到了后端也会被$request_id覆盖日志锚点的生成权收在网关手里。二是轮转这是请求级日志量随流量走logrotate 按天切割加压缩保留期和日志平台的摄入策略事先对好别让网关本机盘先满。日志拉进现有的日志平台慢请求、按桶的流量分布、客户端排行都从这份数据出。网关这层还能顺手做两件存储做不到的事按客户端限流limit_req挂在 location 上以及在 RustFS 维护窗口时切备用 upstream 做优雅摘流。日志和流量控制都在同一层这也是把网关留在链路里的理由之一。一张表分清两条路审计目标网关访问日志回答的问题谁在什么时候动了什么每个请求花了多久、传了多少关键字段身份、access key、操作、状态耗时、字节数、来源 IP去向SIEM、Kafka、数据库日志平台、时序分析排障时定位“这次删除是谁做的”“这批请求为什么慢”两条路不互相替代。审计记录里有来源主机但流量过了网关之后 RustFS 看到的是网关的 IP真实客户端地址要靠X-Forwarded-For传递并在网关日志里留存反过来网关日志没有身份信息SigV4 签名的解析在 RustFS 侧。合起来才是完整的请求画像。X-Forwarded-For 还有一条安全边界要守住这个头的内容客户端可以随便写$proxy_add_x_forwarded_for只是把网关看到的地址追加在尾部原有部分原样透传。可信的只有受信任网关追加的那一段所以 RustFS 的端口要对网关以外的来源封禁不能让客户端绕过网关直连后端否则来源 IP 在两份日志里都可以被伪造审计记录的合规效力跟着打折。分两步上线先审计后网关先接审计目标官方能力四行配置加一个队列目录接之前跟接收端约定好保留期限审计记录里有身份和来源信息留存策略要按合规要求定。验证方式就是文档里那句通过一次 S3 请求确认投递再在 Nginx 上加这份日志格式不需要动 RustFS 的任何配置。桶访问日志如果后续进了官方的已测试列表再做一次评估补齐即可。在那之前这两条已经把安全审计和性能观测两头的需求都接住了。上线节奏建议两步分开先让审计目标跑一周确认队列目录的磁盘占用和投递成功率都稳再动网关的日志格式。两件事一起上出了问题分不清是谁的。上线检查项里再补一条时钟同步网关日志的时间戳来自 Nginx 机器的系统时钟审计记录的时间来自 RustFS 节点两边机器都进 NTP。跨机器用 request_id 关联两份日志时时钟偏差会把对齐变成猜谜先同步时钟再谈排查。审计目标的环境变量清单、QUEUE_DIR的行为说明都在官方文档的审计日志章节RustFS 1.0.0 于 2026 年 9 月 16 日发布源码在 GitHub 的 rustfs/rustfs 仓库。Nginx 侧用到的几个日志变量都是发行版自带的功能参数细节在 nginx.org 文档的 log 模块页。