集成状态监控要盯住的是每一条具体连接是否在跑、数据是否正确流转、出错后多久被发现和恢复。本文按“盘点连接—定义指标—分级告警—值班响应—验收复盘”的顺序，给出可直接套用的清单、指标口径和告警规则，范围限于系统连接可靠性，构建发布管理与接口自研不在本篇展开。
要点总览（TL;DR）
- 集成状态监控以每条具体连接为最小单元，围绕连通性、执行结果、时效与积压、异常处置四个层面设定指标，平台级汇总只能作为概况参考。
- 落地按四步推进：盘点连接建立清单，定义成功、失败、延迟等口径与指标，配置分级告警与值班响应，最后用故障演练和验收清单确认机制可用。
- 阈值以业务时效要求为基准推导，例如端到端要求 15 分钟时，可在 10 分钟预警、15 分钟告警；连续失败次数结合执行频率换算成中断时长。
- 告警按业务影响等级、连续失败次数、积压量和持续时间分级，并设置合并窗口与恢复通知，避免同一连接重复失败淹没真正的新问题。
- 判断监控是否有效，看故障从发生到被发现、被定位、被恢复的时长能否统计出来并持续下降；改进结论转为有责任人和期限的工作项跟踪到关闭。
先回答：集成状态监控要盯住哪几件事
监控对象应当落到每一条具体连接上，例如“订单系统到履约系统的订单同步”“CRM 到数据仓库的客户主数据同步”。平台级的总成功率只能说明整体概况，无法回答是哪条连接出了问题、影响了哪个业务。把连接作为监控的最小单元，指标、告警、责任人都能挂到同一个对象上，排查时才有明确入口。
围绕每条连接，需要回答三类问题：
- 连接是否存活：接口能否调通、定时任务是否按时触发、最近一次成功是什么时候。
- 数据是否正确流转：执行成功还是失败、失败率多少、有没有连续失败、端到端延迟和待处理积压是否在可接受范围。
- 异常是否被及时处置：从失败发生到被发现、被定位、被恢复各用了多长时间，是否有人负责跟进到关闭。
这三类问题对应四个观测层面：连通性、执行结果、时效与积压、异常处置。前三个层面回答“连接现在怎么样”，第四个层面回答“出问题时团队反应得怎么样”，两者缺一不可。
状态口径必须在建设监控之前统一定义。同一个失败事件，集成开发人员可能认为“重试成功就算正常”，业务方可能认为“只要延迟超过十分钟就是故障”。如果“成功”“失败”“延迟”没有书面口径，指标算出来各方也不会认同。口径要写清成功与失败的判定条件、重试是否计入失败、统计窗口是五分钟还是一小时，并作为监控配置的依据固定下来。
需要说明边界：本文讨论的是连接建立之后的运行可靠性监控。连接所依赖的构建发布流程归研发交付管理，接口本身的开发与扩展归开放接口与扩展开发，这两部分只在影响连接状态时作为背景提及。
第一步：盘点集成连接并建立可监控清单
监控的输入是一份完整的连接清单。没有清单，指标无从挂载，告警也不知道该通知谁。盘点可以从四个来源收集：接口文档与集成设计说明、中间件与 ESB 配置、定时任务与调度平台的任务列表、以及人工同步的操作记录。人工同步最容易被遗漏，但恰恰是故障影响最直接的部分，需要单独访谈相关岗位确认。
清单建议包含以下字段，缺一项都会在后续环节造成断点：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 连接名称 | 用“来源系统-目标系统-数据对象”命名，全团队唯一 | 指标、告警、工单的统一标识 |
| 来源系统 / 目标系统 | 写系统全称，注明负责团队 | 定位故障归属方 |
| 数据方向 | 单向或双向，写明主数据流向 | 判断失败影响哪一侧 |
| 触发方式 | 定时、事件触发、手动、实时消息 | 决定探活与延迟的采集方式 |
| 频率 / 时效要求 | 如每 5 分钟一次，端到端不超过 15 分钟 | 设定延迟阈值 |
| 责任人 | 集成负责人与业务方联系人各一名 | 告警通知与升级对象 |
| 业务影响等级 | 高 / 中 / 低，附一句影响说明 | 决定监控投入与告警级别 |
业务影响等级要按“连接中断后多久会影响对外交付或财务结算”来评，而不是按系统大小评。影响订单履约、对账结算、客户可见状态的连接定为高等级；影响内部报表、非实时分析的定为中或低等级。等级直接决定后面告警的通道和响应时限，评错会导致高影响连接用低级别告警，半夜故障无人响应。
清单需要版本化维护。新增连接必须先登记清单、补齐字段，才能上线运行；连接下线或变更频率、责任人时同步更新。可以把“清单已登记”作为集成上线检查的一项，由集成负责人确认。清单本身放在团队可共同访问的文档中维护，保留变更记录，便于追溯某次故障时当时的配置是什么。
第二步：定义状态口径与监控指标
指标要能对应到具体连接，并且能从现有日志、调度平台或集成中间件中取到数。建议按四个层面各选一到两个核心指标，先跑通再扩充，避免一开始就设计几十个指标却无人维护。
| 层面 | 指标 | 口径说明 | 采集来源 |
|---|---|---|---|
| 连通性 | 最近成功时间 | 该连接最近一次完整成功的时间戳，超过约定周期未更新即视为异常 | 调度记录、接口调用日志 |
| 连通性 | 探活结果 | 定时对接口或任务做一次轻量探测，记录通或不通 | 探活脚本、监控平台 |
| 执行结果 | 失败率 | 统计窗口内失败次数 ÷ 总执行次数，重试按最终结果计入 | 执行日志 |
| 执行结果 | 连续失败次数 | 从最近一次成功之后累计的失败次数，成功即清零 | 执行日志 |
| 时效与积压 | 端到端延迟 | 数据在来源系统产生到在目标系统可用的时间差，取分位值 | 业务时间戳比对 |
| 时效与积压 | 待处理队列长度 | 某一时刻尚未处理完的消息或任务数量 | 队列监控、调度平台 |
| 异常处置 | 发现时长 / 恢复时长 | 从首次失败到告警送达、从告警到恢复成功的时间 | 告警记录与恢复记录 |
口径统一要落到三条规则上。第一，成功与失败的判定：以目标系统确认接收为准，仅发出请求不算成功。第二，重试的处理：重试后最终成功的不计入失败次数，但连续失败次数按首次失败起算，避免无限重试掩盖问题。第三，统计窗口：失败率按滚动一小时或按批次统计，需在指标定义中写明，不同连接可以用不同窗口，但同一连接的口径不能随意改。
阈值设定以业务时效要求为基准，而不是拍一个整数。例如连接要求端到端不超过 15 分钟，延迟阈值可设在 10 分钟预警、15 分钟告警；连续失败次数达到 3 次即触发告警，因为按 5 分钟频率计算，3 次意味着已中断约 15 分钟。阈值写进指标定义表，与连接清单一起维护。
指标定义表建议每个指标一行，写明指标名、适用连接、计算公式、采集来源、统计周期、预警阈值、告警阈值和责任人。这张表是配置监控和后续调整的唯一依据，避免不同人按不同理解配置出互相矛盾的规则。
第三步：分级告警与值班响应机制
告警分级的依据是业务影响等级、连续失败次数、积压量和持续时间四个因素的组合。高影响连接连续失败 3 次或延迟超过业务时限，定为一级告警，立即电话通知一线值班并同步业务方；中影响连接失败率达到阈值或积压持续增长，定为二级，通过即时消息通知集成负责人，一小时内响应；低影响连接的非连续失败定为三级，进入日报汇总，次日处理。分级规则要写成表，配置到告警系统中，减少人工判断。
通知路径按“一线值班—二线负责人—业务方通报”三级设置。一线值班负责接收告警、做初步定位（确认是网络、凭证、数据格式还是目标系统故障），在约定时限内无法恢复则升级到二线集成负责人；影响对外交付的高等级故障，同时向业务方通报影响范围和预计恢复时间。每一级都要有明确的响应时限和升级触发条件，例如一级告警 15 分钟未确认自动升级。
告警内容要让人不看系统也能判断严重程度，至少包含：连接名称、失败现象（错误码或错误摘要）、首次发生时间、已连续失败次数、影响范围（涉及的业务对象和下游系统）、当前值班人。缺少首次发生时间，值班人员无法判断是刚发生还是已持续数小时。
抑制与去重是防止告警风暴的关键。同一连接在短时间内重复失败，合并为一条告警并累计次数，恢复后发送一条恢复通知；由同一根因引发的多条连接告警（例如某个中间件宕机导致十条连接同时失败）可以按依赖关系归并到主告警下。去重规则要写清楚合并窗口长度，例如 30 分钟内同一连接只发一条，避免值班人员被重复消息淹没而忽略真正的新问题。
恢复确认与关闭条件同样要定义：目标系统确认数据已补齐、积压清零、连续成功达到约定次数后，才能关闭告警；关闭时记录恢复时间、处理人和根因分类。这条记录是后面计算恢复时长和做复盘的原始数据。
角色分工与各环节交付物
监控建成后无人维护是常见失败原因。把每个环节的责任人和交付物固定下来，机制才能持续运转。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 集成负责人 | 维护连接清单与指标定义，审核新增连接登记 | 连接清单、指标定义表 | 连接上线前、每月更新 |
| 平台 / 运维 | 采集监控数据、配置告警规则、保障监控自身可用 | 告警配置、监控运行记录 | 指标定义确认后一周内完成配置 |
| 值班人员 | 接收告警、初步定位、按流程升级、记录处置过程 | 告警处置记录 | 每次告警关闭时 |
| 业务方 | 确认影响范围、参与恢复验证 | 恢复确认意见 | 高等级故障恢复时 |
交接时点要具体：新增连接由集成负责人在上线前完成清单登记和指标定义，平台角色据此配置监控，两者都完成才允许上线；告警处置记录在关闭告警时同步填写，作为月度复盘的输入。角色可以由同一人兼任，但职责不能空缺，尤其是监控自身的可用性需要有明确归属。
一个示例：订单同步连接的监控配置
以下为演示情景，用于说明前几步如何组合，实际配置需按团队系统情况调整。
清单填写：连接名称为“订单系统-履约系统-订单同步”，来源系统订单中心，目标系统履约平台，数据方向单向，触发方式为定时任务每 5 分钟一次，时效要求端到端不超过 15 分钟，集成负责人为订单组张工，业务方联系人为履约运营李工，业务影响等级为高（影响发货时效）。
指标与阈值：最近成功时间超过 10 分钟未更新触发预警，超过 15 分钟触发告警；连续失败 3 次触发一级告警；待处理订单积压超过 500 单或延迟超过 15 分钟触发一级告警；失败率按滚动一小时统计，超过 5% 触发二级告警。
告警与通知：一级告警电话通知一线值班，同时即时消息通知张工与李工；二级告警仅即时消息通知张工；同一连接 30 分钟内重复失败合并为一条，恢复后发送恢复通知。
一次失败走查：14:05 定时任务因目标系统凭证过期开始失败，14:20 连续失败达到 3 次，系统发出合并后的一级告警，包含连接名称、错误摘要“认证失败”、首次发生时间 14:05、影响范围“待发货订单”。一线值班 14:23 确认告警并定位为凭证问题，14:35 更新凭证后手动补跑，14:50 积压清零、连续成功 3 次，关闭告警并记录恢复时间与根因。本次从发生到恢复共 45 分钟，其中发现用时 15 分钟，可作为后续改进的基线。
完成检查：监控机制是否真的可用
建设完成后，用下面这份清单逐项核对，每项给出通过标准，未通过的项目回到对应步骤补齐。
| 检查项 | 通过标准 |
|---|---|
| 连接清单覆盖率 | 所有在跑的连接均已登记，抽查调度平台任务与清单一致，无遗漏的人工同步 |
| 指标可计算 | 每个核心指标都能从现有日志或平台取到数，并已实际算出至少一个统计周期的值 |
| 告警有效性 | 已做至少一次故障演练，告警在约定时限内送达正确的人，内容包含定位所需信息 |
| 去重与抑制 | 模拟同一连接连续失败，确认只收到一条合并告警及一条恢复通知 |
| 处置闭环 | 每次告警关闭均有恢复记录，记录含发现时长、恢复时长和根因分类 |
| 监控自身可用性 | 采集中断或探活脚本停止时，有独立机制发现并通知平台角色 |
| 口径一致性 | 集成负责人与业务方对“成功”“失败”“延迟”的理解与指标定义表一致 |
验收的核心判断是时间可度量：故障从发生到被发现、被定位、被恢复的时长能否统计出来，并在后续月份持续下降。如果这些时间取不到数，说明监控还停留在“有告警”的阶段，尚未形成可改进的机制。
把监控结果接入研发协作流程
告警关闭不等于问题结束。每次高等级故障和月度复盘得出的改进结论，都应转为有责任人和期限的工作项，例如“修复订单同步凭证轮换机制”“为三条高影响连接补充积压告警”，进入团队日常任务列表跟踪到完成。连接清单、指标定义表和告警分级规则作为文档资产维护，变更时保留记录，新增连接按同一流程登记。
巡检与复盘节奏建议按月进行：核对清单与实际运行连接是否一致，检查告警数量和误报比例，统计各连接的发现时长与恢复时长，挑出一到两个反复出问题的连接做根因分析。复盘结论同样转为工作项，形成“监控发现—工作项跟踪—修复验证—口径更新”的循环。
这些管理动作可以在 ONES 中承载：告警和复盘结论转为工作项，指派责任人与期限并跟踪状态流转；连接清单与指标定义作为文档维护，变更留痕；评审与恢复确认记录随工作项保存。ONES 提供开放 API 与第三方应用对接能力，可用于与企业系统打通数据；其 DevOps 解决方案支持集成 Jenkins、GitLab CI 等流水线工具并同步执行状态和日志。需要说明的是，连接级的心跳探活、失败率、延迟与积压监控及告警配置，需在选型时结合官方文档单独核验，本文不将其作为既有能力描述。
常见问题
连接数量很多，初期应该先给哪些连接配监控？
按业务影响等级排序，优先覆盖中断后最快影响对外交付或财务结算的连接，例如订单履约、对账结算、客户可见状态相关的同步。高影响连接先配齐连通性、执行结果和时效三类指标；中低影响连接可以先只做最近成功时间与连续失败次数两项，跑通后再补延迟和积压。清单里每条连接都登记，但监控投入按等级分批推进，避免一次性铺开导致配置质量下降。
重试机制存在时，失败率怎么算才不会被掩盖？
建议把“最终结果”和“过程失败”分开统计。失败率按重试后的最终结果计算，反映业务是否真正受影响；连续失败次数从首次失败起算、成功才清零，用来暴露被重试掩盖的持续异常。这样一条连接即使每次重试都成功，只要连续失败次数持续增长，仍会触发告警，值班人员可以据此排查凭证过期、目标系统不稳定等根因。
告警发出后经常没人处理，机制上怎么补？
先检查告警是否送达了正确的人，再检查响应时限是否明确。每条告警应包含连接名称、失败现象、首次发生时间、影响范围和当前值班人；一级告警设置确认时限，超时未确认自动升级到二线负责人，高影响故障同时通报业务方。值班表按周排定并提前公布，告警处置记录在关闭时填写，月度复盘时统计各连接的发现时长与恢复时长，把长期无人响应的连接单独拿出来分析。
监控系统自身出问题时怎么发现？
监控自身也需要一条独立的检查路径。可以为采集任务和探活脚本设置心跳，超过约定周期没有数据上报时，由另一套机制通知平台角色；同时定期核对调度平台的实际任务与连接清单是否一致，防止新增连接未纳入监控。验收清单中“监控自身可用性”一项要求采集中断时有人知道，这条在故障演练中一并验证。
监控发现的问题如何进入团队日常工作并跟踪到关闭？
把每次高等级故障和月度复盘的改进结论转为工作项，写明责任人、期限和验收方式，进入团队任务列表跟踪状态流转。连接清单、指标定义表和告警分级规则作为文档资产维护，变更保留记录。这类管理动作可以在 ONES 中承载：工作项跟踪责任人与期限，文档维护清单与口径，评审与恢复确认记录随工作项保存。ONES 提供开放 API 与第三方应用对接能力，可用于与企业系统打通数据；其 DevOps 解决方案支持集成 Jenkins、GitLab CI 等流水线工具并同步执行状态和日志。连接级的心跳探活、失败率、延迟与积压监控及告警配置，需在选型时结合官方文档单独核验。
