监控体系建设（完整）(2)

4)应用服务层

• 服务可用性监控：如服务、端口是否存在,是否假死等
• 应用营业状态监控：指应用的状态是否满足业务开业状态
• 应用性能：应用处理能力,比如交易量、成功率、失败率、响应率、耗时
• 应用交易：比如交易主动埋点、交易流水、ESB等

应用服务层监控可扩展的面与深入的度都有很大空间,具体介绍参见公众号另一篇梳理《应用可用性监控建设阶段小结》,以下是一部份应用监控点：

5)客户体验层

比如测速系统以及模拟用户访问的方式：
以模拟用户访问为例,通过模拟用户访问业务并校验返回数据结果,监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统.不仅仅是接入层(网站类业务是否能访问,访问的速度是否快),业务逻辑的验证就涉及到登录鉴权、关系数据自动化获取等.

二、监控整合

监控的分层的方式促进了每一个专业层的监控覆盖面与深度,防止建设失控,但也带来一个管理上的副作用,所以需要在事件、可视化、子系统、数据的整合,以减少管理成本.

在监控整合上,主要从事件汇总、统一可视化、监控数据汇总3方面进行梳理.

1、事件汇总

google sre解密一书中提过(大体意思如下)：监控应该尽可能简单的把需要人介入或关注的信息展示给运维团队,能通过自动化自愈解决、分析定位过程则不在一级视图提供.当前,能实现自愈的企业还比较少,或还在摸索建设过程中,所以我先讲讲如何让每天产生上亿条流水,触发上万次告警条件(同一告警如未解除会持续不断触发告警条件),来自各种不同工具、不同格式的的告警事件以尽可能简单的方式展示给一线监控团队.

第一章监控分层中提到,原有的监控工具以保留为主思路,这些工具在运营过程中每天都会产生大量事件,为了实现监控集中展示,集中管理,需要建设一个事件汇总的模块实现事件统一汇总,并对不同层面、不同专业角度的事件进行收敛,关联分析,更全面的感知系统运行状况.

可能上面讲得还不够清楚,举几个例子：

• 从可视化角度看,不同的工具有不同的监控事件展示界面,多个运维视图增加了运维技能要求,需要更多的人力去管理生产；
• 缺少对各类事件进行汇总与数据分析,无法反映生产系统整体的运行状况,如能将这些事件数据汇总起来,比如物理层的拓扑,则可以直观的管控应用状况；
• 同一个生产问题往往会带来多个维度的生产运行问题,比如一台物理机宕机,在这台物理机上的虚拟机都会出现网络、操作系统层面可用性、应用可用性、交易级状况、应用性能、客户体验的告警,如果监控指标足够丰富往往会有上百条以上,不能准确、快速定位问题根源.
• 每天能触发阀值的告警很多,以经验的方式很难让一线监控团队无时无刻能准确的定位哪些是高优先级的告警,比如磁盘空间到了70%的确需要有人去关注,评估是否进行数据清理、扩容,但这类告警属于低优先级的事件.

从上面4个例子可以看到,事件汇总模块需要有几个基本要求：

• 事件汇总：汇总不同层次、不同专业条线、不同类型事件是监控集中管理的基础.
• 事件收敛：前面提到同一个故障会触发多类指标的告警,同一个指标在故障未解除前也会重复产生大量的告警事件,如果将全部事件都展示出来,那对于监控处理人员将是灾难性的,所以需要进行事件收敛(关于收敛的思路可以见公众号另一篇关于事件收敛的文章)
• ?事件分级：对于不同的事件需要有适当层次的事件分级,事件升级的策略.事件分级是将事件当前紧急程度进行标识显示,事件升级是对于低级的事件当达到一定的程度,比如处理时间过长,则需要进行升级.
• ?事件分析：事件分析是建立事件的关联关系,关联分析可以从纵向和横向关系进行分析,纵向是指从底层的基础设施、网络、服务器硬件、虚拟机/容器、操作系统、中间件、应用域、应用、交易；横向是指从当前的应用节点、上游服务器节点、下游服务器节点的交易关系.事件分析是形成故障树,自愈的基础.对于事件分析重点在于关系模型的建立,互联网公司有不少标准化的方案,但我个人认为需要开发团队介入改造的标准化不可控,所以另外一方向是针对企业内部特点,以CMDB、应用配置库为中心,或以节点型的系统为中心去建立关系模型,具体介绍见第三章.
• 高性能：为了实现实时监控,需要事件汇总模块具备高性能.
• 对外提供采集事件数据接口：监控作为一体化运维体系的一部份,需要对外提供服务化接口,支持事件数据的采集.

2、统一可视化

不同监控工具有着不同界面,不同的操作方法,对工具的掌握程度依赖于运维人员的经验,监控管理很难形成标准化,不利于监控的集中管理、释放人力成本.所以,监控事件汇总后,需要有一个统一的可视化,支持统一展示、多类型展示形式、多维用户视角、支持按需订阅的特点.具体包括：

支持事件的统一展示：支持不同角色用户管理不同的事件,包括事件的受理、分派、督办、升级、解除、转工单等闭环操作,无需在不同工具上多次操作.

多类型的展现形式：PC电脑的web端,移动手持端,大屏展示,为了支持可视化的快速开发,以及低成本的过渡到移动手持端,建议采用H5的技术选型.

多维用户：根据不同机构、不同用户的关注点,比如一线运维主要关注实时告警,二线运维主要关注事件丰富与故障树等辅助定位,值班经理主要关注当天监控事件处理情况,团队管理者主要关注团队内监控事件与重要业务系统运行状况,主管经理主要关注整合的运行情况与人员处理情况,开发人员需要有协助处理的视角数据等.

支持用户订阅展示,针对不同的业务运营场景、不同的用户进行布局、推送数据、监控指标的订阅式展示,比如,双十一或秒杀的运营活动,需要关注几十个OS的资源情况,各个OS上的交易、性能情况,如果每一个指标一个窗口,需要看几十个窗口；如果只看告警信息,又无法观察到趋势；所以,需要支持多指标合并在一个视图页面的订阅功能.

3、数据整合标准

关于数据整合,这里不再复述不同监控工具事件数据的整合,主要从报文、日志、数据库流水几个角度分析：

1)报文解释：

报文解释标准,以天旦BPC为例做个介绍.

（编辑：ASP站长网）