随着业务的飞速发展，数据库服务器量级飞速增长，比如Oracle、MySQL、Redis、MongoDB的使用更加普及，对数据库运维人员的要求也越来越高，构建一个真正好用的监控系统是一项艰巨的任务。在监控系统的开源软件中，可供选择的工具众多，然而真正适合自己需求、能够真正解决自己数据库问题的监控系统软件却凤毛麟角。

Zabbix和Ansible分别是两款非常流行的开源监控和自动化工具。具有上手简单，学习曲线平滑、配置简单、功能强大、扩展性强等优点。

本次将分享如何使用Zabbix并结合Ansible打造自动化数据库监控体系。

Zabbix是企业级监控解决方案，和自动化相关的核心功能包括：LLD、API、Zabbix_trapper。

在数据库监控中监控的对象往往是变化的，以部署Redis来说：近几年硬件发展迅速，在企业中新购的X86服务器配置基本都在32C、256GB以上，大家都知道Redis是用“单线程-多路复用IO模型”来实现高性能的内存数据服务，只能用到一个CPU核心，内存配置一般也在8G-16G左右，为了提高资源利用率，一般会选择在一台服务器上部署多个实例。当需要监控的内容比较多的时候，此时每次添加一批实例都去手动部署监控、配置告警的话就会造成大量人力的消耗。

此时通过LLD能自动发现并自动发现添加新部署实例的监控项，包括Item、Trigger这些的自动添加，做到一次部署永久受益，提高数据库监控人员的幸福值。

LLD的核心思路是给服务端发送一个JSON的数据格式，下面以Redis Standalone类型实例为例说明。

• 首先模板中添加discovey rules增加一个trapper类型：

• 然后增加宏{#REDISPORT}：

• 当关联好Redis的模板后，使用zabbix_sender发送给如下的数据：

就完成了Redis的监控添加，其中一项Item示例如下：

API是Zabbix中非常强大的功能，通过调用API可以将Zabbix和其他系统串联到一起，在自动化运维环境中非常有用。

Zabbix API是一个JSON-RPC的API，通过http请求，它提供了几乎所有Zabbix的功能，比如更新Item、添加Host监控等。

API使用流程如下：

官方也提供了详细的API功能说明。

官方API：

https://www.zabbix.com/documentation/3.2/manual/api

下面通过调用user.login的例子来说明:

• JSON RPC：标准的JSON RPC参数以标示协议版本。所有的请求都会保持不变。

• Method：定义了需要执行的方法。

• Params：这里通过传递JSON对象来作为特定方法的参数。

• ID：用于绑定JSON请求和响应。响应会跟请求有相同的ID。

• Auth："0424bd59b807674191e7d77572075f33"，这是一个认证令牌用以鉴别用户、访问API。

在Python项目上一般可以使用第三方的py-Zabbix或者自己封装（urllib、requests）来实现访问。

其中py-Zabbix的网址如下：

https://github.com/adubkov/py-zabbix

使用示例如下：

Zabbix_trapper是不通过zabbix-client收集数据，直接主动向Zabbix Server发送数据的一种方式。

我们监控数据库，如果使用Agent的方式发送，要用到agent conf文件中的userParameter，这样需要接受一个参数，来返回对应的监控数据，这样等于有多少个Item就要在一次监控周期内执行多少次命令，并且对数据库说也是要建立相应次的短链接，增加了数据库的负担。

此外，在监控的数据库实例比较多的情况下，也将给Zabbix Server带来较大的压力，可以通过使用trapper的方式，一次搜集所有的监控数据到一个JSON中，并且只给Zabbix Server发送一次。

使用方式如下：

• 直接调用：

• 使用py-Zabbix：

监控运维自动化的目的在于解放、简化、方便运维人员的工作，提高效率，减少人为故障，思路是能自动坚决不手动，将高频率低风险的监控操作全部自动。自动化的基础是基础信息的准确性和各种配置信息规则的规范化。

约定服务器主机名规范：见到这个主机名就能知道这个设备是部署了什么样的服务，以及是什么业务来使用的。

约定服务器网卡IP规范：比如一台服务器可能有多个IP：应用IP、数据IP等，监控要用哪个IP以及哪块网卡绑定IP，需要统一。

约定服务部署规范：统一所有被监控服务器的Zabbix Agent部署目录，监控脚本部署目录。还有包括数据库的标准化比如，如Oracle、MySQL、Redis这些常见服务的应用初始化流程、部署更新流程等。

报警等级的规范：用于区分报警发给谁、怎么发、如何做报警升级等，还可以根据等级和监控项进行自动处理，等级较高的优先处理，较低的可以集中处理等。

等这些标准规范固化下来之后，消除了各种差异，才能为后续的自动化开发铺平前进的道路。因为连标准都没有的话，那就毫无自动化构建可言。

我们自己的项目后端开发语言为Python，Ansible基于Python开发，能够很好的支持Python项目进行二次开发发布。在不需要考虑大规模并发性能的情况下，Ansible是最合适的自动化工具，只需要一台能够SSH到其他服务器的管理机。

上图为Ansible的基础架构图，由以下部分组成：

• Ansible：核心；

• Core Modules：Ansible自带的核心模块；

• Custom Modules：自定义模块；

• Plugins：Ansible插件，包括邮件插件、日志插件、连接插件等；

• Playbooks：剧本，Ansible配置、部署、编排语言，定义主机执行的Task集合；

• Host Inventory：Ansible管理远程主机和组之间的关系清单，记录主机SSH端口、账号密码等。

如上图所示，只需要在Ansible Server上执行:

就可完成所有工作。（如果是自动化项目，可以通过封装Ansible API来实现）

这里的main.yml如下：

其中host_list指传入被监控服务器的信息；role_name指传入自定义的Zabbix监控角色。

这里需要注意的是通过Auto Register关联模板，当添加主机、加入主机组后，关联到相应的模板，才能使整个流程形成闭环。

那么如何做呢？

例如我们上面的Ansible命令，会同时添加zabbix_agentd.conf这个agent的配置文件，其中有一个参数是HostMetadata=MySQL。

Zabbix Server会提前为Discovery创建Action：

这样就完成了对MySQL模板的管理，从而形成闭环。

下面介绍如何根据Oracle、MySQL、Redis、Mongo以及自己的需求情况使用Python开发一套DBA_Monitor项目，使监控更加全面、丰富、灵活，使交付更加快速、稳定、高效。

项目目录结构如下：

其中authzabbix.py封装了共用的Zabbix API的方法，Lib目录主要存放全局的变量信息，包括Zabbix API地址、Zabbix用户、各类数据库的监控用户、路径等信息，Log目录用于存放监控日志，Template用来存放Zabbix模板信息。

pyora.py是Oracle的监控脚本，mysql_db_status.py是MySQL的监控脚本，redis_db_status.py是Redis的监控脚本，mongo_db_status.py是Mongo的监控脚本。

Ansible把DBA_Monitor包推送到被监控机后，会根据不同的数据库服务类型来启动对应的监控脚本。如果再有新的数据库类型需要监控，也可以方便的进行扩展。

下面将对Oracle、MySQL、Redis、MongoDB监控的关键点进行讲解。

Oracle监控使用了Pyora这套脚本，Pyora大量使用了Python反射（自省），从而实现了非常灵活的Oracle监控，自定义自己想监控的指标相当方便，只需要添加相关函数就能获得相应的Item值。

Pyora通过组件cx_Oracle来连接Oracle数据库，获取到的数据传递给Zabbix的Agent，从而获取到相关监控数据。

Pyora的网址：

https://github.com/bicofino/Pyora

下面对Pyora中的关键代码进行注释说明：

如果我们想要添加新的监控user_status，只需在Checks增加相应的方法：

非常灵活。

MySQL的监控主要使用MySQLdb这个包，通过show global variables、show global status、show slave status管理命令获取，然后进行计算，存在一个Python的dict数据结构中，key为监控项，value为取到的值。

因为新版本的MySQL对硬件的利用率很高，这里没有使用多实例监控，所以没有过多难点。在MySQL模板里定义item为trapper类型，通过zabbix_sender将dict中的数据发送给zabbix_server就完成了。

下图是对trapper类型MySQL监控的模板配置示例：

Redis实例的监控是使用Python-Redis通过info命令来获取信息，并对信息进行处理来完成。Redis Standalone和Cluster都可以在一次LLD添加item后通过info命令收集数据来监控，而Seninel稍微特殊，下面主要说明Seninel的监控技巧。

首先要用LLD发现Seninel的实例，这个和Standalone类似，上图中的Sentinel discover，就是第一次LLD。在前面的LLD章节已有说明，这里主要说明是如何发现Seninel中监控的Master实例信息，即上图中的Sentinel master。

在发现了Seninel的实例后，通过info sentinel命令可以抓取如下类似的关键信息：

这些信息通过再次LLD来添加到Zabbix Server的item中，用来监控Seninel中存储的被监控Master的状态，并且如果有新加入的Master也能自动LLD发现，也就是两次LLD监控Seninel中的被监控Master的状态信息。

需要注意的是其中这里的Seninel master需要同时接收到{#REDISPORT}和{#SENTINELMASTER}两个宏信息。

包括item也要设置{#REDISPORT}和{#SENTINELMASTER}两个宏信息：

线上环境基本都会选择MongoDB Sharded cluster架构，MongoDB Sharded cluster共有三种不同类型的服务：Mongos、Mongod、Config Server。

在MongoDB的监控中，为了满足自动化的需求，最好是在一个脚本中里同时完成：

发现实例（LLD）

判断出实例类型，在Zabbix添加对应的监控，是Mongos就添加Mongos模板，是Mongod和Config Server都是添加Mongo模板。

发送数据

判断实例类型，收集相应数据并发送给Zabbix Server，这里监控Mongo使用的是PyMongo包，通过Mongo中的管理命令serverStatus、replSetGetStatus（mongos无此命令，需要过滤）来获取信息，并进行处理。代码片段如下：

这里通过serverStatus中的process是否为Mongod来区分实例类型：

发现实例的代码如下，通过netstat查询出这台主机上所有的不同的Mongo实例，实例的信息，放入一个List里面返回：

run函数用来组装数据，并通过zabbix_sender来发送LLD信息，完成实例的添加：

最终通过LLD发现的Mongod和Mongos监控Item示例如下：

Zabbix结合Ansible一键部署监控，做到了安装Zabbix Agent，修改Agent配置文件、Agent加入开机启动、启动Zabbix Agent、添加客户端Host、添加Host的模板等一系列动作，并且可以和CMDB结合，进行自动部署，简化了数据库监控操作步奏，提高数据库监控人员的工作效率。