zabbix监控kafka模板_关于CMDB与Zabbix的一些实践与思考

作者: Eric
公众号: 有田菜也香

背景

      今年，随着全国首个“微服务+分布式”架构的新一代分布式银行核心系统在笔者的公司正式落地投产，银行系统的大脑正式“换芯”了。同时，随着业务的快速发展以及新IT技术的不断引入，应用系统的IT资源规模是越来越大，IT架构的复杂性也与日俱增。在这种背景下，作为一名应用系统维护工程师，我们也深刻感觉到工作方式和内容正在悄然发生改变，下面笔者就分享一下平时日常工作的一些心得体会。

CMDB平台的演进

         CMDB 是 Configuration Management Database(配置管理数据库)的简称，CMDB 存储与管理企业 IT 架构中设备的各种配置信息，它与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。
      笔者认为， 一个有序的IT组织，必然需要一个统一的资产管理平台，所有的系统，都以CMDB为核心。那么我们对CMDB的定位是怎么样呢？首先，CMDB是一个资产管理系统，它需要采集所有设备的资产信息，其次，它需要周而复始的更新数据信息，手动操作，难免遗漏，CMDB是一个组织的人员协作和IT资产流转，生命周期的管理。从设备的上下架到维保，整个生命周期都需要在CMDB里面体现出来。
        CMDB有哪些解决方案呢？开源的有itdb，itop，cmdbuild，ralph等等。当你用了开源的CMDB后，恐怕不想再用了，原因在于开源的CMDB页面不友好，定制化差，同时，IT资源资产清单的不断增删改，导致维护CMDB是个不讨人喜欢的活，所以一个成熟的、可定制化的商用CMDB平台成为我们的迫切需求的产品。

CMDB的介绍

    EasyOps所提供的CMDB平台是一种敏捷、灵活、可充分自定义的CMDB平台。根据我们所属金融业的特点和自身IT系统管理的需求来自定义CMDB平台上所需要管理的资源对象和对象内的属性，如下图所示：

        从图中可以看出，自顶向下，共有五个层级，用户-应用系统-应用模块-集群-主机，这一条应用系统的关系链，解决我们系统运维人员在一直最关心的几个问题，这个主机是哪个系统哪个模块的？这个系统开发运维负责人是谁等一些老难问题，在这一条链上的每一个模型节点，存在基本属性和关系两个属性。同时在每个模型，也有一个内在的关联关系，应用系统中父系统和子系统的关系，应用模块中上游应用和下游应用的关系。

CMDB的维护

     CMDB的模型建设好，怎么去维护CMDB呢？在从事过一段时间CMDB管理员的工作后，深深感觉到CMDB的维护是个“体力活”，也是一个“技术活”，在主机-集群应用模块-应用系统-用户这一条链中，对于每个节点，我们的维护方法，尽量自动化，流程化，EasyOps平台提供了全功能的API接口，各种外部系统通过通过标准的Restful API与平台的CMDB进行交互，实现动态、高效的配置信息的读、写交互。

• 用户的维护

        对于用户的维护，我们通过API定时与ITSM系统同步全量的用户信息。

• 应用系统的维护

        对于应用系统模型的维护，我们也通过API获取科技管理平台全量系统清单以及与应用系统负责人信息，再通过Easyops的api全量更新到应用系统模型，从而实现应用系统模型和应用系统-用户关系链的自动创建，自动维护。

• 主机的维护

用户通过部署一个开源的agent程序即可实现通用的服务器基础信息的自动发现、自动采集、自动上报。对于其中的一些特殊业务配置，还可以可以通过人工编写 agent的采集插件来实现信息的自动维护，agent采集的信息如下：

• 主机-集群-应用模块-应用系统的维护

       对于这条链路的维护，是整个CMDB维护中最核心也是最为艰难的地方，也是我们CMDB维护的一个痛点。由此我们想到的一个方法是想通过流程驱动CMDB的方式去建立此条链路。首先，我们将IT资源申请统一入口做成“轻流程”，申请人可在“轻流程”平台上通过excel表单填写主机-集群-应用模块-应用系统等信息，然后我们再通过调用系统工具在CMDB建立起单个模型的信息以及模型之间的关系信息。

    至此，用户-应用系统-应用模块-集群-主机，整个CMDB链的信息我们就脚本化、流程化的方式建立维护起来。CMDB管理员也解放了劳动力。

应用监控的发展与变化

     在我们以前使用监控系统是一种插件式的监控系统——Nagios，可以监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机参数以及服务，同时提供异常告警通知功能等。近年来，随着其他开源监控软件的崛起，Nagios逐渐淡出了历史舞台，使用的人群相对减少。

      在新核心系统密锣紧鼓地进行开发测试演练的同时，我们也意识到，随着新核心系统以及其配置系统的上线，乃至以后旧业务系统的改造和新业务系统的上线，将带来IT资源的快速增加 ，如果继续使用nagios来做应用组件的监控、配置、运营，无疑监控的工作将成为系统维护人员的一个“体力活”。因此，我们考虑使用一个新的监控工具。首先分析我们的需求，对于监控点，我们关注的监控点有应用进程[process]的存活、应用端口[port]的存活、业务探测[telnet]的存活、BS架构系统[url_check]的页面探测、各种中间件的参数，对于维护方式，我们希望在一台主机上配置一个声明监控项的文件，剩下的工作交给自动化去做。

        基于我们的需求，我们开始对监控工具选型，当时运维条线内使用的另外一个工具是Zabbix，这是定位于企业级的分布式监控系统，是一个开箱即用的成熟解决方案，具备完备的功能。它的一大特性，自动发现(network discovery & low level discovery)堪称监控的运维利器。配置一个发现规则，即可将所有的机器纳入监控。这种自动化的能力，恰恰就是我们所需要的。最终，我们内部运维人员自主编写一个框架级别的工具，接管应用的监控生命周期。这个框架在我们内部称为zbx_app。关于这个框架工具的原理与介绍在我们公众号前面发布的，作者为AcidGo的一篇文章《银行Zabbix监控架构分享》中的应用监控一章节有详细的介绍。

Zabbix的配置与运营

      对于应用组件的监控配置，我们只需要在特定目录下根据预设的语法编写一个如下的声明文件lps.cfg即可。

• 基础监控(包括进程端口、业务探测、页面探测、日志关键词)

#进程端口
[process_port]
应用用户|模块简称|进程名字
应用用户|模块简称|进程名字|端口
应用用户|模块简称|进程名字|端口|预设连接数
#业务探测
[telnet]
备注|对端IP|对端端口
备注|对端IP||预设连接数
#页面探测
[ur_check]
备注|请求类型|url
备注|请求类型|url|请求报文|返回报文
#日志关键词
[log]
日志全路径|特征码|预设值
日志目录|特征码|预设值

• 中间件组件(9大主流中间件，Redis、Tomcat、welogic、Kafka、Zookeeper、Apache、Nginx、IBM MQ、Rabbit MQ)

#Redis中间件
[redis]
IP:Port|密码｜密码的文件(全路径)
[redis_cluster]
IP:Port|密码｜密码的文件(全路径)
[redis_sentinel]
IP:Port|
#Zookeeper中间件
[zk]
zk=ip:port
#Apache中间件
[apache]
process|port
#Nginx中间件
[nginx]
process|port
#Tomcat中间件
[tomcat]
ProtocolHanler
#Weblogic中间件
[weblogic]
#Kafka中间件
[kafka]
#IBM MQ中间件
[ibm_mq]
#Rabbit MQ中间件
[rabbit_mq]

• Zabbix前端页面的配置的监控模板如下

CMDB与Zabbix的联动

        对于CMDB，我们通过脚本同步其它系统来完自身的模型数据、用“轻流程”来驱动CMDB的建立。对于业务系统的应用监控，我们仅仅维护一个lps.cfg就可以达到整个应用监控的闭环纳管。那么如何联动CMDB和Zabbix两大运维利器来达到一些标准化、可视化的场景呢？
      Zabbix的每一台主机有一个类似key/value形式的标签，由此我们想到的方法是通过丰富这个标签来将CMDB与Zabbix联动起来，从每一台主机出来，在CMDB查询得到主机-集群-应用模块-应用系统-运维小组的链路关系，再用Zabbix提供了一个host.update的API方法，更新同步到Zabbix，同步之后，效果如下：
       当每个告警都有一些立体化的CMDB信息后，我们就可以结合开源可视化工具Grafana消费这些信息来做一些可视化的展示，如每个运维小组存量的告警趋势图。

    后期可以持续实现的可视化场景有：各业务系统告警趋势图、BS架构系统WEB响应情况展示等等。

总结

CMDB平台、Zabbix监控系统是运维的两大利器，日常很多工作内容跟两者息息相关，两者的关系密切，在CMDB建立初期，监控系统为CMDB提供CI信息，当CMDB正常运营后，反过来为Zabbix监控系统提供必要的支撑数据，来收敛、立体化、标准化告警信息。随着银行核心系统的“换芯”革命，对应用系统维护工程师的工作能力也随之发生改变， 希望能在以后的工作中能够不忘初心，砥砺前行。