基于Python 与OEMCC 的数据库移动集中监控的实现

李 琦

（中国邮政集团公司湖南省信息技术局，长沙 410007）

随着邮政信息化建设的逐步深入，应用系统的集约化不断提高，系统大集中是大势所趋，地市中心机房的数据库和服务器数量日趋减少，而我省中心机房的数据库和集群服务器数量越来越多，如何对大集中后的应用系统进行有效的运维已成为企业信息化发展的一个重大课题。面对日益庞大的数据库和服务器的维护工作，我省中心机房运维人员基本还是采用传统的手工巡检方式进行设备和系统巡查，需要人工或脚本进行单机独立巡检与分析，每天需要手工处理很多重复性工作，运维工作中的数据记录分散，预警信息获取不及时，导致运维人员工作量大，工作效率低，并且无法实时和直观的监控到集群服务器的运行状况，也使得系统运行风险大增。

由于我省中心机房目前对众多的应用系统和数据库的运维主要是采用竖井式的应用运维模式，往往是1-2名系统工程师熟悉某一专业的系统，碰到故障形成只有那一两名工程师能解决问题或者临时找不到人而其他人则有力无处使的情况，由于大量的系统是7*24小时运行方式，有些重要系统的安全运行指标非常高，宕机恢复时间超过20分钟即属于重大事故，硬件故障，我们可以采用冗余和双机热备这样的机制保障，但是对于数据库以及性能下降这样造成的软宕机故障，对数据库运行性能的参数进行动态监控并及时预警，就成为机房数据库运维工作的必须。要实现这个目标，首先需要解决两个问题：（1）是一是如何单点集中监控数据库。（2）是如何在移动端接受监控信息。

得益于移动互联网应用技术在邮政行业内的快速发展，微信已发展成为我省邮政企业众多业务领域的最受欢迎的移动应用工具。目前我省微信客户群已经拥有超过300万个活跃用户，微信因信任度高、传播快，可以随时互动，我省邮政企业员工很多日常通知，正逐渐由短信向微信转变。所以我们的课题就选择采用了微信这一渠道，以微信企业号接受监控信息的方式实现向系统管理员和相关运维人员发送预警信息。

经过我们多次全面深入的调研与尝试，确立了以OEMCC（Oracle Enterprise Manager Cloud Control）实现数据库集中监控。通过在一台机器上部署OEMCC 的OMS（Oracle Management Server）端，在需要监控的各数据库服务器上部署OMA（Oracle Management Agent）端。通过OMA 将各实例的信息注册至OMS，实现OMS 端捕获各实例的告警信息、操作系统信息、硬件资源及性能信息等。通过CCC（Cloud Control Console）端即可将OMS 上捕获到的信息展示在WEB 页面上并实现管理。通过Python 爬虫脚本及微信企业号信息推送脚本即可实现在手机端自动接受监控信息。具体架构如图1。

具体实现上，分别在对应的数据库服务器上通过部署OEMCC 12C 的OMS、OMA、CCC 端，实现单点对多数据库的监控；同时编写Python 爬虫脚本及微信企业号信息推送脚本，将CCC 端上的告警信息爬取下来推送至微信企业号。考虑监控服务器的高可靠性，我们部署了OEMCC 集群，包括OMR 的集群和OMS 的集群，其中OMR 的集群就是对应Oracle 12.1.0.2 RAC；OMS 的集群配置Active-Active 模式，并配合SLB 实现负载均衡。

图1 逻辑架构图

同时，为了对各数据库的备份进行统一管理，构建了机房集中的数据湖，将各系统的备份统一部署脚本，RMAN 备份脚本集中部署。实现办法是在OMS 机器上安装不同版本的Oracle 形成一个单机catalog 库群，实现了单机部署RMAN 脚本集中管理不同版本的Oracle 数据库备份。

为了实时监控RMAN 的备份情况，我们编写了sh 脚本，分析RMAN 备份产生的日志，实时查看受监控各系统的数据库备份的执行情况，汇总当前应备份的数据库实例个数，已完成数据库实例数，备份失败的数据库实例个数，记录每个备份任务的实际时长，备份记录的大小，用以后续分析数据库的运行效率和系统健壮程度。当备份异常时通过Python 脚本将异常信息推送至微信企业号相关技术人员，以便及时处理。

对于经常晚间定时处理的跑批服务，也通过将跑批程序日志表集中监控进行了动态及时监控。我们编写了Python 脚本实时监控各应用系统跑批程序日志表并部署在OMS 机器上，当有跑批程序日志出现异常记录时，将表中异常记录信息实时推送至微信企业号相关技术人员。

图2 手机端实时收到报警信息

在运维技术人员的手机端收到的报警信息如图2所示：如图2所示，两台受监控主机上根目录文件系统可用空间分别只有5.83%和，10.57%了，低于预设的告警区间，所以系统自动报警，需要相关技术人员及时处理。

相对于生产网来说，办公网虽然安全级别不是最高，但是也不能直接与互联网（外网）直连，暴露在互联网下，所以根据机房实际情况，我们按下图3模式构建了机房的DMZ 区（DMZ 通常是驻留于专用网络和公共网络之间的一个子网，从公共网络的连接到DMZ 设备终止，这些服务器也经常被相对安全的专用网络设备访问。），使用一个有3个接口的防火墙去创建隔离区，每个隔离区成为这个防火墙接口的一员。防火墙提供区与区之间的隔离。这种机制提供了许多关于DMZ 安全的控制。用以隔离办公网与互联网，对访问进行控制，我们将部分用于提供对外服务的服务器主机划分到一个特定的子网—DMZ 内，在DMZ 的主机能与同处DMZ 内的主机和外部网络的主机通信，而同办公网内的主机通信会被受到限制。这使DMZ 的主机能被办公网网络和外部网络所访问，而办公网网络又能避免外部网络所得知。

图3 防火墙隔离DMZ区和办公网

DMZ 区的隔离策略如下：

（1）办公网（内网）可以访问互联网（外网）。办公网（内网）的用户访问外网时，防火墙会对源地址进行转换。

（2）办公网可以访问DMZ 区。方便工作人员从办公网使用和管理DMZ 区的服务器。

（3）互联网不能访问办公网。有助于对办公网的资源进行保护。

（4）互联网可以访问DMZ 区。某些需要从互联网登陆的服务，就可以专门部署在DMZ 区。这样可以集中网络安全设施和设备对DMZ 区加强保护。

（5）DMZ 区不能访问办公网。为了有效隔离外网直接访问办公网。当有入侵者攻陷DMZ 区时，这样可以阻止入侵者进一步攻入办公网。

（6）DMZ 区不能访问互联网。通过这样设计和部署的一整套方案，现在我们省中心机房实现了：多系统数据库的移动集中监控、RMAN 备份集中管理、应用系统跑批程序日志表集中监控。目前主要管理的目标包括2套ASM、2套RAC 集群、12个Oracle 数据库实例、一个MySQL 库、12台服务器，共计29个监控目标。在2018年的运行中，共计成功发送报警信息84条，应急处理信息4条，有效的支持了我省中心机房全年无故障运行。同时，这套方案的实施，极大的减少了机房运维人员工作量，也使得我们数据库的DBA 能参与到更多的数据库管理或软件开发任务中去，既减少了运维成本投入，又提高了软件开发效率。未来机房运维，其中最重要和关键的就是应用系统和数据库的运维，所以，该方案的成功实施最重要的意义是，为我们后续继续深入探索机房的远程智能云监控模式打下了良好的基础。