可观测性运维后端【免费下载链接】PulseReal-time monitoring dashboard for Proxmox VE, PBS, Docker, Kubernetes, TrueNAS and vSphere. Self-hosted, with smart alerts and AI patrols that catch silent failures.项目地址https://gitcode.com/gh_mirrors/pulse27/Pulse点击查看免费下载本文基于 Pulse 仓库中的已知 RC 问题关闭记录known-rc-issue-closure-for-ga-pbs-health-authority-2026-07-24.md还原 Proxmox Backup ServerPBS连接健康状态的完整修复链路从#1465的「Settings 显示 Active、Dashboard 显示错误」矛盾出发剖析根因、修复设计、场景覆盖与验证命令帮助你理解 Pulse 如何把一次轮询错误定稿并一致投影到调度器台账、Dashboard、连接聚合、Fleet 治理、告警与诊断等多个消费面。一、问题背景同一个 PBS 系统Settings 与 Dashboard 状态互相矛盾Issue#1465描述了这样一个现场两个已配置的 PBS 系统在 Settings 中显示为Active / Fleet OK但 Dashboard 同时将两者渲染为错误状态并且「保存的连接测试」Saved Test Connection也失败。三处界面各说各话运维人员无法判断 PBS 到底是否可达。这条记录指出该矛盾的根因在v6.0.0-rc.4时代就已埋下deferred poll accounting延迟轮询记账在轮询真正执行之前捕获了一个 nil error。提交bf6261adc和bd7d196c1修正了这次捕获并且是v6.1.1的祖先提交。但 Release-tag 重放release-tag replay证明这个修正必要但不完整。在v6.1.1上重放测试时出现了两类残留问题认证分支早退v6.1.1会在调度器台账scheduler ledger中记录一次认证失败但认证分支在返回之前没有更新 Dashboard 的 PBS 模型导致台账有错误、Dashboard 仍显示在线。连接聚合器的乐观投影connections aggregator 只要存在更早的成功记录、且熔断器circuit breaker未打开就把新出现的超时当作 Active。而同一个当前错误本来就定义为「未决状态」outstanding state会在下一次成功时被清除——于是 Active 投影与 Dashboard、台账三者互相矛盾。二、修复设计Disposition一次轮询错误全局一致投影修复的核心思路可以概括为一句PBS 轮询把单个动态轮询错误定稿finalize并将该结果投影到所有健康消费面。具体而言修复后的 PBS 轮询会把结果写入以下七处调度器台账scheduler ledger陈旧度跟踪staleness tracking轮询指标poll metrics连接健康映射connection-health mapDashboard 的 PBS 模型遗留 PBS 告警评估legacy PBS alert evaluation在 monitor_pbs_pmg.go 的实现中可以看到这套「定稿 投影」的骨架pollPBSInstance用defer统一收口pollErr无论轮询成功、panic 恢复还是普通返回都依次执行recordTaskResult写入调度器台账、stalenessTracker.UpdateSuccess/UpdateError更新陈旧度、publishPBSConnectionOutcome发布连接结果以及pollMetrics.RecordResult记录轮询指标。2.1 错误分类认证、超时、取消、初始化、panic 一致发布 offline/error修复后认证authentication、超时timeout、取消cancellation、初始化initialization、panic 五类失败都会一致地发布为 offline / error不再出现「台账记了错、Dashboard 却还显示在线」的分裂。panic 场景在 defer 中被recover()捕获并转换为普通轮询错误panic while polling PBS instance %q: ...从而进入同一条错误定稿链路。2.2 部分数据失败 ≠ 连接失败连接性与数据收集解耦与「连接性失败」严格区分的是可选项收集失败节点node数据存储datastore命名空间namespace任务/作业job这些可选项的采集失败被视为部分数据证据partial data evidence不会把已被验证的连通性proven connectivity转换成连接失败。换句话说版本探测成功但 datastore 清单拉取失败时连接仍是 Connected部分数据而不是 offline。这一点在测试 TestPollPBSInstanceKeepsPartialDataSeparateFromConnectivity 中得到印证fixture 在/api2/json/admin/datastore返回 503 时连接健康映射仍为 connected、Dashboard 状态仍为 online同时已发布的数据存储清单为空——不伪造任何数据行。TestPollPBSNodeMetricsFailureAndRecovery同文件 L361-L421则进一步刻画了「指标不可用」与「连接性」的分离节点端点返回 403/502 时NodeMetricsUnavailabletrue、指标归零但连接台账不受影响只有完整不可用503才被独立记录为一次连接失败。2.3 客户端创建与重试重建不再预支「连接成功」修复后客户端创建和重试重建不再在轮询发生前声称连通。两条规则非常清晰无效初始化立即记录并发布一个失败结果failed outcome。成功构建保持 pending直到第一次完整轮询完成才转为 online。对应测试 TestInitPBSClientsDoesNotTreatClientConstructionAsConnectivity 验证对https://backup.local:8007这类合法地址initPBSClients成功构建 client 后连接健康映射与pollStatusMap中都不应出现connected 或已完成的轮询记录而对://not-a-url这类非法 URL则会在台账中留下一次当前失败ConsecutiveFailures 1并投影为 offline。三、connections API 的派生规则当前错误优先于历史成功连接聚合器connections aggregator是 Settings 统一连接台账的构建者核心实现在 connections_aggregator.go 的deriveConnectionState。修复后的派生规则可以总结为一张状态表输入信号派生状态说明Disabledpaused用户暂停reason 为 paused by user无 LastSuccess 且无 LastErrorpending等待首次轮询当前 LastError 匹配认证错误模式unauthorized见下方认证错误正则存在当前 LastErrorunreachable即使 LastSuccess 仍在熔断器 openunreachablereason 为 circuit breaker open 或错误消息超过陈旧阈值stale阈值随轮询间隔缩放其余情况active—关键变化在于任何当前的LastError都被视为不可达unreachable认证错误则视为未授权unauthorized即使LastSuccess被保留下来作为新鲜度上下文freshness context。这正是对「有历史成功就把新超时算作 Active」这条旧逻辑的修正。认证错误判定由一个集中式正则完成connections_aggregator.govar connectionAuthErrorPattern regexp.MustCompile( (?i)401|403|unauthori[sz]ed|forbidden|authentication|permission denied|invalid (credentials|token|api key), )这个正则被所有连接类型共享确保「凭证错误 / token 缺权限」在各类型间以同样的方式派生出unauthorized。3.1 陈旧阈值随轮询节奏自适应为避免健康连接因单个丢失的 tick 而被误判为 stale聚合器设置了基础阈值connectionStaleThreshold 2 * time.Minuteconnections_aggregator.go并对慢节奏轮询按max(3 × interval, 2min)缩放connectionStaleThresholdFor。注释解释了 3× 而非 2× 的原因连接降级告警与轮询在同一调度 tick 上并发评估健康连接的 LastSuccess 在评估时通常已经「过期」一个完整间隔2× 会抖动。此外自适应轮询adaptive polling拉长的计划间隔也会通过effectivePollInterval参与阈值计算关联问题#1437避免健康连接在整个拉伸周期后半段被误判为 stale。3.2 同主机名的双 PBS按实例独立记账Issue#1465的场景之一是「两个共享同一 hostname 的 PBS 系统」。修复后连接行按配置实例名pbs::name独立聚合不会因为地址相同而合并。测试 TestBuildConnectionsKeepsDistinctPBSSystemsWithSameHostname 使用两个 Name 分别为pbs-east、pbs-west、Host 均为https://backup.local:8007的实例验证聚合结果仍为两行独立连接pbs-east无错误 →activepbs-west有超时错误 →unreachable且两份告警快照都保留。聚合器还支持通过pbsReportedNodeNames把节点自报的 hostname 并入 HostAliases用于 host agent 身份归并。3.3 Fleet 治理与连接告警消费同一行文档明确指出Settings 的 Fleet 治理Fleet governance和连接告警消费的是同一条连接行同一份Connection派生结果而不是各自再算一遍。Fleet 状态字段EnrollmentState、LivenessState、AdapterHealth、CredentialStatus 等在 connections_types.go 定义均由deriveConnectionFleetGovernance从连接状态派生其中 LivenessState 直接等于连接行状态string(conn.State)AdapterHealth 在unauthorized/unreachable时对应blocked从而让 Fleet 与 Dashboard 必然对齐。四、诊断与即时探测分离两种「连通」不再混淆修复后诊断Diagnostics把两类信息分开暴露canonical monitored state权威监控状态来自调度器轮询的持久健康事实immediate support probe即时支持探测点击诊断时现场发起的连通性探测。当两者不一致时例如监控侧显示 unreachable但即时探测成功Settings 的诊断行会同时具名展示两者而不是让一次成功的即时探测覆盖掉权威状态。测试 TestPBSDiagnosticsKeepsCanonicalPollStateSeparateFromLiveProbe 演示了这一规则连接行携带当前错误connection timed out派生出unreachable即使PBSDiagnostic.Probe.Connected true即时探测成功、版本 3.4.2最终诊断状态仍保持unreachable但Probe.Connected证据被保留LastSeen仍是之前的 LastSuccess。五、Saved Test Connection隔离的凭证/网络探测不污染运行时健康「保存测试连接」Saved Test Connection被明确定义为一次隔离的凭证/网络探测不修改任何运行时健康状态——不写调度器台账、不动连接健康映射、不触发告警。测试 TestHandleTestNodePBSIsADirectProbeWithoutChangingRuntimeHealth 提供了完整的自动化证明构造一个使用rotated-secret的 PBS 实例配置记录测试前的SchedulerHealth()与GetConnectionStatuses()调用POST /api/config/nodes/pbs-0/test断言请求的 Authorization 头携带当前存储的 tokenrotated-secret断言测试后SchedulerHealth的 Instances/Breakers/Staleness 与GetConnectionStatuses与测试前逐字段相等。也就是说你可以随时验证凭证是否有效而不必担心这次验证把健康状态「探活」成 online。六、场景覆盖托管式双 PBS HTTP fixture文档中的「Scenario Proof」列出了修复必须覆盖的场景这些场景由托管式双 PBS HTTP fixturemanaged dual-PBS HTTP fixture与 API 投影测试共同覆盖具体包括两个独立凭证key、共享同一 hostname 的 PBS 系统初始成功 → 认证拒绝 → 网络超时的状态演变当前失败期间保留 last-success 新鲜度版本探测成功 datastore 清单失败 → Connectedpartial data凭证轮换、URL 替换、监控重启与恢复无效 URL 初始化与首次轮询 pending 行为Settings / API / Fleet、Dashboard、告警快照alert-snapshot、诊断投影的一致性使用当前存储 token 的直接保存连接测试且不改变调度器或连接健康。在测试实现中fixturemonitor_pbs_health_authority_test.go通过atomic模式位支持 success、auth-failure、timeout、partial-data、node-denied、node-gateway-failure、unavailable、low-memory、null-node-status 等十余种服务端行为并支持requireToken模拟凭证轮换主流程测试 TestPollPBSInstancesKeepsAllHealthProjectionsOnOneOutcome 完整走了一遍「双实例成功 → primary 认证失败 secondary 超时 → 失败后 LastSuccess 不变 → 凭证轮换恢复 → URL 替换 → 全部恢复 → 重建 monitor 重放」的完整旅程。七、验证清单Proof如何在仓库中复现文档给出了可在当前仓库直接执行的验证命令-count1禁用测试缓存-race开启竞态检测# 监控侧PBS 健康权威回归全套 go test ./internal/monitoring -count1 # API 侧连接聚合、诊断、保存连接测试 go test ./internal/api -count1 # 监控侧竞态检测聚焦四个核心回归 go test -race ./internal/monitoring -run \ TestPollPBSInstancesKeepsAllHealthProjectionsOnOneOutcome|TestPollPBSInstanceKeepsPartialDataSeparateFromConnectivity|TestInitPBSClientsDoesNotTreatClientConstructionAsConnectivity|TestMonitor_PollPBSInstance_AuthFailure \ -count1 # API 侧竞态检测聚焦四个派生/隔离回归 go test -race ./internal/api -run \ TestDeriveConnectionState_CurrentFailureOverridesRecentSuccess|TestBuildConnectionsKeepsDistinctPBSSystemsWithSameHostname|TestPBSDiagnosticsKeepsCanonicalPollStateSeparateFromLiveProbe|TestHandleTestNodePBSIsADirectProbeWithoutChangingRuntimeHealth \ -count1其中TestMonitor_PollPBSInstance_AuthFailure在v6.1.1上通过用于证明 RC5 的 deferred-accounting 修正已就位该用例位于 monitor_pbs_coverage_test.go用一个返回 401 的 mock server 验证认证失败被记录为离线状态。除了上述 Go 测试记录还列出了发布门禁gate侧的完整验证聚焦 Settings 诊断、连接台账、基础设施来源、架构的 Vitest 套件共169 个用例通过前端 TypeScript、ESLint、Prettier 与 Settings 诊断边界检查以及子系统注册表、契约、状态、控制面、阶段形状staged-shape与 canonical-completion 审计。八、发布状态与后续Outcome这份记录对发布决策给出了非常审慎的结论RC5 的 deferred-accounting 修正已经存在于v6.1.1但本记录所描述的完整跨面行为complete cross-surface behavior并不在v6.1.1中——认证分支早退、聚合器乐观投影等剩余修正位于main分支将随未来的 v6 版本发布记录不声称任何 backport 或发布日期Issue#1465保持 open等待报告者在包含该变更的版本上重测后确认关闭。这条状态对使用者有直接意义如果当前运行的是v6.1.1PBS 认证失败在调度器台账中已有记录但 Dashboard 投影与 Settings Active 的矛盾仍可能出现需要等待包含「source-authority 修复 回归测试」的未来 v6 版本。九、源码阅读指引如果你希望进一步深入实现以下是本记录对应的核心代码位置轮询定稿与投影骨架internal/monitoring/monitor_pbs_pmg.go连接状态派生规则与陈旧阈值internal/api/connections_aggregator.go统一连接行与状态词表internal/api/connections_types.go双 PBS 场景、部分数据、客户端初始化回归internal/monitoring/monitor_pbs_health_authority_test.go认证失败RC5 修正证明用例internal/monitoring/monitor_pbs_coverage_test.go连接派生与同主机名用例internal/api/connections_aggregator_test.go诊断与即时探测分离用例internal/api/diagnostics_test.go保存连接测试隔离用例internal/api/configapi/config_handlers_connection_test.go十、小结Issue#1465的修复本质上是把 PBS 连接健康的单一事实来源source of authority确立为「调度器轮询定稿的错误」再让 Dashboard、台账、陈旧度、指标、连接健康映射、告警、Fleet 治理与诊断全部从这个事实派生。任何绕开该事实的乐观推断——无论来自 deferred accounting、认证分支早退还是聚合器「有历史成功就算 Active」——都被逐一关闭。这套「一次定稿、全局投影、部分数据与连接性分离、即时探测不污染权威状态」的模式同样可以推广到 Pulse 对 PVE、PMG、VMware、TrueNAS 等其他基础设施源的连接健康管理之中。赞分享可观测性运维后端【免费下载链接】PulseReal-time monitoring dashboard for Proxmox VE, PBS, Docker, Kubernetes, TrueNAS and vSphere. Self-hosted, with smart alerts and AI patrols that catch silent failures.项目地址https://gitcode.com/gh_mirrors/pulse27/Pulse点击查看免费下载相关推荐Pulse v6 RC3 已知问题关闭记录连接状态合并、图表 Tooltip 与 PBS 告警阈值的回归修复实战Pulse v6 RC3 已知问题关闭记录连接状态合并、图表 Tooltip 与 PBS 告警阈值的回归修复实战 导读 本文以 Pulse 仓库内部发布的 k可观测性运维后端EMQX MQTT 桥接陈旧连接状态修复解析从「假 Connected」到真实健康检查与自动重连EMQX MQTT 桥接陈旧连接状态修复解析从「假 Connected」到真实健康检查与自动重连 本文围绕 EMQX 开源仓库中 changes/ee/fix后端物联网消息队列通信dromara/easy-query健康检查连接状态的实时监控dromara/easy query健康检查连接状态的实时监控 引言数据库连接健康检查的重要性 在现代分布式系统中数据库连接的稳定性直接影响着应用的可用性后端ORM数据库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考