浅谈业务监控指标数据经验总结

最近编写监控规范，在监控指标覆盖面的章节中设定了从基础设施、平台软件、应用软件、客户体验等范围要求。从规范角度，将规范中编写的覆盖指标落实是一个难题，尤其是业务监控指标。以下整理几点经验总结，希望给大家有帮助：

缺少必要的数据埋点 。从监控的分类看，监控可分为运行监控和应用监控，其中运行监控关注基础设施、资源监控、平台软件、性能监控、服务异常错误、端口监控、HTTP监控等，通常这类监控不需要埋点数据。业务监控关注业务状态、应用功能、应用数据是否正常的实时监控，通常需要在应用逻辑层面埋点数据。很多SRE组织没有推动运维左移，引入了类似NPM、APM、拨测，以智能运维算法应对非结构化数据等技术， 或者从业务数据库或应用日志的实时分析， “自力更生”的解决了部分业务监控缺少数据埋点的问题。 但是，由于这类数据在设计之初就不是为了监控而生成，所以应用在监控中往往有很多受限条件。

SRE不擅长发现业务逻辑层面的异常 。监控覆盖面通常是SRE的基本要求，尤其是在故障复盘中，故障的监控覆盖面不足、发现不够及时等问题均会归到SRE责任或由SRE跟进完善。这种方式推动着SRE需要持续的、主动的去增加监控发现能力，确保落实已知异常的监控发现策略，以及尽量落实未知异常的发现策略。不过，随着应用系统架构及逻辑越来越复杂，对于未知异常，以及应用逻辑与数据层面的异常，作为软件交付最后一环节的SRE很难掌握，这让“监控覆盖面第一责任人”的SRE组织十分被动（当然，业务监控是否作为研发与产品在上线前配套的职责也可以作为一个话题进行分析）。事实上，最擅长发现业务逻辑异常的角色是研发与产品，SRE需要推动业务监控到上线前的非功能性需求设计环节，让更加擅长判断业务异常的产品、研发人员落地相关监控要求。

SRE需要为业务监控数据埋点提供基础设施。理想情况下，业务监控要监控的范围最好推动产品、研发人员在设计研发阶段解决，但在实际操作过程中监控这类非功能性需求从来不是产品与研发人员最优先关注的内容。所以，SRE既要建立机制要求产品、研发人员落实规范，又要为他们带来直接收益。 所以，SRE一方面需要为监控数据采控涉及的数据采集、存储、计算、管理的基础设施能力，方便研发人员埋点数据；另一方面还需要为产品、研发人员提供所见即所得的配置监控策略、数据查询、看板与报表的数据消费功能应用。

埋点数据比落地监控更容易实现。由于产品、研发人员对“监控”的并不了解，作为对“监控”理解得更深入的SRE，还需要帮助产品、研发人员更好的理解“如何埋点业务监控数据”，这个思路可能比“落地业务监控”更加可行。比如， 制定一个埋点数据的范围指导：
（1）应用流水数据：应用流水数据指在应用逻辑过程中进行埋点，比如委托、订单、交易、登录、操作行为等数据。
（2）应用错误数据：针对关键的应用功能、服务反馈错误、接口超时、服务异常、数据同步失败等报错数据。
（3）应用性能数据：针对交易量、成功率、耗时/时延等应用性能指标数据。
（4）应用变更数据：针对重要参数、配置变更，应用程序版本变更，以及上下游的应用变更数据。

以终为始定好监控指标范围。关于业务监控的指标可以参考我在上一篇文章的内容：
（1）与单位时间内流量（吞吐率）相关的：业务相关的订单\委托\成交次数、性能相关的请求/响应/并发次数、基础相关的磁盘/网卡流量，以及持续积累的处理次数；
（2）与交易处理延迟（时延）相关的：业务相关的交易请求到响应时长、业务处理各环节的处理时长、基础涉及的IO wait/网络延时/集群心跳时延/数据同步时延。
（3）与饱和度（容量）相关的：业务相关的账户 账户数/证券代码数/交易单元数/每日订单/每日成交/每日接入网关连接/每日报盘数 ，应用涉及的TCP连接数/关键功能使用率/队列等待长度、基础涉及的CPU使用率/内存使用率/空间使用率/打开句柄次数。
（4）与错误相关的：应用与业务相关的失败率/错误率、关键功能错误次数/比例、数据丢失数量/比例、日志报错次数/比例、上游依赖报错状态、超时次数。