设备监控平台设备监控软件( 四 ) _设备

【设备监控平台设备监控软件】刚才提到了组的概念，我们在实际应用中，一个监控对象属于两个组，即一个 P 组(平台组)和一个 S 组(业务组) 。
IT 运维人员的视角和业务人员的视角存在差异性，通常一个组织内会雇佣不同角色的 IT 专业人员，比如 Windows 管理员，Linux 管理员，DBA 等。
DBA 会负责所有数据库相关的运维工作，而且不在乎这个数据库属于那个应用系统。
因此所有的数据库服务器，比如所有的 MySQL，都会放到一个叫做 P-DB-MySQL 的组中。
这个组所有的告警会发送给指定的 DBA 而不是 Windows 管理员，同时会和对应的 MySQL 监控模版进行关联。
这样做的收益在于 DBA 只会收到他们所负责系统的告警，同时监控也实现了标准化。
而业务人员关注的是整体业务应用是否正常运行。比如一个登陆系统，它可能有前端的 Tomcat 中间件，还有一台 MySQL 存放着用户登录信息，底层跑着一台 HP 的服务器。
那么我们会把这三个监控对象放在一个叫做 S-Department1-Login 的组中。
这样做的好处在于，一旦一个监控对象出现任何问题，我们可以第一时间知道它影响什么系统。
通过 P 组和 S 组的结合，我们可以在监控告警不被遗漏的同时，最大限度降低监控噪音，同时也能直观知晓当前的问题会对那些业务造成影响。
告警方式
Zabbix 支持非常多的告警方式，这点类似于 Prometheus 的 AlertManager 。
首先我们会对报警进行分级，Zabbix 原生提供了 5 种级别的告警，即 Disaster，High，Warning，Average 和 Info 。
我们使用了其中的三种，并给出了这三种级别告警的定义：

Disaster：触发后需要立即处理，如不处理会直接影响生产系统的告警。
Warning：触发后需要尽快处理，短期不处理不会直接影响生产系统。
Info：提示性的告警。

不同级别的报警会对应不同的策略，比如 Disaster 告警会发送给 IT 负责人和系统管理员;Warning 告警只会发送给系统管理员;Info 不会发送告警，但会在监控大屏上展现。
具体的告警分级和策略可以根据企业内部的实际情况和监控需求进行定制。
对于告警的呈现方式，主要有邮件、短信和监控大屏等几种，多渠道的告警确保了我们的告警不会被遗漏。
同时我们也会对报警内容进行精细化的定制，包含报警状态(Problem 或者OK)、具体的问题、出现问题的服务器和 IP、问题具体的值等信息。
此外，我们还会在内容中补充该告警对应系统负责人姓名和联系方式，方便我们 7×24 小时的 NOC 第一时间联系到相应运维人员处理故障，降低故障时间。
在我们的监控大屏上，也会展现出当前每个系统状态，并显示出具体的问题有哪些，用红色标示出 Disaster 级别报警，Warning 级别的则是黄色。
持续集成/持续交付
在前面的分享中提到了 Zabbix 提供了 API 。基于 Zabbix 的 API，我们将其融入到了 DevOps 的持续交付流水线。
当持续集成平台 Jenkins 从版本控制系统 Git 上拉去代码进行构建后，通过 Ansible 等配置管理工具进行应用发布的同时，会调用 Zabbix API 将对应的主机放入维护模式，从而避免应用发布时的监控噪音。
同时 Zabbix 也会通过基础信息的收集，为 CMDB 配置管理数据库提供数据。当告警的时候调用微信、邮件等平台的接口进行告警触发。通过和其他平台的集成，形成完整的持续交付闭环。
自动化带外管理
当物理服务器数量大幅上升后，硬件巡检问题是最烧脑的难题。硬件故障存在着随机性。