使用 Zabbix 监控 Exchange Server 的数据库

使用 Zabbix 监控 Exchange Server 的数据库

在这篇文章里我想要分享一下 Exchange Server 2016 数据库状态以及数据库使用量的监控方法,经过几次修改和迭代,目前我使用的是 Zabbix 3.2 对数据库进行统一、自动化、动态自配置的监控。

主要解决了哪些问题?

当前主流的监控平台,如 Zabbix、Prometheus,微软自家的 SCOM,还有古董 Cacti 我都已经进行过或多或少的尝试,最终选定 Zabbix 作为 Exchange Server 的统一监控平台,主要原因是它高自由度的配置、分布式部署方式以及丰富的 API 接口,便于针对性的修改和获取数据用于统一展示,图表功能一般但是够用,好在可以通过 API 将数据取出来做二次处理。

在花费了大量时间优化调整监控项、触发器以及告警策略之后,只剩最后一块难啃的石头,也就是今天讨论的数据库状态监控。

Exchange 数据库监控的演变

集团 Exchange 数据库的监控经历了 3 个主要阶段:

  • 最初是根据一个数据库列表文档跑脚本,通过 Test-MAPIConnectivity 检测数据库是否挂载,发送短信来告警。手工维护难免造成遗漏;
  • 在经历了一个由于主备关系问题导致的集群崩溃事故之后,第二阶段的脚本使用 Get-MailboxDatabaseCopyStatus 来侦测数据库状态。另外可以自动的检测新加入的数据库;
  • 但是数据库大小、人数、可用空间、主备关系这些东西没有直观的展示出来,于是进化到第三阶段,Zabbix 统一监控展示。

Zabbix 监控数据库思路

目前所有的邮件服务器均已加入 Zabbix 做基础的硬件信息和服务、性能指标的监控。

使用 Zabbix 发现服务,通过一个 Powershell 脚本( Get-ExchangeDBDiscovery.ps1 )获取到每台服务器中的数据库信息,写入到服务器监控项中;为了减少抓取延迟,服务器本地每分钟会执行另一个 Powershell 脚本(Get-ExchangeDBStatus.ps1),将所需要的数据库信息全部写入到脚本执行目录中的子目录 DBStatus 中;Zabbix 中的服务器,通过执行自定义命令从 CSV 文件中获取字段值,完成数据收集;如果数据库被卸载,则触发一级告警,直接电话通知我。若数据库同步状态异常,则触发二级告警,使用集团内部 IM 软件告诉我。

困难

由于我的目标是做成全自动监控,而且数据库数量实在太多(集团接近 50000 人,分了 300 多个数据库)所以其中比较困难的点在于:

  1. 由于数据库分 Active 和 Passive,会在两台成对的服务器中各生成一个监控项,降低 Zabbix 执行效率,所以必须分开
  2. 由于 Active 和 Passive 会切换,如果监控项也跟着切换,会造成临时性数据获取失败
  3. 主备关系切换同样会导致挂载信息和复制信息的混乱

解决方案

对于第一点和第二点,通过 Get-MailboxDatabaseCopyStatus 中数据库挂载优先级字段 ActivationPreference 将主备关系固定,去掉优先级是 2 的数据库。

对于第三点,使用了一个过滤方法 Get-MailboxDatabaseCopyStatus | Where {$_.status -like "*ount*"} ,ount 是 Active 的数据库可能的四种状态:MountedDismountedMountingDismounting

源码使用方法

源码我已经放在了 GitHub,使用方法:

  1. Get-ExchangeDBStatus.ps1 加入计划任务,每分钟执行一次
  2. 修改 Exchange 服务器的 Zabbix Agent 服务配置,可以参考 zabbix_agentd.conf
  3. Zabbix 中导入模版 ZabbixTemplate_Exchange Server 2016 Database Monitor.xml
  4. 将源码中的另外两个脚本 Get-ExchangeDBDiscovery.ps1Get-ExchangeDB.ps1 放到与 zabbix_agentd.conf 同级或自定义目录中(放置在自定义目录需要修改 zabbix_agentd.conf 中的脚本路径)

如果是较大型的企业或数据库服务器较多,推荐将三个 powershell 脚本置于 UNC 路径中,Zabbix 是支持的,这样便于部署配置。

后记

其实在早期曾经尝试过在一台机器上进行所有数据库的收集,这样会让整个方案建立起来快速和方便得多,只需要执行一次脚本,也不需要那么多的判断。但是对于 50 个以上数据库规模的架构,这个方法不适用了,一方面脚本执行效率堪忧,完整执行一次可能要 5 分钟以上,这对于我们 99.995% 的 SLA 要求显然是不能够满足需求的;其次 Zabbix 对于单个主机的监控项收集效率也不够,实测起来可能会产生最多 15 分钟的延迟告警,这样是无法接受的。

如果是小型公司,数据库数量使用单一脚本做全部数据库收集显然是没问题的

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×