监控要看哪些指标

监控首先应该回答哪种问题？

先回答用户和运营能否完成关键业务，再寻找技术原因。首页可开并不证明登录、下单或付款查询可用；CPU平稳也可能伴随数据库等待或外部渠道失败。业务观察与资源指标应共同使用，明确每个信号代表的对象、环境和时间，避免只有一个绿色总状态。

监控建设先确定业务链路、日志来源与告警动作。固定源码能够核对的现状是：应用配置公开 health 与 info 端点并关闭健康详情展示；网关健康不能代替后端和业务链路检查。 现有入口只覆盖其定义的健康范围，目标环境还需准备日志、业务查询和告警协作，验证后才能形成运行结论。

哪些消费者路径值得持续观察？

从浏览、登录、商品读取、提交订单、付款结果和售后查询中选择企业真正依赖的路径。每条路径写起点、输入、期望和拒绝条件；观察合法拒绝与技术故障分别出现的情况。没有身份或资料的探测可能一直返回简单错误，不能把它当作关键业务正常。

路径	可以观察的业务事实	相关技术信号	解释结果时的限制
浏览与商品	正确对象可读、图片可取得	入口响应、存储与数据库读取	缓存结果可能掩盖回源异常
登录与权限	合法主体能进入约定范围	会话、请求防护与授权错误	登录成功不表示能读所有资料
订单提交	正常成交或可解释拒绝	写入等待、冲突与错误分类	业务拒绝不能全部计为系统故障
支付查询	尝试、渠道结果与订单一致	回调、查询和处理积压	页面跳转不能证明付款已确认
履约协作	受理、出库和回传可解释	外部接口及未完成任务	下发成功不表示仓库已完成
售后与退款	关联和金额结果正确	查询、状态推进与渠道结果	退款受理不表示资金已到账

探测资料应为获授权的合成对象。包含写入或资金的探测必须限定用途、身份和清理，不在真实环境随意重复提交。也可以通过已有业务查询观察关键结果，避免为了监控制造新的业务影响。

错误怎样分类才不会误导处置？

分开身份失效、权限拒绝、业务条件不满足、请求冲突、依赖失败和程序错误。每种类别对应不同下一步：补身份、重新读取、修资料、查询结果或定位代码。若所有错误统一写成失败率，运行人员难以判断是否应停流量、扩资源或联系渠道。

分类依据要来自真实响应、日志和业务状态，不能由前端提示文字独立决定。固定源码的错误结构可核对：公共错误对象包含 code 与 message；具体状态码、字段及登录要求须以对应接口实现和契约为准。 具体接口仍按其契约解释。记录错误类型与业务路径的关联，保留脱敏样本，让同类告警可以聚合而不丢失影响信息。

应用、数据库和资源指标如何一起看？

应用请求增加时同步观察排队、连接使用、查询等待、内存变化和网络。CPU高可能有不同原因，连接池空闲也不能证明数据库没有锁竞争。选择同一时间范围核对，先确定受影响业务，再查看哪种技术信号与现象相关，避免抓取无关图表堆进报告。

后台导出、导入和计划作业要单独标记，它们可能在消费者访问不多时消耗大量资源。负载结束后观察积压是否清空、内存是否回落及连接是否恢复。指标定义与采样方式保持稳定，调整口径后记录变更，不把不同条件的历史曲线直接比较。

支付与外部同步应该观察什么？

观察业务结果可查询、未知状态可查证和未完成集合可解释。重试队列只能说明已经记录的任务，业务对账还需要发现没有产生任务的遗漏。支付尝试、ERP外部单号或仓库编号应能关联两侧结果，运行人员才可以区分未发送、已受理、已完成和未知。

没有真实渠道权限，记录访问限制，不把不可查询写成无错误。模拟链路用于验证自身逻辑，真实联调另有资料与环境要求。有关恢复和对账方法见接口重试与对账；按项目实施对账查询、差异处理与停止条件。

告警怎样对应一个可执行动作？

每条告警说明业务影响、确认资料、负责岗位和初步处理范围。仅报告“内存高”而没有应用、版本和持续情况，容易产生噪声；仅设置自动重启可能掩盖现场甚至放大故障。先判断需要人工确认、停止接流量、暂停作业还是排查依赖，再规定自动化边界。

告警聚合保留关键样本与时间，避免同一事件重复通知导致真正风险被忽略。恢复通知也应核对业务结果，而不只依据资源回落。运行窗口和升级方式按真实岗位确认，不在文章里假设长期值守或固定响应时间。

日志怎样既便于定位又保护资料？

日志需要业务编号、请求类别、版本和结果，帮助追踪跨系统过程，但不应打印密码、密钥、Cookie、完整个人资料或私有附件内容。字段保留、脱敏与访问按企业实际规则设计，查询权限与业务管理员权限分开。支持人员拿到日志也不意味着可以继续导出全部原始资料。

关联编号不应承载秘密值，也不能用消费者手机号作为所有日志的主要索引。保留范围、删除和归档需要说明用途与负责方；日志不可访问时明确证据缺失。这样故障报告才能诚实解释观察范围，而不是把不存在的资料推断为不存在的问题。

监控方案应该怎样验证？

在隔离环境构造合法拒绝、依赖不可用、数据查询异常和业务积压，检查信号、告警、定位及恢复链。每种情景限定范围，不以破坏真实渠道或生产资料为手段。验证不仅看告警是否发送，还要看接班人是否能理解影响和取得所需资料。

建立监控版本和变更记录，应用接口、业务或渠道变化后复验相关路径。已通过且没有变化的部分保留证据，不机械重复所有探测。新指标需要有解释和动作，不能为了看起来完整收集越来越多无人使用的数据。

运行团队应拿到什么资料？

提供指标字典、路径和身份范围、错误分类、告警动作、日志权限及已验证场景。未部署的采集、外部查询限制和未知业务规则继续列清。使用上线检查清单记录观察是否准备好，结合商城运维服务确认责任。

回到运维专题串联SLA、恢复和发布，并核对交付技术说明。监控的价值在于解释业务与促成处理，