可观测性运维后端【免费下载链接】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点击查看免费下载本文基于docs/release-control/v6/internal/records/operational-trust-patrol-attention-workbench-2026-07-19.md这一阶段性验收记录结合仓库内internal/ai、internal/api、frontend-modern的真实实现与测试系统讲解 Pulse v6 Operational Trust 实施规范 Phase 3「Patrol Attention Workbench巡逻注意力工作台」的产品语义、后端投影、API 契约、生命周期变更、前端交互与验证矩阵并说明它为什么被判定为product级而不仅仅是一个原型。本记录是 Pulse v6 Operational Trust 实施规范OPERATIONAL_TRUST_IMPLEMENTATION_SPEC.mdPhase 3 的正式验收记录对应治理候选protection-posture-attention-queue。它描述的是一整套规范读路径把 Phase 1 的告警生命周期canonical lifecycle与 Phase 2 的保护态势protection posture投影为类型化的注意力条目并通过列表、摘要、详情三类 API 与 Patrol 工作台呈现给运维人员。读完本文你将理解注意力队列的六类生命周期过滤、200 条分页与姿势批量联结的实现细节、monitoring:read保护下的路由设计以及一套可以复制的后端/前端/浏览器三级验证命令。一、Phase 3 的定位从第二生命周期到一条规范读路径在展开实现细节之前需要先明确 Phase 3 在整个 Operational Trust 实施中的位置。实施规范OPERATIONAL_TRUST_IMPLEMENTATION_SPEC.md定义了 Pulse 对运维人员的七个回答什么需要关注、影响哪个资源、为什么相信它、可能的影响、有什么保护/恢复证据、什么安全下一步、动作是否生效。对应的实现闭环是observe - identify - detect - relate - explain - act - verify。该规范立下了一条根修决策共享的 operational-trust 模型而不是在无关的告警、通知、恢复与 Patrol 载荷之上做 UI 拼接。平台适配器可以输出 provider 特定的证据但不能拥有并行的生命周期、姿势或动作语义前端可以呈现共享契约但不能从标签、消息文本或松散元数据推断规范信任状态。Phase 3 在此框架下只负责读路径记录原文明确写到了四条边界internal/ai/attention.go 将规范告警操作记录、证据、转换与恢复归属的姿势投影为类型化注意力条目它拥有排序、生命周期过滤、分页、摘要与诚实平静honest calm评估但不是可写真相。internal/api/attention_handlers.go 暴露受monitoring:read保护的有界 list / summary / detail 路由summary 不读姿势存储list 的姿势联结以 200 个主体为一批。frontend-modern/src/features/patrol/PatrolAttentionWorkbench.tsx 是首要的 Patrol 表面导航与队列计数复用同一个 summary遗留检查findings、调查与运行历史降级为可折叠的支撑上下文。选中条目的详情携带受影响/相关资源、影响、推荐下一步、类型化证据与局限、保护姿势、时间线、所属资源导航以及仅限解释的 Assistant 交接。特别值得强调的是两条防伪规则生命周期故障仍不可用、姿势故障仍为部分可用二者都不能变成假零false zero、平静、健康、已解决或受保护状态历史快照只贡献近期已解决上下文一个没有匹配活动记录的非终结性历史条目不能复活出虚假的当前工作。二、用户视角User Lens用最小经验运维人员的语言验收记录的验收方法论是从最低经验合理用户的工作描述出发。这份记录给出的工作描述是Show me what needs attention now, why it matters, what it affects, whether it is protected, and what I should do next.现在什么需要关注、为什么重要、影响什么、是否受保护、下一步该做什么围绕这句话记录记录了六项实机演练结论认证后的启动仍然监控优先Patrol 只隔一次导航。Patrol 在第一个带边框的分区里就回答整个工作一个标题/计数、六个生命周期过滤器、一个有序队列与刷新。选中一个条目即到达最深状态暴露影响、资源、证据、保护、时间线、下一步与支撑链接。390×844 视口无文档宽度溢出选中或直接深链将详情带入视野关闭后焦点恢复到条目。减少动画、键盘激活、稳定的读屏名称以及 calm / partial/unavailable / acknowledged / suppressed / stale/unknown / recent resolved 各状态均有浏览器证据覆盖。实机最深状态暴露了单个磁盘事件有64 条重复观测默认详情只显示最新 3 条其余 61 条折叠在显式的更早观测older-observations披露项下既保留取证证据又不把监控变成原始事件浏览器。默认可见元素的取舍决策记录用一张表格给出了默认可见 vs 降级 vs 删除的判定这是 Phase 3 产品语义的核心完整继承如下元素运维人员动作决策活动计数Active count判断当前工作量并打开 Patrol保留生命周期过滤器Lifecycle filters不丢失已确认、已抑制、不确定或已解决历史地检查工作保留有序条目行Ordered item row选择下一个问题并打开证据保留资源、证据、保护、年龄标签判断紧急性以及条目是否值得信任到可以行动保留刷新Refresh请求一次新评估保留Provider 证据与时间线解释单个选中条目降级到选中详情重复的更早证据观测需要时检查取证历史降级为选中详情内的显式披露Patrol 运行历史、调查、评分取证或历史上下文降级为可折叠支撑上下文大型 Assistant 提示未选中条目前无动作删除通用信任评分/证明条无直接运维动作从主队列删除词汇约定Stale or unknown取代关于 collector 的实现词汇并明确说明证据不足以判断健康。Protection unknown表示没有完整的、与主体关联的 provider 历史而不是未受保护。Provider/collector 身份只出现在详情里。与既有 GitHub issue 的对照记录将设计决策与七个 issue 逐一对照这些结论用于说明需求来源本文不引用外部链接仅转述记录结论at a glance 列出发现队列成为首要的一眼可见目的地。建议很难找到选中详情把下一步放在影响与证据旁边。确认陈旧备份告警后感到困惑生命周期过滤器让 acknowledged 与 stale/unknown 保持可区分、可检查。无前置告警却有恢复通知噪音队列消费规范生命周期而非通知投递。不想被故意归档的备份打扰被抑制的工作离开默认活动队列但仍可检查。Patrol 可达性信息不正确证据新鲜度、完整性、置信度与限制性说明在 Assistant 解释之前就可见。移动端缩放失败手机宽度下的最深状态证明成为显式验收项。记录给出的最终判定是product主表面在不需要第二生命周期、通用对象浏览器、证明条或 Assistant 优先绕行的前提下回答了运维人员的工作。按规范的 User-Lens AcceptanceOPERATIONAL_TRUST_IMPLEMENTATION_SPEC.md任何阶段的主表面停留在prototype级都不能关闭。三、后端投影internal/ai/attention.go 的规范读模型Phase 3 的规范读路径的源头在 internal/ai/attention.go。该文件定义了两组关键常量与类型const ( DefaultAttentionPageSize 50 MaxAttentionPageSize 200 )过滤器枚举AttentionFilter支持七个取值也是 API 层面唯一合法的filter值active | open | acknowledged | suppressed | stale_unknown | resolved | all从源码internal/ai/attention.go可以确认active过滤器把observing / open / resolving / stale / unknown都计入活动而open只含observing / open / resolvingstale_unknown对应stale / unknown两个不确定状态all返回全部。这与规范中的OperationalStateinternal/operationaltrust/contracts.goobserving、open、acknowledged、suppressed、resolving、resolved、stale、unknown一一对应。投影入口 ProjectAttentionItems核心函数ProjectAttentionItems(active, history, postures, now)是唯一 Patrol 读模型投影它不检查松散告警元数据来发明工作也绝不创建第二个可写生命周期。其流程可以概括为以operationalRecord.ID为主键合并活动与历史告警internal/ai/attention.go。合并规则保证了记录第 6 条的防伪语义非终结性非 resolved的历史条目只有在没有活动记录、或活动记录更新时才进入结果孤儿非终结历史无法复活为虚假当前工作。逐条投影克隆操作记录、证据与时间线校验记录有效性汇总证据新鲜度/完整性生成标题与纯语言摘要附加保护姿势若姿势映射中存在该主体。稳定排序attentionItemLess严重度critical warning info unknown、受影响资源数blast radius、保护姿势关注度attention unprotected unknown、证据新鲜度fresh stale unknown、首次观测时间、最后以 ID 兜底internal/ai/attention.go。这与规范中先按可行动严重度、爆炸半径、保护关注、证据新鲜度、再按年龄的队列规则一致。汇总summarizeAttention生成AttentionSummary包含activeCount / openCount / acknowledgedCount / suppressedCount / uncertainCount / resolvedCount / calm / coverageState / evaluatedAt。其中calm activeCount 0。类型化的 AttentionItem 与 DetailAttentionItem是规范域模型中AttentionItem契约的直接落地字段包括id即规范操作记录 ID、operationalRecordId、subjectResourceId/Name/Type、kind、title、plainLanguageSummary、severity、state、firstObservedAt/lastObservedAt、evidenceFreshness/evidenceCompleteness、impact、protectionPosture、relatedResources、recommendedNextStep、availableActions、verificationState以及flapping抖动摘要。详情AttentionItemDetail额外携带完整operationalRecord、timeline生命周期转换列表与evidence证据信封列表。值得注意的两个细节实现Flapping 摘要attentionFlapping用与 findings storm throttler 相同的窗口与阈值把 open/resolved 反复抖动折叠成transitionCount / windowHours / firstTransitionAt / lastTransitionAt的运营者摘要acknowledgement、suppression、证据刷新这类记账转换不计入抖动internal/ai/attention.go。前端类型注释给出共享阈值为24 小时内 4 次转换见 frontend-modern/src/api/patrolAttention.ts。证据汇总的最差即真相summarizeAttentionEvidence在 stale/unknown 生命周期状态下直接映射证据新鲜度并逐信封取最差完整度没有任何证据时返回unknown / unavailable而不是健康internal/ai/attention.go。这就是陈旧或未知证据可见但绝不呈现为已确认故障的代码级落实。有界分页PaginateAttentionDetails强制page 1、1 limit 200起始偏移越界时返回空切片而非报错。性能测试 internal/ai/attention_performance_test.go 用 10,000 条生命周期记录验证投影后第一页恰好 200 条且整个投影在 5 秒内完成CI 环境下的宽松上限用于捕获意外的二次方投影或逐条外部请求。四、API 契约internal/api/attention_handlers.go 的受保护路由路由注册在 internal/api/router_routes_ai_relay.go/api/ai/patrol/attention与/api/ai/patrol/attention/都经过RequireAuth与requireRelayMobileRuntimeRoute包装处理器统一为AttentionHandlers.HandleAttention。记录所言的monitoring:read保护在测试侧internal/api/action_authority_test.go体现为只有monitoring:read作用域的令牌对approve等高危动作必须被拒绝读接口与写接口的作用域边界是显式设计的。分发与四个读端点HandleAttention先剥离前缀再按路径与方法分发internal/api/attention_handlers.goGET /api/ai/patrol/attention?filterpagelimit—— 列表。filter非法例如healthy、page 1、limit 200都会返回 400测试见 internal/api/attention_handlers_test.go。响应包含dataAttentionItem[]、summary投影摘要与meta{page, limit, total, totalPages}。GET /api/ai/patrol/attention/summary—— 摘要。调用project(r, false)不读取姿势存储includeProtectionPosturefalse因此导航角标、队列计数共用同一个轻量摘要。GET /api/ai/patrol/attention/{itemID}—— 详情。itemID先经url.PathUnescape解码规范记录 ID 若含/如agent:node-1/disk:mnt-disk2::metric-threshold:disk必须被百分号编码为深链身份。对应测试 TestAttentionHandlersDetailSupportsCanonicalIDsContainingSlashes 验证了%2F编码路径可正确还原。GET /api/ai/patrol/attention/{itemID}/evidence/{evidenceID}—— 有界证据详情internal/api/attention_evidence.go。返回{evidence, freshness, retained}证据引用已过期保留期外时返回410 Gone而不是把过期细节当作可用证据测试 TestAttentionEvidenceDetailIsBoundedAndReportsExpiredRetention。姿势联结的 200 主体分批loadProtectionPostures把投影所需的主体 ID 按attentionPostureBatchSize 200分批查询recovery存储internal/api/attention_handlers.go每次批查询使用SubjectResourceIDs Limit的有界ProtectionPostureQuery。任一整批失败都会把摘要的coverageState标记为partial——绝不静默降级为健康。这正是记录所说list 姿势联结以 200 个主体为批、无逐项拉取以及规范表 API 支持有界批量读前端不得逐行发请求的实现。读模型不可用时的失败关闭writeAttentionUnavailable返回503错误码为attention_read_model_unavailable并显式声明Patrol attention is temporarily unavailable. No calm or healthy state has been inferred.internal/api/attention_handlers.go。测试 TestAttentionHandlersFailClosedWhenLifecycleUnavailable 验证了生命周期源不可用时不会推断出平静/健康状态。浏览器侧同样的语义出现在工作台错误态文案Pulse has not inferred a calm or healthy state from this failure.生命周期变更端点读路径之外的受控写虽然 Phase 3 队列本身不包含动作执行但acknowledged / suppressed 可过滤且保留真实状态需要受控的写端点实现在 internal/api/attention_mutations.goPOST /api/ai/patrol/attention/{itemID}/acknowledge/unacknowledgePOST /api/ai/patrol/attention/{itemID}/suppress/unsuppress两个硬约束值得运维人员注意抑制必须有理由与到期时间suppress请求体为{reason, expiresAt}body 上限 4096 字节reason非空、expiresAt非零且必须在未来 30 天内maxAttentionSuppressionDuration 30*24h否则返回 400internal/api/attention_mutations.go。变更直接作用于告警管理器acknowledge/suppress 调用monitor.GetAlertManager()上的AcknowledgeAlert/SuppressOperationalAlert等随后SyncAlertState()刷新状态。这意味着变更写入唯一的规范生命周期然后投影自动反映——acknowledge 永远不会等于 resolvesuppress 也永远不会改写底层探测器状态对应规范转换规则 2、3。集成测试 TestAttentionLifecycleMutationsRefreshTheCanonicalProjection 验证了 acknowledge → suppressed 后filteractive列表清空但suppressedCount1。五、动作的出价边界Phase 3 只投影不执行记录明确指出该阶段的队列不包含动作执行能力。受治理的出价、审批、执行与验证属于 Phase 5。但AttentionItem.availableActions字段是 Phase 3 投影的一部分其出价逻辑在 internal/ai/attention_actions.go 中已有雏形ProjectAttentionAction只处理刻意选定的第一个窄动作——docker-container-health类型的应用容器重启且必须逐项通过生命周期必须是open或acknowledgedlifecycle_inactive拒绝证据必须存在evidence_missing、新鲜evidence_stale、完整evidence_incomplete、已确认evidence_unconfirmed、权限充分evidence_permission_limited、主体与规范资源 ID 一致且相关匹配唯一evidence_subject_mismatch资源必须可用且声明restart能力 docker.container.lifecycle处理器 最小审批等级 admin就绪状态可用、操作者已授权。从源码可以推断这套门控是对规范第 6 条动作是声明式能力未知/陈旧/不完整/模糊证据必须对变更动作失败关闭的读侧预演——即使执行留待 Phase 5出价本身已经不会建立在陈旧证据上。浏览器证据tests/integration/tests/91-operational-trust-attention-workbench.spec.ts也按 confirmed / contradicted 两种验证结果验证了执行成功 ≠ 结果真相的诚实呈现验证失败时文案明确为restart did not satisfy its postcondition / issue remains open。六、前端工作台PatrolAttentionWorkbench 的交互语义主表面组件 frontend-modern/src/features/patrol/PatrolAttentionWorkbench.tsx 的 ARIA 语义是Patrol decision inbox。其核心交互可以归纳为双视图inbox需要你决策的条目与handled已确认/已抑制条目。handledCount acknowledgedCount suppressedCount两个视图使用同一个 summary 驱动导航计数这正是一个活动计数来自规范读模型的前端落实。选定详情双栏选中条目后桌面端变为列表 详情双栏关闭详情后焦点通过itemButtonsMap 恢复到原条目按钮PatrolAttentionWorkbench.tsx浏览器测试toBeFocused()断言了这一行为。深链身份selectItem通过buildPatrolAttentionPath写入attentionencodeURIComponent(itemId)的查询参数history.replaceState刷新后createEffect解析该参数并把详情带回视野。这也解释了为什么含/的规范 ID 必须是百分号编码深链身份。证据折叠披露详情证据按observedAt降序PRIMARY_EVIDENCE_LIMIT 3条为默认展示其余折叠在older observations披露下PatrolAttentionWorkbench.tsx。这就是记录中64 条观测 → 最新 3 条 折叠 61 条的实现。决策排序sortPatrolAttentionDecisions按 severitycritical→warning→info→unknown、是否可行动、最近观测时间、ID 排序PRIMARY_DECISION_LIMIT 5超过后出现Show all N decisions。平静状态的门槛AttentionEmptyState只有在calm true coverageState current 无错误时才显示Nothing needs you right now / 当前运行评估没有活动条目并附带最近评估时间coverageState partial时则明示Pulse 不把该缺口当作健康证明。前端 API 客户端 frontend-modern/src/api/patrolAttention.ts 提供了getPatrolAttention / getPatrolAttentionSummary / getPatrolAttentionDetail / getPatrolAttentionEvidence / acknowledgePatrolAttention / suppressPatrolAttention / planPatrolAttentionAction等函数与后端路由一一对应。七、验证矩阵三级证明与实机观测记录给出的证明体系分为三层均可直接复现后端Go 单测与契约go test ./internal/alerts ./internal/ai ./internal/api \ -run OperationalContract|Attention|PatrolMetrics|RouteInventory -count1记录特别指出聚焦的迁移与路由回归额外证明了孤儿非终结历史被排除、已解决历史仍然可用、含编码斜杠的规范 ID 能打开其详情路由——对应 internal/api/attention_handlers_test.go 中TestAttentionHandlersSummaryAndDetailShareOneProjection、TestAttentionHandlersDetailSupportsCanonicalIDsContainingSlashes、TestAttentionHandlersFailClosedWhenLifecycleUnavailable等用例。前端类型、lint、vitest 与热开发运行时npm run type-check npm run lint npm exec vitest run \ src/api/__tests__/patrolAttention.test.ts \ src/features/patrol/__tests__/PatrolAttentionWorkbench.test.tsx \ src/__tests__/App.architecture.test.ts \ src/__tests__/AppLayout.test.tsx \ src/pages/__tests__/AIIntelligence.test.tsx \ src/routing/__tests__/resourceLinks.test.ts bash scripts/tests/test-hot-dev-runtime.sh浏览器Playwright 真实前端PLAYWRIGHT_BASE_URLhttp://127.0.0.1:5173 \ npx playwright test \ tests/91-operational-trust-attention-workbench.spec.ts \ --projectchromium浏览器测试文件 tests/integration/tests/91-operational-trust-attention-workbench.spec.ts 用有界、确定性的 API 桩不依赖真实凭据与可变的首启设置覆盖活动工作、Phase 3 全部生命周期过滤器、证据/保护/时间线详情、导航计数一致性、键盘与焦点、窄视口390×844、减少动画、平静态以及不可用时无假健康。记录还澄清了两个运行细节npm test -- tests/91-... --projectchromium不是正确的托管运行时调用该包装需要 Docker而更宽的npm run dev:verify会撞上既有的首会话设置向导辅助超时在16-dev-runtime-recovery.spec.ts因此 Phase 3 特性证明直接针对托管运行时运行。记录同时记录了托管实机运行时的观测结果从同一 Development-SSD 源码树重建后实机契约报告了 1 个当前活动条目、一个当前非平静覆盖状态与迁移后的通用下一步选中的磁盘条目在 390×844 视口文档宽度 390px深链成功默认证据区显示 64 条观测中的最新 3 条、折叠 61 条。性能证明internal/ai/attention_performance_test.go 投影 10,000 条生命周期记录证明 200 条的有界页summary 路由不读姿势存储list 只做一次有界姿势批量、无逐项拉取。八、范围边界与未完成工作这份记录只接受 Phase 3没有关闭整个 operational trust 目标、候选车道或覆盖缺口。记录原文列出的剩余工作清晰如下Phase 4availability attachment可用性作为资源切面——这是独立治理的availability-as-resource-facet候选需先声明治理面再开始运行时变更最终由internal/records/operational-trust-availability-resource-facet-2026-07-19.md关闭。Phase 5governed actions and verification受治理动作与验证——选择最小的既有声明能力实现出价资格与证据门控证明审批、幂等执行、审计与后置条件验证。Phase 6rollout hardening加固与发布完成——兼容与迁移证明、并发/失败/保留/负载证明、无障碍与响应式证明、生产观测遥测、文档与升级说明并按治理证据移除被取代的兼容路径。只有在规范OPERATIONAL_TRUST_IMPLEMENTATION_SPEC.md的14 条完成标准全部通过后目标车道才能关闭。Phase 3 通过只意味着Patrol 工作台是 product 级读路径离运行时可信任仍有完整的后半程。结语Patrol Attention Workbench 是 Pulse v6 Operational Trust 由规范契约走向运维界面的关键一跳它在不创造第二生命周期、不发明假健康、不逐行拉取的前提下把规范生命周期与保护姿势压成一张运维人员可以直接回答现在什么需要关注、为什么、影响什么、是否受保护、下一步做什么的队列。若你想深入源码建议从 internal/ai/attention.go 的投影函数、internal/api/attention_handlers.go 的批联结与失败关闭、frontend-modern/src/features/patrol/PatrolAttentionWorkbench.tsx 的双栏交互以及 tests/integration/tests/91-operational-trust-attention-workbench.spec.ts 的浏览器证明四条线并行阅读。赞分享可观测性运维后端【免费下载链接】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.1.0-rc.4 发布说明深度解读Operational Trust 生命周期、报告只读 Observer 与 Patrol 注意力工作台Pulse v6.1.0 rc.4 发布说明深度解读Operational Trust 生命周期、报告只读 Observer 与 Patrol 注意力工作台可观测性运维后端Pulse 平台化界面指南Proxmox 工作区与 Patrol 注意力队列实操详解Pulse 平台化界面指南Proxmox 工作区与 Patrol 注意力队列实操详解 本指南基于 docs/SCREENSHOTS.md https://li可观测性运维后端Pulse v6.1.0 发布解读Attention 工作台、Operational Trust 与 Unified Agent 深度升级指南Pulse v6.1.0 发布解读Attention 工作台、Operational Trust 与 Unified Agent 深度升级指南 Pulse v可观测性运维后端上一篇工业通讯调试实战指南5个工程场景下的OpenModScan深度应用下一篇揭秘PPO强化学习AI马里奥如何从游戏菜鸟变身通关高手创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考