一场监控平台架构培训感悟

最近部门安排了一场关于自动化运维体系的系列培训，开篇培训就是监控平台的讲解，听完之后很有感触，在此记录下当晚培训的主要知识点以及自己的理解

正文

自动化运维体系

首先放上整个运维体系架构

架构最底层就是一些硬件基础，在硬件基础之上建立CMDB与WEB_API(对底层做了一次封装，提供一些操控与获取信息的功能)，在此之上建立自动化部署，自动化监控，Docker虚拟化、弹性计算等服务，最顶层为最终的WEB管理平台。

本次培训主要讲解的是自动化监控这部分，自动化监控从服务器、组件、服务、业务、应用、容量等多个维度对项目进行全面的监控，支持多样化策略配置，支持短信和邮件的告警，为项目的未定运行保驾护航。

自动化监控

接下来再附上整个自动化监控的架构

整个自动化监控最底层是那些被监控的对象，这些对象主要包括服务器的CPU以及内存，引擎容量，会话信息，错误等等，在此之上建立了一个模块负责守护与收集数据，并且保存至MySQL、Tair、Redis等数据库；收集完数据之后，必定需要对数据进行处理与分析，因此又在原有的基础上建立了数据分析处理模块。该架构最顶层属于展现与管理层面，主要是负责展示展示进程，容量，以及生成一些报表等功能。

监控数据流

上图是整个自动化监控系统中的数据流向图，数据首先会在各个服务器组件上产生，通过PMI发送给PMC，PMC将信息转发给PMS，再由PMS将数据分类保存在不同的数据库中。Web展示和查询，数据分析报警，组件和业务波动测都会利用这些数据，来呈现最终的监控效果。

各组件介绍

• PMI：在各个服务器上安装的小程序，可以用于与PMC结点的信息交互
• PMC：一个PMC管理多个PMI，它的主要功能是对PMI的管理(守护)，以及对数据流进行处理
• PMS：一个PMS管理多个PMC，PMS还承担存储数据的功能

PMC对服务的守护

 

PMI与PMC之间会建立心跳联系，被监控的组件会定时上报进程和线程信息给PMC，PMC也会定时检测被监控组件的存在。如果心跳联系断开了，那么PMC会远程启动保存在服务器上的脚本，重新启动组件。

服务器报警逻辑

服务器报警逻辑中，HOST会将基础指标传递给PMC，PMC定时上报给PMS，再由PMS保存到MySQL中，在这个流程中，如果PMS长时间没有受到PMC传递的数据，便会回拨PMC，如果PMC回拨成功，说明PMC上传数据超时；如果失败，在PING一次HOST主机，如果成功，说明PMC异常，如果失败，说明HOST异常

组件，业务波测逻辑

在监控过程中，有时需要对被监控对象所需的内部服务或者外部服务进行波测，确保被监控对象的稳定运行，因此该监控平台建立了一套波测流程。首先会由项目管理员对波测进行配置，将配置信息保存至MySQL中，波测服务PPM会查询数据，调用脚本进行波测交互，并且将波测结果存入数据库，再由报警服务PMA取出数据，并对其进行分析，以判断是否报警

数据分类保存数据库

该平台利用了MySQL，Redis，Tair等数据库，其中MySQL数据库中保存服务器的基本信息，一些配置信息等，MySQL数据库中会保存一年内的所有数据；Tair数据库中保存实时组件服务信息，仅会保存一小段时间的信息，主要用于配合服务器信息进行报警

遇到问题与优化

该体系设计之初，在PMI与PMC，以及PMC与PMS之间都是一条数据传输一次请求，造成网络IO性能的瓶颈，最后对其进行优化将原来的单处理切换成批处理，也即先将所需发送的数据缓存起来，到达一定条件后一次性发送。批处理支持两种策略混合

• 设置一个最长时间，到达规定时间将发送数据给下一层
• 设置一个数据最大容量，超过最大容量将发送数据给下一层

由于业务方数据传输的数据多且杂，有很多重复数据，因此在PMI层对数据进行精简，只缓存发送有用的数据