半夜告警群同时弹 redis 超时 shop-agent 5xx——到底谁是因谁是果组件级健康 ≠ 系统级健康需要一张「关系图」才能推理。监控不是看一块 Grafana 面板而是把 shop-agent、gateway、redis、postgres、ollama……这些分散组件的健康状态收敛成一张可推理的拓扑健康矩阵——谁挂了、影响面多大、先救谁。核心论点监控的职责是把分散组件收敛成一张可推理的拓扑健康矩阵排障从盲找变推理。系统级巡检问在不在与应用内可观测查为什么职责不重叠。监控的边界巡检 vs 可观测组件职责monitoring-agent系统级健康巡检、拓扑矩阵、存活探测Prometheus Grafana指标采集与看板Langfuse / SkyWalkingLLM trace / 分布式链路决策巡检是「持续问在不在」可观测是「出了问题查为什么」职责不重叠。把两者混在一起要么巡检太重背一堆 trace 存储要么可观测太浅只看探活绿点。要探哪些组件怎么探探测清单shop-agent / gateway / redis / postgres / ollama / minio / SkyWalking / Langfuse。注Langfuse 存完整对话是最大 PII 落点脱敏见《06-合规护栏》/《09-LLM业务级可观测》。两种探活方式分工探活方式适用验证内容HTTP/healthshop-agent / gateway / ollama 等有语义端点的组件进程存活 业务语义状态TCP 探活redis / postgres / minio 等无 HTTP 语义的组件仅验端口连通服务清单从硬编码到自动发现探测目标不再写死进代码。新服务上线只要接入 Prometheus 抓取agent 自动纳入巡检无需改代码/重启——这是「新增服务」与「运维巡检」的解耦。三层合并优先级从高到低层级来源覆盖例子静态显式STATIC_TARGETSenvnameurl逗号分隔k8s 外 / 未接 Prometheus 的服务STATIC_TARGETSext-dbhttp://db.example:5432/ping动态发现Prometheus/api/v1/targetshealthup的 job → 拼接健康路径被 Prometheus 抓取的所有服务gateway / shop-agent / monitoring-agent静态兜底HTTP_TARGETS代码内默认值已知组件失联时的保底milvus / minio / langfuse决策巡检是高频路径动态发现带 TTL 缓存DISCOVER_CACHE_TTL_S默认 60s避免每次/status都打 PrometheusPrometheus 不可达时静默降级到静态清单发现是「增强」而非「依赖」。DISCOVER_ENABLED0可整体关闭。k8s 外服务怎么办任何自动发现源都只覆盖「主动上报」的服务——Prometheus 只认有/metrics且配置了 scrape 的目标SkyWalking 只认接了 agent 上报的进程。未接入的集群外服务云 RDS、独立部署组件用STATIC_TARGETS静态登记与自动发现结果合并缺一不可。/status 聚合拓扑健康矩阵输出结构{ component: {status, latency_ms, last_check, detail}, dependencies: [...] }。dependencies为依赖边列表[{source, target}]source 依赖 target来源SkyWalking OAP 真实调用边方案 CSTATIC_DEPENDENCIES静态兜底k8s 外 / 未接 agent 的服务依赖只能手工声明。价值一眼看出「redis 挂 → shop-agent 降级」的影响链且由真实调用边驱动而非拍脑袋。正常态 vs 故障态对比组件正常态redis 故障态redisup延迟个位数 msdownprobe_duration逼近超时上限连续失败计数递增shop-agentupdegraded依赖 redis 的功能降级矩阵单元绿redis 红、shop-agent 黄监控矩阵对应单元由绿转红触发 P1 级存活告警——自身up探活与组件探活分离避免误判 agent 自身挂掉。旁路原则监控流量不过业务计量monitoring-agent 探gateway/health但不走完整业务流程探活否则污染 LLM 计量呼应 01 篇网关是唯一计量点——任何走完整业务流程的非业务流量都会让计量失真。关键区分探活探的是网关在不在不是LLM API 通不通。/health只验证网关进程存活不验证下游模型能否出字。后端挂了/限流由 02 路由故障转移 09 可观测发现不靠监控探活 cover——两者职责分离。监控流量分两类别一刀切流量类型走哪标识计费探活问在不在/health无不计 token用模型做自动分析根因归纳/日志摘要/v1X-Traffic-Source: monitoring进平台运维账网关按 tag 分桶业务 token 进业务成本账、监控 token 进平台运维账09 看板只聚合业务 tag——既不漏掉监控用模型的需求也不污染业务计量。日志通道推送 集中 判定后触发不走agent 去拉日志日志体量远大于指标让 monitoring-agent 轮询/存储日志既重又慢。改为事件驱动——应用自己把日志推走异常时才回头找 agent。应用侧前提shop-agent / gateway 用 structlog 输出 JSON 结构化日志天然机器可读无需改日志格式。推送形态应用通过 Loki handler / OpenTelemetry log exporter 主动推送至 Loki而非 agent 拉取。Loki 与既有 Grafana 同栈无新增运维负担。异常判定在收集器侧Loki 用 LogQL 规则如count_over_time({levelerror}[5m]) N触发告警经 Alertmanager webhook 推送给 monitoring-agent。三通道同源指标 日志 LLM 异常LLM 通道日志通道指标通道webhook 叫醒应急口直推 /ingest/eventPrometheus 抓取规则评估Alertmanager应用推送LokiLogQL 规则Langfuse metricsPrometheus alert rulemonitoring-agent被叫醒才工作三通道最终都汇到 monitoring-agent 这一个分析点。agent 平时零日志存储被告警 webhook 叫醒后才用 LogQL 临时查询相关日志原文做 RCA查完即弃。决策日志走推送集中判定后触发与指标的抓取判定推送共用同一事件驱动哲学——monitoring-agent 始终是「被叫醒才工作」的无状态分析层不轮询、不持久化。告警分级与根因归因redis 一抖告警群炸 5 条——分级与收敛才是巡检篇的收口。分级级别触发条件示例规则P0核心服务全挂—P1单组件失联up{jobgateway}0持续 1mP2延迟劣化 / 成本突增网关 P99 10s 持续 5m租户 token 速率 2×1h 基线持续 10mP3安全拒绝速率偏高注入拦截治理异常合计 0.5/s 持续 10m收敛噪声关联矩阵做根因归因避免重复告警——redis 挂导致的 shop-agent 5xx归因到 redis 一条不重复报。依赖拓扑级联归因收敛根因纯「平铺」的拓扑健康矩阵只能回答「谁挂了」答不了「谁导致谁挂」。用 SkyWalking OAP 的getGlobalTopology拿到真实调用依赖边A 调 B ⇒ A 依赖 BRCA 时做级联归因同时挂了一串组件时按依赖方向收敛根因候选 不依赖任何「同故障组件」的节点即最下游、无可被传导的依赖其余是受影响者。例shop-agent 依赖 gatewaygateway 依赖 redis。redis 挂 → gateway 挂 → shop-agent 挂级联归因把根因收敛到 redisshop-agent / gateway 标记为受影响者告警合并成一条。k8s 外 / 未接 agent 的服务依赖怎么办OAP 拓扑只覆盖接了 SkyWalking agent 的进程。集群外服务没有 agent依赖边用STATIC_DEPENDENCIESenv 静态声明sourcetarget逗号分隔与 OAP 动态边合并去重。SKYWALKING_ENABLED0关闭动态查询OAP 不可达时自动降级到纯静态依赖RCA 退化为平铺归因每个故障组件都是根因候选不阻断排障。⚠️ 跨平面提醒呼应 06告警 payload 若含用户标识 / 请求片段推送前需脱敏——告警群 / 工单系统也是 PII 落点否则网关在模型侧的脱敏白做。单实例边界为什么不需要集群为什么单实例够agent 探的是 redis / postgres / shop-agent / gateway 等全局共享组件多实例探同一批目标结果完全冗余无分片收益只带来重复打探、重复告警、状态不一致的副作用。自身高可用不靠自己agent 挂了 → Prometheus 抓不到它的up{jobmonitoring-agent}指标 → 自动告警「监控组件失联」。监控组件监控自己靠下游采集器不靠多副本互备。业界佐证Blackbox Exporter最对标的黑盒探测组件在生产环境全局单体部署无集群概念Node / 业务 Exporter 是一目标一 agent 天然分片只有 Prometheus 服务端才跑双副本 HA且那是上游采集器冗余不在 exporter 这层。agent 自身异常三层兜底异常类型兜底机制进程崩溃Prometheusup0告警 Dockerrestart: unless-stopped自动拉起静默误判如把 5xx 算健康指标通道与日志通道双通道交叉验证任一报异常都触发自愈动作出错默认只产处置建议、不直接写操作与 05 自愈闭环的「建议 审批」一致采集器与 agent 同时挂外部存活探针OCI Monitoring / 节点 exporter / cron 心跳兜底存储边界agent 只持久化派生产物数据类型存哪理由原始指标Prometheus专业存储负责 retention 与查询原始日志Loki同上原始告警/路由状态Alertmanager同上拓扑健康矩阵agent 本地排障推理的底座告警分级状态agent 本地P0/P1/P2 分级、根因归因、去噪后的有效告警自愈审计agent 本地处置建议内容、触发条件、审批/执行结果golden signal 快照agent 本地token 成本 / P99 / 质量退化等派生聚合值决策派生产物体量远小于原始流、且是 agent 真正产出价值的部分原始流留在专业存储由它们各自负责agent 按需临时拉取关联、查完即弃——既守住无状态定位又不丢推理能力。不变量监控数据全走可观测管道绝不混入 LLM 流量呼应 01 §2 旁路原则。与 K8s probe 分工监控 agent 的应用层巡检探 redis/gateway 业务语义健康如/status返回内容与 K8sliveness/readiness探针探进程是否存活、是否可接流正交——kube 层只管进程在不在agent 层管进程在但业务是否已坏互补而非重叠。自研边界不变量留给薄壳深度调查交给成熟引擎市面上有成熟的 AIOps/RCA 产品商业Datadog Watchdog、Dynatrace Davis、PagerDuty AIOps开源Aurora、IncidentFox、ninoxAI功能覆盖面很大——服务发现、依赖拓扑、告警收敛、LLM 根因分析、Slack/工单通知、复盘报告它们都有。那 monitoring-agent 为什么还要自研因为通用产品替代的是「功能」替代不了「不变量」不变量通用产品的默认行为冲突点无旁路 / 唯一计量点不理解「网关是唯一 LLM 计量口」监控流量会混入业务计量需改造产品不是配置项入站即 PII 脱敏把告警当数据存储脱敏是事后配置本项目脱敏在解析层进分析路径前已完成只建议、不写操作Aurora 反而自动生成修复 PR与「RCA 只产建议、自愈由 Operator 审批」冲突无状态、零持久化全是有状态平台Neo4j/Postgres/向量库与「agent 不存原始流」的存储边界相反边界划分不变量层自研薄壳巡检探活、旁路计量隔离、入站脱敏、fail-closed、级联归因的规则主线深度调查与自治执行留给成熟引擎Aurora / IncidentFox 的 agentic 调查、知识图谱、RAG 复盘。为什么这两个不能让步「零持久化」保护 PII 边界——存储点 攻击面 合规面原始流一旦落库agent 就从「分析层」变成「PII 落点」需要补加密 at-rest、访问控制、保留销毁、存储 HA 一整套。「只建议」保护二次故障——错误的自愈比半夜叫醒人更贵05 篇。真要放开必须先做动作分级read-only 随时、可逆重启/回滚/扩容限定条件自动、不可逆删数据/改配置强制人批外加预检、verify、连续失败熔断、全程审计。演进路线若未来要放开薄壳 → 加持久化补加密/RBAC/审计→ 加动作分级自治可逆类自动执行→ 深度调查接外部引擎。每步都对应一套新增治理不是加个开关就行。与本项目的关系本子弧的 monitoring-agent 定位是「验证不变量」的薄壳若演化成「小型事故管理平台」则与ai-agent-distributed-system自治运维子弧的边界需重新划分——届时决策点不再是「自研 vs 采购」而是「薄壳与引擎的接缝在哪」。核心要点监控的职责是把分散组件收敛成一张可推理的拓扑健康矩阵排障从盲找变推理。系统级巡检问在不在与应用内可观测查为什么职责不重叠。监控流量一律旁路业务计量/health探活不计 token用模型分析须带独立 tag 进运维账。指标Prometheus、日志Loki、LLM 异常Langfuse三通道同源、事件驱动最终汇于 monitoring-agent。agent 是无状态分析层被告醒才工作不轮询、不持久化原始流只持久化派生产物。单实例部署探的是全局共享组件多实例冗余无收益自身高可用由 Prometheusup指标承接对标 Blackbox Exporter。异常三层兜底进程崩溃靠up0告警 自动重启误判靠双通道交叉验证自愈出错因「只建议不写操作」天然隔离。服务清单自动发现方案 A新服务接 Prometheus 即被巡检STATIC_TARGETS兜底 k8s 外服务。依赖级联归因方案 COAP 真实调用边收敛根因STATIC_DEPENDENCIES兜底未接 agent 的依赖。自研边界通用产品替代「功能」替代不了「不变量」无旁路 / 入站脱敏 / 只建议 / 零持久化薄壳留自研深度调查交给 Aurora / IncidentFox 等成熟引擎。真要放开须先补加密存储、访问审计、动作分级与熔断。
系统健康监控巡检
半夜告警群同时弹 redis 超时 shop-agent 5xx——到底谁是因谁是果组件级健康 ≠ 系统级健康需要一张「关系图」才能推理。监控不是看一块 Grafana 面板而是把 shop-agent、gateway、redis、postgres、ollama……这些分散组件的健康状态收敛成一张可推理的拓扑健康矩阵——谁挂了、影响面多大、先救谁。核心论点监控的职责是把分散组件收敛成一张可推理的拓扑健康矩阵排障从盲找变推理。系统级巡检问在不在与应用内可观测查为什么职责不重叠。监控的边界巡检 vs 可观测组件职责monitoring-agent系统级健康巡检、拓扑矩阵、存活探测Prometheus Grafana指标采集与看板Langfuse / SkyWalkingLLM trace / 分布式链路决策巡检是「持续问在不在」可观测是「出了问题查为什么」职责不重叠。把两者混在一起要么巡检太重背一堆 trace 存储要么可观测太浅只看探活绿点。要探哪些组件怎么探探测清单shop-agent / gateway / redis / postgres / ollama / minio / SkyWalking / Langfuse。注Langfuse 存完整对话是最大 PII 落点脱敏见《06-合规护栏》/《09-LLM业务级可观测》。两种探活方式分工探活方式适用验证内容HTTP/healthshop-agent / gateway / ollama 等有语义端点的组件进程存活 业务语义状态TCP 探活redis / postgres / minio 等无 HTTP 语义的组件仅验端口连通服务清单从硬编码到自动发现探测目标不再写死进代码。新服务上线只要接入 Prometheus 抓取agent 自动纳入巡检无需改代码/重启——这是「新增服务」与「运维巡检」的解耦。三层合并优先级从高到低层级来源覆盖例子静态显式STATIC_TARGETSenvnameurl逗号分隔k8s 外 / 未接 Prometheus 的服务STATIC_TARGETSext-dbhttp://db.example:5432/ping动态发现Prometheus/api/v1/targetshealthup的 job → 拼接健康路径被 Prometheus 抓取的所有服务gateway / shop-agent / monitoring-agent静态兜底HTTP_TARGETS代码内默认值已知组件失联时的保底milvus / minio / langfuse决策巡检是高频路径动态发现带 TTL 缓存DISCOVER_CACHE_TTL_S默认 60s避免每次/status都打 PrometheusPrometheus 不可达时静默降级到静态清单发现是「增强」而非「依赖」。DISCOVER_ENABLED0可整体关闭。k8s 外服务怎么办任何自动发现源都只覆盖「主动上报」的服务——Prometheus 只认有/metrics且配置了 scrape 的目标SkyWalking 只认接了 agent 上报的进程。未接入的集群外服务云 RDS、独立部署组件用STATIC_TARGETS静态登记与自动发现结果合并缺一不可。/status 聚合拓扑健康矩阵输出结构{ component: {status, latency_ms, last_check, detail}, dependencies: [...] }。dependencies为依赖边列表[{source, target}]source 依赖 target来源SkyWalking OAP 真实调用边方案 CSTATIC_DEPENDENCIES静态兜底k8s 外 / 未接 agent 的服务依赖只能手工声明。价值一眼看出「redis 挂 → shop-agent 降级」的影响链且由真实调用边驱动而非拍脑袋。正常态 vs 故障态对比组件正常态redis 故障态redisup延迟个位数 msdownprobe_duration逼近超时上限连续失败计数递增shop-agentupdegraded依赖 redis 的功能降级矩阵单元绿redis 红、shop-agent 黄监控矩阵对应单元由绿转红触发 P1 级存活告警——自身up探活与组件探活分离避免误判 agent 自身挂掉。旁路原则监控流量不过业务计量monitoring-agent 探gateway/health但不走完整业务流程探活否则污染 LLM 计量呼应 01 篇网关是唯一计量点——任何走完整业务流程的非业务流量都会让计量失真。关键区分探活探的是网关在不在不是LLM API 通不通。/health只验证网关进程存活不验证下游模型能否出字。后端挂了/限流由 02 路由故障转移 09 可观测发现不靠监控探活 cover——两者职责分离。监控流量分两类别一刀切流量类型走哪标识计费探活问在不在/health无不计 token用模型做自动分析根因归纳/日志摘要/v1X-Traffic-Source: monitoring进平台运维账网关按 tag 分桶业务 token 进业务成本账、监控 token 进平台运维账09 看板只聚合业务 tag——既不漏掉监控用模型的需求也不污染业务计量。日志通道推送 集中 判定后触发不走agent 去拉日志日志体量远大于指标让 monitoring-agent 轮询/存储日志既重又慢。改为事件驱动——应用自己把日志推走异常时才回头找 agent。应用侧前提shop-agent / gateway 用 structlog 输出 JSON 结构化日志天然机器可读无需改日志格式。推送形态应用通过 Loki handler / OpenTelemetry log exporter 主动推送至 Loki而非 agent 拉取。Loki 与既有 Grafana 同栈无新增运维负担。异常判定在收集器侧Loki 用 LogQL 规则如count_over_time({levelerror}[5m]) N触发告警经 Alertmanager webhook 推送给 monitoring-agent。三通道同源指标 日志 LLM 异常LLM 通道日志通道指标通道webhook 叫醒应急口直推 /ingest/eventPrometheus 抓取规则评估Alertmanager应用推送LokiLogQL 规则Langfuse metricsPrometheus alert rulemonitoring-agent被叫醒才工作三通道最终都汇到 monitoring-agent 这一个分析点。agent 平时零日志存储被告警 webhook 叫醒后才用 LogQL 临时查询相关日志原文做 RCA查完即弃。决策日志走推送集中判定后触发与指标的抓取判定推送共用同一事件驱动哲学——monitoring-agent 始终是「被叫醒才工作」的无状态分析层不轮询、不持久化。告警分级与根因归因redis 一抖告警群炸 5 条——分级与收敛才是巡检篇的收口。分级级别触发条件示例规则P0核心服务全挂—P1单组件失联up{jobgateway}0持续 1mP2延迟劣化 / 成本突增网关 P99 10s 持续 5m租户 token 速率 2×1h 基线持续 10mP3安全拒绝速率偏高注入拦截治理异常合计 0.5/s 持续 10m收敛噪声关联矩阵做根因归因避免重复告警——redis 挂导致的 shop-agent 5xx归因到 redis 一条不重复报。依赖拓扑级联归因收敛根因纯「平铺」的拓扑健康矩阵只能回答「谁挂了」答不了「谁导致谁挂」。用 SkyWalking OAP 的getGlobalTopology拿到真实调用依赖边A 调 B ⇒ A 依赖 BRCA 时做级联归因同时挂了一串组件时按依赖方向收敛根因候选 不依赖任何「同故障组件」的节点即最下游、无可被传导的依赖其余是受影响者。例shop-agent 依赖 gatewaygateway 依赖 redis。redis 挂 → gateway 挂 → shop-agent 挂级联归因把根因收敛到 redisshop-agent / gateway 标记为受影响者告警合并成一条。k8s 外 / 未接 agent 的服务依赖怎么办OAP 拓扑只覆盖接了 SkyWalking agent 的进程。集群外服务没有 agent依赖边用STATIC_DEPENDENCIESenv 静态声明sourcetarget逗号分隔与 OAP 动态边合并去重。SKYWALKING_ENABLED0关闭动态查询OAP 不可达时自动降级到纯静态依赖RCA 退化为平铺归因每个故障组件都是根因候选不阻断排障。⚠️ 跨平面提醒呼应 06告警 payload 若含用户标识 / 请求片段推送前需脱敏——告警群 / 工单系统也是 PII 落点否则网关在模型侧的脱敏白做。单实例边界为什么不需要集群为什么单实例够agent 探的是 redis / postgres / shop-agent / gateway 等全局共享组件多实例探同一批目标结果完全冗余无分片收益只带来重复打探、重复告警、状态不一致的副作用。自身高可用不靠自己agent 挂了 → Prometheus 抓不到它的up{jobmonitoring-agent}指标 → 自动告警「监控组件失联」。监控组件监控自己靠下游采集器不靠多副本互备。业界佐证Blackbox Exporter最对标的黑盒探测组件在生产环境全局单体部署无集群概念Node / 业务 Exporter 是一目标一 agent 天然分片只有 Prometheus 服务端才跑双副本 HA且那是上游采集器冗余不在 exporter 这层。agent 自身异常三层兜底异常类型兜底机制进程崩溃Prometheusup0告警 Dockerrestart: unless-stopped自动拉起静默误判如把 5xx 算健康指标通道与日志通道双通道交叉验证任一报异常都触发自愈动作出错默认只产处置建议、不直接写操作与 05 自愈闭环的「建议 审批」一致采集器与 agent 同时挂外部存活探针OCI Monitoring / 节点 exporter / cron 心跳兜底存储边界agent 只持久化派生产物数据类型存哪理由原始指标Prometheus专业存储负责 retention 与查询原始日志Loki同上原始告警/路由状态Alertmanager同上拓扑健康矩阵agent 本地排障推理的底座告警分级状态agent 本地P0/P1/P2 分级、根因归因、去噪后的有效告警自愈审计agent 本地处置建议内容、触发条件、审批/执行结果golden signal 快照agent 本地token 成本 / P99 / 质量退化等派生聚合值决策派生产物体量远小于原始流、且是 agent 真正产出价值的部分原始流留在专业存储由它们各自负责agent 按需临时拉取关联、查完即弃——既守住无状态定位又不丢推理能力。不变量监控数据全走可观测管道绝不混入 LLM 流量呼应 01 §2 旁路原则。与 K8s probe 分工监控 agent 的应用层巡检探 redis/gateway 业务语义健康如/status返回内容与 K8sliveness/readiness探针探进程是否存活、是否可接流正交——kube 层只管进程在不在agent 层管进程在但业务是否已坏互补而非重叠。自研边界不变量留给薄壳深度调查交给成熟引擎市面上有成熟的 AIOps/RCA 产品商业Datadog Watchdog、Dynatrace Davis、PagerDuty AIOps开源Aurora、IncidentFox、ninoxAI功能覆盖面很大——服务发现、依赖拓扑、告警收敛、LLM 根因分析、Slack/工单通知、复盘报告它们都有。那 monitoring-agent 为什么还要自研因为通用产品替代的是「功能」替代不了「不变量」不变量通用产品的默认行为冲突点无旁路 / 唯一计量点不理解「网关是唯一 LLM 计量口」监控流量会混入业务计量需改造产品不是配置项入站即 PII 脱敏把告警当数据存储脱敏是事后配置本项目脱敏在解析层进分析路径前已完成只建议、不写操作Aurora 反而自动生成修复 PR与「RCA 只产建议、自愈由 Operator 审批」冲突无状态、零持久化全是有状态平台Neo4j/Postgres/向量库与「agent 不存原始流」的存储边界相反边界划分不变量层自研薄壳巡检探活、旁路计量隔离、入站脱敏、fail-closed、级联归因的规则主线深度调查与自治执行留给成熟引擎Aurora / IncidentFox 的 agentic 调查、知识图谱、RAG 复盘。为什么这两个不能让步「零持久化」保护 PII 边界——存储点 攻击面 合规面原始流一旦落库agent 就从「分析层」变成「PII 落点」需要补加密 at-rest、访问控制、保留销毁、存储 HA 一整套。「只建议」保护二次故障——错误的自愈比半夜叫醒人更贵05 篇。真要放开必须先做动作分级read-only 随时、可逆重启/回滚/扩容限定条件自动、不可逆删数据/改配置强制人批外加预检、verify、连续失败熔断、全程审计。演进路线若未来要放开薄壳 → 加持久化补加密/RBAC/审计→ 加动作分级自治可逆类自动执行→ 深度调查接外部引擎。每步都对应一套新增治理不是加个开关就行。与本项目的关系本子弧的 monitoring-agent 定位是「验证不变量」的薄壳若演化成「小型事故管理平台」则与ai-agent-distributed-system自治运维子弧的边界需重新划分——届时决策点不再是「自研 vs 采购」而是「薄壳与引擎的接缝在哪」。核心要点监控的职责是把分散组件收敛成一张可推理的拓扑健康矩阵排障从盲找变推理。系统级巡检问在不在与应用内可观测查为什么职责不重叠。监控流量一律旁路业务计量/health探活不计 token用模型分析须带独立 tag 进运维账。指标Prometheus、日志Loki、LLM 异常Langfuse三通道同源、事件驱动最终汇于 monitoring-agent。agent 是无状态分析层被告醒才工作不轮询、不持久化原始流只持久化派生产物。单实例部署探的是全局共享组件多实例冗余无收益自身高可用由 Prometheusup指标承接对标 Blackbox Exporter。异常三层兜底进程崩溃靠up0告警 自动重启误判靠双通道交叉验证自愈出错因「只建议不写操作」天然隔离。服务清单自动发现方案 A新服务接 Prometheus 即被巡检STATIC_TARGETS兜底 k8s 外服务。依赖级联归因方案 COAP 真实调用边收敛根因STATIC_DEPENDENCIES兜底未接 agent 的依赖。自研边界通用产品替代「功能」替代不了「不变量」无旁路 / 入站脱敏 / 只建议 / 零持久化薄壳留自研深度调查交给 Aurora / IncidentFox 等成熟引擎。真要放开须先补加密存储、访问审计、动作分级与熔断。
