监控体系建设（一）：监控体系分层与整合
近年来，随着计算机技术的飞速发展，以及行业信息的共享,传统企业的运维己不再是固步自封，日新月异的计算技术的发展推动企业云平台的建设，云平台的计算能力为大数据分析提供了基础、云平台与大数据分析又将推动运维人工智能的发展。
放眼云、大数据、人工智能的运维发展方向的同时，作为运维的生命线，安全生产保障的生命线仍需强调。作为传统企业的安全生产保障，主要以“监”、“管”、“控”为核心，其中“监”则主要指的的监控。
以下，从五个方面对监控建设思路进行梳理，本文为第一章：体系分层与体系整合。
1、体系分层：
-专业条线角度的分布：
-各层职责：
2、体系整合
-事件整合：事件上收，判定、清洗，统一合并、收敛
-可视化整合：多维、多渠道、可订阅
-整合标准：整合标准（日志、流水、数据库连接等）、数据再利用
3、监控指标
指标分类、指标权重与阀值分级、指标基线
4、事件处理
-事件关联：事件压缩、事件丰富、事件扩散、事件收敛
-事件应急（启停、日志获取、应用可用性分析、运维文档等）
-事件分析引擎：影响分析、根源分析、一键健康性检查
-智能化（动态基线、故障分析树、故障自愈、无人值守望、预测性监控）
5、持续整改
-不漏报
-减少误报
一、 监控体系分层
1、概述：
传统企业的运维经过多年的积累，往往己沉淀下来不少监控工具，有不同专业条线的工具，如基础设施、硬件、软件、安全等；也有不同类型的工具，如基于日志、数据库、中间件、操作系统、网络报文等。对于这些工具，我们采用以下方式处理：
-建立集中监控平台，在一体化运维体系中，监控平台贯穿所有环节，它起到了生产系统涉及的软硬件环境实时运行状况的“监”，监控平台事件驱动的特性也为一体化运维体系起到神经网络驱动的作用，进而进行了“控”，另外，监控平台优质的运维数据可以作为运维大数据分析的数据源，实现运维数据采集的角色。为了提高投入效率，减少重复投入，需要建立集中监控平台实现统一展示、统一管理，支持两地三中心建设，具备灵活的扩展性，支持运维大数据分析；
-原有的监控工具保留为主：当前并没有哪一个监控工具可以覆盖所有生产系统的运行指标，己沉淀下来的监控工具往往是当前生产系统深度定制的工具，俱有存在价值。另外，虽然监控平台从WEB、APP、到DB均采用了多中心双活分布式架构部署，但为保证监控覆盖能力，部份重要的环节仍建议不仅限一套监控工具。
-各专业条线对各条线的监控负责：各专业条线是最清楚自己需要什么监控的团队，各专业条线对监控覆盖率负责，监控平台的建设方负责平台体系的建设，提供基础技术支撑。
-工具间整合：不同的专业条线、不同的分析技术可以有不同的监控工具，采用这种多点开花的建设方式更有助于监控面与深度的完善，所有的工具最终需要进行标准化的整合。
基于上面4个处理思路，为防止监控建设失控，减少重复建设、明确主要的建设目标，我们需要对监控工具进行体系化管理，体系化管理首先要做的就是进行监控体系分层。
2、分层方式：
相信每家企业对于监控分层体系都会有各自的划分方式，以下是以专业条线方式分层：
1）基础设施层：包括运营商专线、机房（机房内的设施，比如制冷、安防等）、网络设备，基础设施层的监控分为状态、性能、质量、容量、架构、流量分析等几个层面。
2）系统服务器层：包括系统服务器、存储等服务器的可用性状态。
3）系统及网络服务层：系统及网络服务层主要是指操作系统、系统软件、网络软件的使用情况。 4）应用服务层：应用服务层主要是针对应用服务可用性、应用营业状态、应用性能、应用交易量分析几方面。
5）客户体验层：客户体验层包括两块，一是客户访问速度；二是功能是否正常，具体指的是全部、局部、个别用户或终端访问情况，不仅包括业务系统是否能访问，访问的速度是否快，还包括业务逻辑的验证功能是否正常。
3、各层职责
1）基础设施层
- 状态监控包括机房供电、空调、网络设备的软硬件状态，如设备状态等；
- 性能监控包括设备的性能情况，比如CPU、内存大小、session数量、端口流量包量、内存溢出监控、内存使用率等；
- 网络监控包括设备错包、丢包率，针对网络设备以及网络链路的探测延时、丢包率监控等；
- 容量监控包括设备负载使用率、专线带宽使用率、出口流量分布等；
由于基础设施硬件往往己有设备健康性的检测机制，建议向这类厂商提要求，将设备的运行事件主动送到监控平台整合。
2）服务器层
- 存储：包括存储设备，以及设备上的硬盘读写错误、读写超时、硬盘掉线、硬盘介质错误；
- 服务器上的内存（内存缺失、内存配置错误、内存不可用、内存校验）、网卡（网卡速率；电源：电源电压、电源模块是否失效）、风扇（风扇转速等）、Raid卡（Raid卡电池状态、电池老化、电池和缓存是否在位、缓存策略）
- 虚拟机：vcenter等
- 容器：docker等
存储、物理设备、虚拟机等建议参考基础设施层由厂商主动汇总事件到监控平台，由于容器方面的监控工具并不多，则需根据实际情况选择是否借鉴开源的工具进行自研。
3）系统服务层：
系统服务层的数据主要包括操作系统、中间件、数据库，以及其它开源分布式中间件等工具，这方面包括很多，以操作系统为例，包括：CPU（CPU整体使用率、CPU各核使用率、CPU Load负载）、内存（应用内存、整体内存、Swap等）、磁盘IO（读写速率、IOPS、平均等待延时、平均服务延时等）、网络IO（流量、包量、错包、丢包）、连接（各种状态的TCP连接数等）、进程端口存活、文件句柄数、进程数、内网探测延时、丢包率等。
在分析系统服务层的数据消费情况时，可以通过分析系统性能情况，客观衡量业务负载高低情况，并结合扩缩容调度，实现业务的负载和成本间的平衡。可以根据服务器所在业务层级（接入层、逻辑层还是数据层）的不同，设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则，设置业务模块（由相同功能的多个服务器构成的业务集群）的扩缩容规则；由系统计算出服务器、业务模块的负载情况，决策出是否需要扩容或缩容，触发业务模块的扩缩容操作。
这一层的工具主要采用引入成熟工具或自研的方式，可选的空间比较大，只要覆盖面够广、支持灵活的二次定制开发，应该问题都不大，建设过程中，我认为中间件与数据库两块是值得让DBA、中间件管理员深度挖掘监控指标覆盖面。
另外，在互联网分布式架构的推动下，传统企业也逐步使用一些分布式中间件，比如分布式数据库中间件，内存数据库、消息队列等。由于对于这类开源中间件，传统企业在技术上弱于互联网企业，且监控工具并不多，需要重点投入资源进行相关监控指标的开发。
4）应用服务层
- 服务可用性监控：如服务、端口是否存在，是否假死等
- 应用营业状态监控：指应用的状态是否满足业务开业状态
- 应用性能：应用处理能力，比如交易量、成功率、失败率、响应率、耗时等
- 应用交易：比如交易主动埋点、交易流水、ESB等
应用服务层监控可扩展的面与深入的度都有很大空间，具体介绍参见公众号另一篇梳理《应用可用性监控建设阶段小结》，以下是一部份应用监控点：
5）客户体验层
比如测速系统以及模拟用户访问的方式： 以模拟用户访问为例，通过模拟用户访问业务并校验返回数据结果，监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统。不仅仅是接入层(网站类业务是否能访问，访问的速度是否快)，业务逻辑的验证就涉及到登录鉴权、关系数据自动化获取等。
二、 监控整合
监控的分层的方式促进了每一个专业层的监控覆盖面与深度，防止建设失控，但也带来一个管理上的副作用，所以需要在事件、可视化、子系统、数据的整合，以减少管理成本。
在监控整合上，主要从事件汇总、统一可视化、监控数据汇总3方面进行梳理。
1、事件汇总
google sre解密一书中提过（大体意思如下）：监控应该尽可能简单的把需要人介入或关注的信息展示给运维团队，能通过自动化自愈解决、分析定位过程则不在一级视图提供。当前，能实现自愈的企业还比较少，或还在摸索建设过程中，所以我先讲讲如何让每天产生上亿条流水，触发上万次告警条件（同一告警如未解除会持续不断触发告警条件），来自各种不同工具、不同格式的的告警事件以尽可能简单的方式展示给一线监控团队。
第一章监控分层中提到，原有的监控工具以保留为主思路，这些工具在运营过程中每天都会产生大量事件，为了实现监控集中展示，集中管理，需要建设一个事件汇总的模块实现事件统一汇总，并对不同层面、不同专业角度的事件进行收敛，关联分析，更全面的感知系统运行状况。
可能上面讲得还不够清楚，举几个例子：
- 从可视化角度看，不同的工具有不同的监控事件展示界面，多个运维视图增加了运维技能要求，需要更多的人力去管理生产；
- 缺少对各类事件进行汇总与数据分析，无法反映生产系统整体的运行状况，如能将这些事件数据汇总起来，比如物理层的拓扑，则可以直观的管控应用状况；
- 同一个生产问题往往会带来多个维度的生产运行问题，比如一台物理机宕机，在这台物理机上的虚拟机都会出现网络、操作系统层面可用性、应用可用性、交易级状况、应用性能、客户体验的告警，如果监控指标足够丰富往往会有上百条以上，不能准确、快速定位问题根源。
- 每天能触发阀值的告警很多，以经验的方式很难让一线监控团队无时无刻能准确的定位哪些是高优先级的告警，比如磁盘空间到了70%的确需要有人去关注，评估是否进行数据清理、扩容，但这类告警属于低优先级的事件。
从上面4个例子可以看到，事件汇总模块需要有几个基本要求：
- 事件汇总：汇总不同层次、不同专业条线、不同类型事件是监控集中管理的基础。
- 事件收敛：前面提到同一个故障会触发多类指标的告警，同一个指标在故障未解除前也会重复产生大量的告警事件，如果将全部事件都展示出来，那对于监控处理人员将是灾难性的，所以需要进行事件收敛（关于收敛的思路可以见公众号另一篇关于事件收敛的文章）
- 事件分级：对于不同的事件需要有适当层次的事件分级，事件升级的策略。事件分级是将事件当前紧急程度进行标识显示，事件升级是对于低级的事件当达到一定的程度，比如处理时间过长，则需要进行升级。
- 事件分析：事件分析是建立事件的关联关系，关联分析可以从纵向和横向关系进行分析，纵向是指从底层的基础设施、网络、服务器硬件、虚拟机/容器、操作系统、中间件、应用域、应用、交易；横向是指从当前的应用节点、上游服务器节点、下游服务器节点的交易关系。事件分析是形成故障树，自愈的基础。对于事件分析重点在于关系模型的建立，互联网公司有不少标准化的方案，但我个人认为需要开发团队介入改造的标准化不可控，所以另外一方向是针对企业内部特点，以CMDB、应用配置库为中心，或以节点型的系统为中心去建立关系模型，具体介绍见第三章。
- 高性能：为了实现实时监控，需要事件汇总模块具备高性能。
- 对外提供采集事件数据接口：监控作为一体化运维体系的一部份，需要对外提供服务化接口，支持事件数据的采集。
2、统一可视化
不同监控工具有着不同界面，不同的操作方法，对工具的掌握程度依赖于运维人员的经验，监控管理很难形成标准化，不利于监控的集中管理、释放人力成本。所以，监控事件汇总后，需要有一个统一的可视化，支持统一展示、多类型展示形式、多维用户视角、支持按需订阅的特点。具体包括：
支持事件的统一展示：支持不同角色用户管理不同的事件，包括事件的受理、分派、督办、升级、解除、转工单等闭环操作，无需在不同工具上多次操作。
多类型的展现形式：PC电脑的web端，移动手持端，大屏展示，为了支持可视化的快速开发，以及低成本的过渡到移动手持端，建议采用H5的技术选型。
多维用户：根据不同机构、不同用户的关注点，比如一线运维主要关注实时告警，二线运维主要关注事件丰富与故障树等辅助定位，值班经理主要关注当天监控事件处理情况，团队管理者主要关注团队内监控事件与重要业务系统运行状况，主管经理主要关注整合的运行情况与人员处理情况，开发人员需要有协助处理的视角数据等。
支持用户订阅展示，针对不同的业务运营场景、不同的用户进行布局、推送数据、监控指标的订阅式展示，比如，双十一或秒杀的运营活动，需要关注几十个OS的资源情况，各个OS上的交易、性能情况，如果每一个指标一个窗口，需要看几十个窗口；如果只看告警信息，又无法观察到趋势；所以，需要支持多指标合并在一个视图页面的订阅功能。
3、数据整合标准
关于数据整合，这里不再复述不同监控工具事件数据的整合，主要从报文、日志、数据库流水几个角度分析：
- 报文解释：
报文解释标准，以天旦BPC为例做个介绍。
市场上有很多APM，大体可以分为主动模拟拨测、页面插入代码监测、客户端插件采集、服务端代理收集、服务端旁路报文监听（详细的分类可以见公众号另一篇关于APM的文章）。天旦的BPC采用服务端的网络层旁路抓取一份报文，通过预先定义好的解码策略，解出了一份数据格式良好的数据源。在这份数据源之上可以进行监控、运维数据分析等运维场景的使用。由于BPC报文解码配置设计比较简单，支持秒级（预计17年将有毫秒级的产品出来），且对应用服务性能无影响，用旁路报文解释的方式作为数据输入标准成为一种值得推荐的方式。
- 日志结构标准：
日志结构标准，主要分两类，一类是直接建一个日志分析平台，比如国外的splunk、国内的日志易，或者开源的ELK（日志易也是用了ELK）;另一类是重构日志标准组件，比如重构java企业应用中经常使用的log4j开源包的标准输出方法，对日志结构进行整合，并通过异步消息的方式将日志发送给监控平台，再提供可视化的IDE对不同系统的日格式进行进一步整理，将需要的数据抽取整合。
- 数据库流水标准：
在监控数据库流水中，也分两类，一类是建立标准的运维流水表，监控直接读取这些流水进行监控或分析；另一类参考重构log4j的思路，对jdbc的包进行重构，将数据库执行语句，以及语句执行过程中的开始时间、结构时间、返回状态进行记录。第一类我们用得比较多，当前的交易级的监控主要采用这种方式进行，第二类目前仍处于思路阶段。
- 其它思路：
其实针对日志LOG4J、数据库JDBC这两种方式从思路看都是从节点类的模块进行，往同类扩展，可以针对标准应用中间件、WEB等模块进行处理；往大的扩展，则比如企业ESB类的应用系统可以作用标准的数据整合。这些节点类的模块进行数据整合标准往往可以有事半功倍的作用。