RustFS KMS 可观测性运行手册指标、告警规则与排障流程全解析【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs导读本文是 RustFS 集群中 KMS密钥管理服务可观测性的完整操作指南适用于以下三类场景Kms*系列 Prometheus 告警触发本文件正是这些告警的runbook_url目标、基于 KMS 指标自行构建 Dashboard 与告警、以及节点重启后 KMS 报出 not-configured 时的排查。读完本文你将掌握 RustFS KMS 全部 20 个指标族的语义与标签设计、7 条内置告警规则的阈值与表达式、每条告警的分步排障流程以及持久化配置启动加载的日志与服务状态对照方法。文中所有指标名称、标签值、阈值均与仓库源码及告警规则文件逐一核对可直接作为你运维和二次开发的基础。事实来源告警名称与阈值的权威定义在 .docker/observability/prometheus-rules/rustfs-kms-alerts.yml后端操作指标在 crates/kms/src/policy.rs其余各族的发射点分别为 crates/kms/src/cache.rs、crates/kms/src/deletion_worker.rs、crates/kms/src/backends/vault_credentials.rs、crates/kms/src/probe.rsDashboard 文件为 deploy/observability/grafana/rustfs-kms-observability.json。指标参考Metric Reference在展开所有指标族之前先记住一条贯穿全篇的硬性约束所有指标族的标签值都来自有界枚举或固定调用点令牌——key 标识符、密钥材料、密文、路径和令牌绝不会出现在指标标签中任何试图增加此类标签的改动都是一次回归。这条约束在 crates/kms/src/policy.rs 的注释中以同样的措辞被强制约定也是你评审 KMS 可观测性改动时的第一道防线。后端操作指标Backend Operation Metrics六条后端操作指标全部在唯一的操作策略咽喉点operation-policy choke point发射即 crates/kms/src/policy.rs 中的execute/execute_with_jitter执行链——每个被插桩的 KMS 后端调用都必然流经这里。这意味着给一个新调用点加埋点的成本仅仅是给它的操作起个名字。指标类型标签含义rustfs_kms_backend_operations_totalcounterbackend,operation,op_class,outcome在操作策略下执行的操作数每个终结结局计数一次rustfs_kms_backend_attempt_failures_totalcounterbackend,operation,error_class单次失败的尝试数包括随后被重试策略吸收的尝试rustfs_kms_backend_operation_duration_secondshistogrambackend,operation,outcome整个操作含重试与退避睡眠的墙钟时长rustfs_kms_backend_operation_attemptshistogrambackend,operation,outcome一次操作完成前消耗的尝试次数rustfs_kms_backend_in_flightgaugebackend,scope准入admission后当前在途的外部后端尝试数rustfs_kms_backend_circuit_opengaugebackend,scope打开或半开的熔断器数0表示关闭各标签的取值域如下标签取值backendvault-kv2、vault-transit、aws、vault-restorerestore 对 Vault bundle 信任根发起的调用。操作名在各后端间共享每个后端都有decrypt因此该标签能区分 Transit 的延迟回归与 AWS 的延迟回归。Vault 凭据的 login 与 renewal 上报各自后端的名字靠operation区分scope标签只出现在两个 gauge 上。Local 与 Static 后端从进程内存服务不进入操作策略不产生任何backend序列outcomesuccessfatal首次观察即为不可重试失败budget_exhausted可重试失败耗尽尝试预算deadline_exceeded操作期限在另一次尝试完成前耗尽backpressure_timeout期限在容量准入前耗尽backpressure_rejected活跃容量与有界队列均满或不可用circuit_open可重试失败打开了熔断器或打开的熔断器拒绝操作cancelled关闭或调用方取消op_classread_idempotent可安全重试mutating_non_idempotent绝不重放——可重试失败在 1 次尝试后即终止因为服务器可能已处理该请求authlogin 与 token 续期error_classretryable_conn拨号、TLS、连接中断retryable_status可重试的后端状态如 Vault 5xx 或已密封 Vault 的 503attempt_timeout单次尝试超时按连接失败方式重试fatal认证、权限、畸形请求、缺少 key 或版本operation各调用点固定的静态名例如vault_kv2_read_key_version、vault_kv2_cas_write_key、vault_transit_encrypt、vault_transit_decrypt、vault_login、vault_token_renew从源码看execute的每一次执行都会调用record_operation写入 operations counter 与两个 histogram并在失败时调用record_attempt_failure见 policy.rs。error_class的分类由classify_status与classify_vaultrs完成429/500/502/503/504归为retryable_status其余状态一律fatal——特别强调400/401/403/404 绝不重试见 policy.rs。准入共享遵循两条边界后端总活跃容量按后端身份共享上限为DEFAULT_MAX_CONCURRENT_OPERATIONS源码中为 64见 policy.rs普通操作最多可使用该值减去RESERVED_CREDENTIAL_OPERATIONS1因此 login 与 renewal 始终保留一个准入槽位。每个后端配置代configuration generation都拥有自己全新的一套有界队列与熔断器policy scope因此一个失败的重新配置候选无法继承或篡改运行中那一代的准入状态。埋点边界Local 与 Static 后端不流经咽喉点不产生操作指标。在一个使用这些后端的集群上这六条序列缺失是预期行为而非故障。下面各指标族位于后端层之上无论使用何种后端都会发射。密钥元数据缓存指标Key Metadata Cache Metrics由所有后端共享的 manager 级密钥元数据缓存发射crates/kms/src/cache.rs。发布由缓存的enable_metrics设置门控该设置默认开启见 config.rs 中enable_metrics: true的默认值且没有任何 configure 请求字段能修改它——因此实践中这些指标总是发布。无论开关如何admin 状态 API 背后的原子计数器都会照常维护见 cache.rs。指标类型标签含义rustfs_kms_metadata_cache_lookups_totalcounterresult密钥元数据查询数按hit或missrustfs_kms_metadata_cache_evictions_totalcountercause从缓存丢弃的条目数按移除原因rustfs_kms_metadata_cache_entriesgauge—缓存当前持有的条目数cause含义expiredTTL——真正的驱逐size容量——真正的驱逐explicit被密钥生命周期操作失效持续上升是生命周期流量而非缓存压力replaced被更新值覆盖与explicit解读相同条目 gauge 从每个写路径以及查询未命中处重新发布因为 TTL 过期会在没有任何写操作的情况下丢弃条目一个完全空闲的缓存可能持有陈旧值直到下一次查询。注意此缓存只服务密钥元数据读取如describe_key——encrypt、decrypt 与数据密钥生成从不查询它所以低命中率不是数据路径问题。密钥生命周期指标Key Lifecycle Metrics由后台删除工作者deletion worker见 crates/kms/src/deletion_worker.rs在每次清扫sweep结束时发布数值直接来自清扫已经遍历的分页。工作者只在能力集包含schedule_deletion的后端上运行因此在不具备该能力的后端上部署时这些指标一条都不会发射。指标类型标签含义rustfs_kms_pending_deletion_keysgauge—已排期删除且期限未到的 key 数rustfs_kms_deletion_tombstone_keysgauge—被中断的删除留下的墓碑tombstonekey 数仍在等待清扫rustfs_kms_oldest_key_rotation_age_secondsgauge—距最近轮换的可用 key 已轮换的秒数无轮换记录时按创建时间起算没有可用 key 时为0rustfs_kms_max_key_wrap_operationsgauge—可用 key 中最大的预留 wrap 操作计数仅由统计 wrap 的后端Vault KV2发布rustfs_kms_deletion_sweep_keys_totalcounteroutcome清扫处理的 key 数按结局outcome含义removed材料已销毁blocked活跃配置默认 key或被注入检查器上报的引用仍指向该 key清扫拒绝移除skipped尚未到期或检查与移除之间状态已变化failed移除尝试失败下次清扫重试。列表本身失败时也会上报不带 key idunreadable后端列出了本构建无法描述的 key 记录——由更新构建写入或材料损坏每个序列从第一次清扫起就以 0 发射因此对它的rate()立即可定义。非零的unreadable速率不会停止清扫但会使该轮的生命周期 gauge 停止发布——因为对部分可读的 key 集做普查会低估持续的unreadable因而表现为 gauge 停止推进——在重新信任 rotation-age 或 pending-deletion 读数之前先去调查清扫日志行中点名的 key id。当完整列表中没有任何可读 key 时后端直接让列表失败见 key listing contract清扫以outcomefailed上报列表错误且不点名任何 key idfailed攀升而unreadable保持为零、gauge 冻结意味着该节点上整个 key 集不可读——可能是混合版本节点或一个打不开任何记录的凭据。Gauge 只由看到完整 key 集的清扫重新发布已经在删除途中的 key 不计入 rotation-age 与 wrap gauge。rustfs_kms_max_key_wrap_operations追踪 Rotation drivers and scheduling, per backend 中描述的 AES-GCM wrap 上限。该值是基于预留reservation的近似值设计上会高估节点从 key 记录中以每块一百万的数量预留 wrap 预算仅在内存中统计单个 wrap因此崩溃只会丢弃未使用的预算永远不会丢弃已计数的 wrap。当它接近 2^32 时应告警并轮换 key。它会在两种有界、有日志记录的情况下低估预留写入持续失败的节点会在 warn 日志Vault KMS wrap budget reservation failed下继续 wrap混合版本窗口期旧构建重写 key 记录时丢弃该字段见 mixed-version notes。Transit 与 AWS 在 KMS 内部完成 wrapLocal/Static 无法轮换因此它们都不发布此序列。轮换年龄来自后端上报的最后轮换时间只有 Vault KV2 持久化该时间戳——它在提交轮换的同一次 check-and-set 写入中盖上见 crates/kms/src/backends/vault.rs。Vault Transit 与 AWS KMS 不记录任何轮换时间因此在这些后端上每个 key 永远按创建时间起算gauge 度量的是 key 年龄而非轮换年龄轮换不会重置它。KV2 上在时间戳存在之前轮换过的 key 同样按创建时间起算直到下次轮换。在所有情况下 gauge 都高估而非编造所以基于它的告警只会早触发不会晚触发。Vault 凭据指标Vault Credential Metrics由 Vault 凭据提供者crates/kms/src/backends/vault_credentials.rs发布因此仅存在于 Vault 后端的部署上。两者都是无标签的要描述的凭据代恰好只有一个且 Vault 地址、mount、认证路径和 token 都不能作为标签值出现。指标类型标签含义rustfs_kms_vault_token_ttl_secondsgauge—活跃 Vault token 到期前的剩余秒数过期后为0rustfs_kms_vault_credentials_fail_closedgauge—提供者处于 fail-closed 安全窗口内、拒绝发放 token 时为1否则为0续期循环在等待期间以10 秒节奏源码CREDENTIAL_GAUGE_INTERVAL Duration::from_secs(10)见 vault_credentials.rs重新发布两个 gauge不产生额外 Vault 流量。rustfs_kms_vault_credentials_fail_closed为1是 Vault KMS authentication runbook 所述 fail-closed 窗口的指标形态窗口期间Vault 后端操作宁可失败也不愿运行在一个可能已经失效的凭据上。合成探针指标Synthetic Probe Metrics由后台探针工作者crates/kms/src/probe.rs发布它在一个保留探针 key 下生成一个数据密钥解密它并比对密钥材料。它每RUSTFS_KMS_PROBE_INTERVAL_SECS秒运行一次默认DEFAULT_PROBE_INTERVAL即 60 秒被抬升到MIN_PROBE_INTERVAL5 秒的下限0禁用探针见 probe.rs 与parse_interval的取值逻辑发布的状态就是 KMS 就绪readiness读取的内容。指标类型标签含义rustfs_kms_probe_rounds_totalcounterresult完成的探针轮数按success、failure或unsupportedrustfs_kms_probe_failures_totalcounterfailure_kind失败的轮数按失败发生的往返阶段rustfs_kms_probe_duration_secondshistogramresult一轮探针的墙钟时长rustfs_kms_probe_last_success_timestamp_secondsgauge—最近一次成功轮次的 Unix 时间戳rustfs_kms_probe_consecutive_failuresgauge—自上次成功以来连续失败的轮数failure_kind含义key_provisioning探针 key 无法被描述或创建generate数据密钥生成失败decrypt解密失败mismatch两个调用都成功但材料未存活过往返——严重程度等同一次宕机unsupported表示后端无法承载探针 keyAWS KMS 后端拒绝调用方命名的创建。它被计为独立的结果从不计为失败且工作者在记录后即停止测试unsupported_backend_stops_the_worker_without_cancellation验证了该行为见 probe.rs因此此类部署上失败计数器告警保持静默。rustfs_kms_probe_last_success_timestamp_seconds只在成功时向前移动所以探针失败期间它的年龄持续增长——请对年龄告警而不是对失败计数器的存在告警。导出路径metricsfacade 喂给 crates/obs 中的 OTel recorder经 OTLP 导出到被 Prometheus 抓取的 collector。因此直方图在 Prometheus 中以_bucket/_sum/_count序列出现。以上所有指标都不携带节点观测 Dashboard 使用的 RustFSserver标签——请通过抓取拓扑job/instance或提升的 OTel 资源属性如service_instance_id区分节点。Dashboard将 deploy/observability/grafana/rustfs-kms-observability.json 导入 Grafana并选择一个抓取 RustFS 指标的 Prometheus 数据源。Dashboard 有两个变量datasource与operation对operation标签的多选。在 docker-compose 观测栈.docker/observability/中Dashboard 通过目录方式供应grafana/provisioning/dashboards/dashboard.yml指向/etc/grafana/dashboards因此无需逐文件注册。出厂 Dashboard 只覆盖后端操作指标。其中的 Planned Panels (TODO) 文本面板已过时缓存、生命周期、Vault 凭据与探针指标族均已发射并在上文 指标参考 中记录。在该面板被替换前请临时查询这些指标族。参见 覆盖缺口。告警规则Alert Rules规则文件位于 .docker/observability/prometheus-rules/rustfs-kms-alerts.yml。docker-compose 的 Prometheus 加载/etc/prometheus/rules/*.yml所以.yml扩展名是起作用的——改名会导致文件被静默忽略。修改后用promtool check rules rustfs-kms-alerts.yml校验。文件内 7 条规则分为两个组rustfs-kms-critical2 条 critical 级与rustfs-kms-warning5 条 warning 级求值间隔均为 30s。完整规则摘要如下告警严重级表达式核心forKmsBackendFatalErrorscriticalrate(rustfs_kms_backend_attempt_failures_total{error_classfatal}[5m]) 05mKmsBackendHighErrorRatecritical非成功 outcome 占比 0.05且总速率 0.02ops/s流量守卫10mKmsBackendP99LatencyHighwarninghistogram_quantile(0.99, sum by (le)(rate(..._duration_seconds_bucket[5m]))) 210mKmsBackendAttemptFailureSpikewarningsum(rate(rustfs_kms_backend_attempt_failures_total[5m])) 0.510mKmsBackendRetryBudgetExhaustedwarningrate(..., outcome~budget_exhausted|deadline_exceeded) 0.0510mKmsBackendCircuitOpenwarningrustfs_kms_backend_circuit_open 0直接 gauge 状态1mKmsKeyRotationOverduewarningrustfs_kms_oldest_key_rotation_age_seconds 400 * 864001h该文件中每个数字阈值都是未经过生产基线的保守默认值在把触发中的告警当作 SLO 违约、或把安静的告警当作健康之前请先阅读 阈值校准。告警响应流程Alert Response ProceduresKmsBackendFatalErrors含义尝试正以error_classfatal失败——策略永不重试的失败认证、权限、畸形请求、缺少 key/版本调用方此刻正在看到错误。这是信号最强的 KMS 告警健康系统中 fatal 失败不会作为背景噪音出现。按操作拆分速率sum by (operation) (rate(rustfs_kms_backend_attempt_failures_total{error_classfatal}[5m]))。如果失败操作是vault_login或vault_token_renewop_classauth说明 Vault 凭据无效或已过期。按 Vault KMS authentication runbook 处理——凭据刷新是 fail-closed 的坏凭据最终会拖垮所有 Vault 后端操作。查找Vault token renewal failed; falling back to a fresh login与Vault credential refresh failed; retrying until the credentials recover警告rustfs_kms_vault_credentials_fail_closed为1或rustfs_kms_vault_token_ttl_seconds接近或等于0可在不读日志的情况下确认该状态。如果失败操作是vault_kv2_*或vault_transit_*检查 Vault 权限拒绝把 token 的 policy 与 minimal policy 对比重新裁剪过的 policy 会产生归类为 fatal 的 403并检查 Vault 审计日志中的被拒请求。解密路径上的 fatalKeyVersionNotFound意味着某个 DEK 信封引用了记录缺失的 key 版本。解密刻意 fail-closed、无回退——见 retention and destruction preconditions确认没有人销毁过 key 子树下的版本记录。用结局视图确认爆炸半径sum by (operation) (rate(rustfs_kms_backend_operations_total{outcomefatal}[5m]))。相关信号Dashboard 的 Attempt Failure Rate by Error Class 与 Backend Operation Rate by Outcome 面板Vault 服务器审计与服务器日志加密桶上的 S3 5xx。KmsBackendHighErrorRate含义超过 5% 的 KMS 操作未成功终止fatal、budget_exhausted、deadline_exceeded、backpressure_timeout、backpressure_rejected或circuit_opencancelled被排除因为关闭窗口会合法地产生它。流量守卫在约 0.02 ops/s 以下抑制告警因此近空闲集群上的单次失败不会呼叫。按结局拆分失败sum by (outcome) (rate(rustfs_kms_backend_operations_total{outcome!~success|cancelled}[5m]))。若fatal占主导按 KmsBackendFatalErrors 处理。若budget_exhausted或deadline_exceeded占主导按 KmsBackendRetryBudgetExhausted 处理。若backpressure_timeout或backpressure_rejected占主导按backend与scope比较rustfs_kms_backend_in_flight总活跃容量按后端身份共享、为凭据刷新保留一个槽位每个配置代都有全新的 scope 本地有界队列。若circuit_open占主导按 KmsBackendCircuitOpen 处理。与客户端影响关联配置了加密的桶上加密对象 PUT/GET 失败与 S3 错误率。相关信号Non-Success Outcome Ratio 面板其他告警下列出的 KMS 相关警告。KmsBackendP99LatencyHigh含义KMS 操作的 p99 墙钟时长持续高于 2 秒。直方图包含重试与退避睡眠因此 p99 高而 p50 健康通常意味着慢重试尾部而非整体变慢。在 Operation Duration p50 / p99 面板对比 p50 与 p99。p50 平稳而 p99 抬升指向重试两者同时抬升指向后端或网络路径整体变慢。按后端与操作拆分histogram_quantile(0.99, sum by (le, backend, operation) (rate(rustfs_kms_backend_operation_duration_seconds_bucket[5m])))。检查 attempts 直方图平均值显著高于 1 确认是重试驱动的延迟对失败类别按 KmsBackendAttemptFailureSpike 处理。若非重试驱动检查到 Vault 的网络路径TLS 握手、DNS、代理以及 Vault 自身的遥测存储后端延迟、负载。此延迟嵌套在加密对象的 S3 请求延迟之内持续接近操作期限的 p99 会开始转化为deadline_exceeded结局。相关信号Operation Duration p99 by Operation 与 Operation Attempts Distribution 面板KMS backend attempt failed with a retryable error; backing off before retry警告字段operation、attempt、error_class、backoff。该日志由drive_attempts中的重试路径发射见 policy.rserror_class用?格式化以便直接对应指标标签。KmsBackendAttemptFailureSpike含义所有错误类别上的单次尝试以持续速率失败。重试策略可能仍在吸收它们——告警触发期间操作可以继续成功——但系统正在烧掉重试预算再小幅恶化就会浮出水面暴露给调用方。按类别拆分速率sum by (error_class) (rate(rustfs_kms_backend_attempt_failures_total[5m]))。retryable_conn网络层失败——检查连通性、TLS、DNS以及 Vault 是否宕机或重启中。retryable_status后端以可重试错误应答——检查 Vault 健康与密封状态密封的 Vault 返回 503以及 Vault 侧限流。attempt_timeout尝试被单次超时截断——要么后端慢与 KmsBackendP99LatencyHigh 关联要么配置的尝试超时对该网络路径过紧。fatal按 KmsBackendFatalErrors 处理。在 RustFS 日志中 grepKMS backend attempt failed with a retryable error; backing off before retry——结构化字段operation、attempt、error_class、backoff能定位哪些调用点在循环。相关信号Attempt Failure Rate by Error Class 面板attempts 直方图均值升过 1。KmsBackendRetryBudgetExhausted含义操作以budget_exhausted或deadline_exceeded终止——每一次单独失败都是可重试的但后端不健康的时间超过了重试策略能弥合的范围因此调用方收到了硬失败。识别失败操作sum by (operation) (rate(rustfs_kms_backend_operations_total{outcome~budget_exhausted|deadline_exceeded}[5m]))。从 attempt-failure 速率历史确定底层失败持续了多久按 KmsBackendAttemptFailureSpike 做类别特定的诊断。设计内案例mutating_non_idempotent操作如vault_kv2_cas_write_key、vault_transit_create_key从不重放因此单次可重试失败会在 1 次尝试后以budget_exhausted终止。仅限 mutating 操作的尖峰意味着写路径失败而非重试循环耗尽。deadline_exceeded与接近操作期限的 p99 聚集出现意味着预算花在了慢尝试而非快速失败上——先按延迟问题处理。确认客户端影响若后端故障是外部的Vault 宕机协调那边恢复——后端恢复后 RustFS 无需干预即可恢复。相关信号Backend Operation Rate by Outcome 面板重试退避警告Vault 可用性监控。KmsBackendCircuitOpen含义rustfs_kms_backend_circuit_open对某个backend与scope持续高于0达一分钟。这条直接 gauge 告警不依赖操作流量熔断器拒绝调用期间、以及单个半开恢复探针运行期间它都保持可见。从源码看熔断状态机policy.rs连续失败达到DEFAULT_CIRCUIT_FAILURE_THRESHOLD5时熔断器打开DEFAULT_CIRCUIT_OPEN_DURATION30 秒打开期过后下一个符合条件的操作是唯一的半开探针成功或不可重试失败关闭熔断器可重试失败重新打开。用rustfs_kms_backend_circuit_open 0识别受影响的 scope。按操作拆分近期拒绝sum by (operation) (rate(rustfs_kms_backend_operations_total{outcomecircuit_open}[5m]))。用sum by (error_class) (rate(rustfs_kms_backend_attempt_failures_total{error_class~retryable_conn|retryable_status|attempt_timeout}[5m]))区分传输失败、可重试后端响应如密封的 Vault与尝试超时。尝试超时按可重试连接失败计入熔断器。打开期过后下一个符合条件的操作是唯一的半开探针。成功或不可重试失败关闭熔断器可重试失败重新打开它。不可重试探针仍以fatal失败因此即使 gauge 清零也请按 KmsBackendFatalErrors 处理。不要为了清除状态而重启 RustFS。每个配置代都有全新的 scope 本地熔断器与队列状态而总活跃容量按后端身份共享、为凭据刷新保留一个槽位。即使其他 scope 的熔断器保持关闭也要检查它们的容量压力。相关信号Backend Operation Rate by Outcome 面板上的circuit_open、backpressure_timeout与backpressure_rejectedrustfs_kms_backend_in_flightVault 可用性与密封状态。KmsKeyRotationOverdue含义rustfs_kms_oldest_key_rotation_age_seconds——距最近轮换的可用 key 已轮换的秒数无轮换记录时按创建起算——已高于 400 天达一小时。这是合规与卫生信号而非宕机加解密不受影响地继续RustFS 内没有任何东西基于该判定行动。轮换重要的原因爆炸半径以及 RustFS 本地 wrap DEK 后端上的 AES-GCM wrap 上限在 Rotation drivers and scheduling, per backend 中统一阐述。找出哪些 key 到期。gauge 刻意不点名任何 key因此从列表读取逐 key 判定GET /rustfs/admin/v3/kms/keys的每个 key 携带rotation_due与rotation_due_reasonage、never_rotated、wraps或unsupported依据RUSTFS_KMS_ROTATION_MAX_AGE_SECS与RUSTFS_KMS_ROTATION_MAX_WRAPS环境变量常量定义见 crates/kms/src/config.rs计算——见 Rotation readiness。wraps原因不能靠放宽年龄阈值满足。若RUSTFS_KMS_ROTATION_MAX_AGE_SECS未设置把它设为你策略的轮换周期使逐 key 判定与本告警一致。若原因是unsupported该后端完全无法轮换Local、Static唯一应对是后端迁移。在可轮换的后端上按 Rotation drivers and scheduling, per backend 的驱动矩阵行动——Vault KV2 用外部调度器、Vault Transit 用auto_rotate_period、AWS KMS 用 AWS 自动轮换——并先满足其轮换前检查清单首先是 upgrade-ordering hard constraint。绝不要在滚动升级中途响应此告警去轮换。知道该 gauge 在 Transit 与 AWS 上的盲区只有 KV2 持久化轮换时间戳因此 Transit 与 AWS 的 key 永远按创建时间起算年龄在那里轮换后此告警不会清除。在属主系统确认真实节奏Transit key 的版本历史或 AWS 中 key 的轮换状态并把已确认健康的节奏视为该 gauge 的已知高估。若 KV2 key 确实轮换过而 gauge 仍高记住 gauge 只由看到完整 key 集的清扫重新发布检查rustfs_kms_deletion_sweep_keys_total中unreadable或failed结局是否冻结了生命周期 gauge见 密钥生命周期指标并确认删除工作者本身在运行——它只在具备schedule_deletion能力的后端上运行这也是 Static 后端从不发射此序列的原因。相关信号key 列表上的rotation_due/rotation_due_reasonrustfs_kms_deletion_sweep_keys_total{outcome~unreadable|failed}冻结的 gauge 是陈旧而非健康。启动持久化配置加载Startup Persisted-Configuration Load通过 admin API 配置的 KMS 会持久化到集群存储并在每次启动时恢复。加载结果在两个地方可见在断定 KMS 从未配置过 之前两处都要检查启动日志eventkms_persisted_config_lookuptarget: rustfs::initGET /rustfs/admin/v3/kms/service-status含义与行动statefoundconfigured持久化配置已加载并应用statenot_foundNotConfigured没有持久化内容从头配置是正确的应对stateload_failedError(Failed to load persisted KMS configuration: ...)或Error(Failed to apply persisted KMS configuration: ...)配置存在但读取、解封或解码失败。不要重新提交完整配置使用 reload这三个状态的发射点位于 rustfs/src/init.rs启动逻辑先在命令行配置与持久化配置之间二选一config.kms_backend非空时走命令行否则走持久化加载加载成功/未找到/失败分别打statefound/not_found/load_failed日志。要从load_failed恢复——或从任何服务器运行但其内存 KMS 落后于持久化配置的状态恢复——调用POST /rustfs/admin/v3/kms/reload需要kms:ServiceControl。它会从集群存储重新读取持久化配置并重新配置服务无需重新提交机密然后把 reload 广播给对端节点。若 reload 持续失败先检查集群存储健康读取需要法定人数再检查RUSTFS_KMS_CONFIG_SECRET解封错误意味着机密缺失或与封存持久化副本时不一致——它必须在每个节点上完全相同。另有一个独立事件kms_config_load_skipped且reasonstorage_uninitialized来自对端 reload RPC 路径使用的环境加载器见 rustfs/src/admin/handlers/kms_dynamic.rs在 peer reload 之外看到它说明请求到达时存储初始化尚未完成。阈值校准Threshold Calibrationrustfs-kms-alerts.yml中每个数字流量或延迟阈值5% 错误率、2s p99、0.5/s 尝试失败、0.05/s 预算耗尽都是未经生产基线的保守默认值偏向于不对健康但繁忙的系统呼叫。在依赖这些告警呼叫之前在 staging 运行负载至少一周记录上文表达式的稳态值然后把阈值收紧到明显高于观测峰值的位置。KmsBackendCircuitOpen不同它的 gauge 是直接状态一分钟的 hold 只抑制立即恢复的熔断器。KmsKeyRotationOverdue则相反400 天阈值是高于常见一年轮换周期的策略默认值——请对照合规策略要求的轮换周期与RUSTFS_KMS_ROTATION_MAX_AGE_SECS校准而不是对照 staging 基线。一旦存在稳定基线可考虑把KmsBackendAttemptFailureSpike转换为基线相对形式offset 1d比值参考 .docker/observability/prometheus-rules/rustfs-get-optimization-alerts.yaml 的模式。在该基线存在之前KMS 操作的正式 SLO 目标刻意不在范围内告警文件头部注释亦注明见 rustfs-kms-alerts.yml。覆盖缺口Coverage Gaps缓存、Vault 凭据与探针指标族没有 Dashboard 面板、没有告警规则生命周期族只有 KmsKeyRotationOverdue。基于它们构建是安全的上面的名称与标签值就是代码实际发射的内容。Local 与 Static 后端不发射操作指标因为它们不流经操作策略咽喉点。它们的缓存指标正常发射。在生产基线存在之前没有正式 SLO 目标——见 阈值校准。相关文档Related DocumentsKMS backend security properties — 后端信任边界、最小 Vault 策略、轮换驱动与保留前置条件。Vault KMS authentication runbook — 凭据来源、刷新行为与 fail-closed 窗口。KMS admin API contract — 端点动作与 key 列表契约。deploy/observability/README.md — 所有 RustFS Dashboard 的导入说明。【免费下载链接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.项目地址: https://gitcode.com/GitHub_Trending/rus/rustfs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考