导读
监控定位体系建设的核心思想：围绕发现、定位两个核心能力，结合上下游依赖、时间两个维度，建设多层次、集中式的监控定位体系。本文首先介绍了一次典型的故障处理流程，然后给出了一种监控定位体系的建设思路。
典型的故障处理流程
一次典型的故障处理过程如下图所示，
对于比较简单的故障，定位过程可能会跳过业务、接口、模块三个层次，直接到实例级别。
监控定位体系建设思路
监控定位体系建设的核心思想：围绕发现、定位两个核心能力，结合上下游依赖、时间两个维度，建设多层次、集中式的监控定位体系。体系框图如下，
1.职责定义
监控体系的主要职责是发现问题、定位问题。发现问题时力求不漏报、少误报（发现问题不是本文的重点）。定位问题要求足够用、足够快，以下的设计都是为了达成这两个定位要求。
2.人员角色
参与故障处理的人，一般分为这几个角色：公司主管，业务线主管，子系统负责人，模块负责人，基础设置管理员。运维SRE会兼具这几个角色。不同角色在故障处理时关注的信息不同，这导致了监控体系的分层次建设(见下文)。
3.定位维度
典型的定位问题，需要根据上下游依赖关系逐层排查、抓住根因。上下游依赖关系，有如下集中展示形式，
- 业务质量大盘：按照
业务->接口->模块的总分层次，平铺展示服务质量信息，这个大盘一般需要具备全局观的童鞋来维度；- 端上客户体验可以通过用户访问质量来度量
- 关联关系拓扑：聚合接口或模块的质量数据，结合上下游依赖关系，以拓扑图的方式进行展示；
- 关联关系拓扑是业务质量大盘的智能化阶段
- 调用链路：展示一次请求的完整调用链路，服务质量信息通过文本来描述(一般用格式化日志)；
- 请求的上下游通过traceid来关联
为了降低业务含义的门槛，有时会将故障同时刻发生的典型事件做逐一排查，借此来加速故障定位。基于时间维度的定位，需要一个完整的事件墙，事件可能包括如下分类，
- 业务变更：模块代码发布，配置变更，服务路由变更，基础组件变更，基础设施变更，客户端发版等；
- 异常通知：聚合后的报警信息，平时容易被忽略的基础设施报警尤其不能缺少；
- 运营：营销活动，奖惩机制更新等；
- 安全：风控策略调整等；
- 其它：压测演练，盲测演练等；
4.监控分层
监控体系可以简单的划分为基础监控、应用监控、业务监控三个层次，
- 基础监控：监控对象为模块实例正常运行所依赖的基础资源，包括操作系统、机器硬件、基础设施（如专线、机房、网络设备）等；
- 应用监控：监控对象为可能影响模块实例可用性的自身指标，如端口存活、进程数、线程池大小、GC、错误日志等；
- 业务监控：主要用来度量服务质量，通过流量、延时、错误率三个指标来展现；
- 有客户端、服务端两个视角
- 有业务、接口、模块、实例四个层次
业务监控在发现和定位两个环节都会起到关键作用，需要着力去建设。业务监控的产品形态跟公司特点紧密相关，一般需要自研。
5.集中式产品
监控系统的产品能力输出，以集中式为宜。集中式一般表现为统一展示层，如同环比看板、红绿灯看板、事件墙等。集中式可以加速信息获取、降低学习成本、节约开发资源。至于每一个监控功能，可以有多个团队、各自独立开发（大部分公司现状即如此）。
优化方向
- 依靠人的经验来做决策的场景，需要降低信息的冗余度。如，报警通知聚合；
- 依靠人的经验来做决策的场景，可以逐步沉淀为自动化决策。如，时间维度的事件关联性自动推荐；
暂不考虑AI方向，实在还有些遥远，哈哈!
其它观点
- 监控平台的技术难点在存储（含计算），工程复杂度在采集，人力投入大头在产品（特别是业务监控产品）
- 监控产品形态的差异，主要由业务差异、用户习惯、服务模型等导致
推荐
偶然间翻到了一篇名为《监控体系建设》的文档，写的很全面、层次也很高，推荐给大家。作者彭华盛，在微信公众号”运维之路”上发表，本文引用的是其他网页资源。