Icinga 简单了解

为什么要了解Icinga

近段时间，由于公司服务出现过几次小故障，导致所有用户短暂不能访问，后来开会复盘事故时，领导提出要对主要服务、网络、硬件设施等进行监控，以保证出故障时能第一时间知悉并采取针对性的措施，而不是各方盲目排查定位原因。于是，运维的同事根据对公司其他服务的监控经验，向我们介绍了 Icinga 这套监控系统。

能监控什么

为了有个直观的认识，下面先直接上图。

image

image

从效果图可以大致看出来，通过 Icinga 我们可以得到服务器主机、服务等监控信息，如果有异常，会有特殊事件显示详细的信息，并可以添加备注、发送提醒、手工重新检查等操作。

是怎么实现的

作为程序员，看到一个新系统，肯定会去想它是怎么实现的。非常幸运的是， Icinga 是一个开源系统，我们可以自由查看它的实现方式。为了学习它，我 ssh 连上测试环境，查看了一下这个项目的部署目录，主要看它的配置文件都有什么东西，数据是保存在哪的，还有启动命令执行时带了哪些命令参数 。

通过 locate icinga 命令，我找到了这个目录 “/etc/icinga2”，cd 进去后，在该目录及其子目录下看到了一堆 ".conf" 后缀的配置文件，有 init.conf, icinga2.conf, hosts.conf, services.conf, … 等等。其实如果对开源项目看得比较多，或者是开发经验比较丰富的话，基本上从配置文件的名称就能猜到文件里的内容是哪方面的了，这时候我们就需要对自己感兴趣的配置文件一探究竟了。不得不佩服做开源软件的大神们，各种配置项都有较详细的文字说明，让我们大概清楚这个配置项有什么作用。由于配置文件比较多，而且配置文件之间是有依赖关系的，当我看到某些配置项引用的变量在当前文件找不到的时候，我便用 grep 命令搜索多个配置文件，找到它出现的原始位置，然后再看它的注释说明，这样便能把配置串联起来了。遇到一些不明白的关键字，当然是要请 Google 大神出马了，还有就是官方的文档说明，各种方法配合着来，总能有收获的。

在看配置文件时，我发现有些服务配置是引用了内置的服务，或者是引入了外置的插件实现。原来 Icinga 是兼容另一个监控系统 nagios 的大部分插件的，网上说 Icinga 的作者原来就是 nagios 项目的开发人员，因此，站在成熟的项目肩膀上，Icinga 得以快速发展壮大。

而要实现自己的自定义监控服务，我们可以通过配置 services.conf，调用内置的功能或像示例一样引入丰富的插件。而像我们对应用内的业务监控，则可能需要在应用内提供接口，把监控逻辑写在业务接口里，再在 Icinga 系统里配置服务请求接口。

更多功能

除了看到的监控告警数据，从公司部署的测试环境上，我们还可以看到一些配置管理、权限控制的菜单。出于好奇，自然要去看看这些菜单都提供了什么功能。可以看到，Icinga web 2 项目具备了一个后台管理系统应用的基础功能，如角色管理、权限管理、用户管理等，还可以配置数据源，启用或禁用某些模块，配置服务监控的主动、被动方式和监控间隔，告警方式等等。

怎么嵌入已有的管理后台

我们现在看到的是 Icinga web 2 项目的效果图，那如果要把这些功能集成到已有的管理后台上做展示该怎么办呢？一个方法是用 iframe 在管理后台的页面上嵌入 Icinga web 2 的页面，这样做的好处是页面是现成的，只需要简单集成，缺点是两套页面风格不能保持统一体验，权限不好管理。另一个方案是直接调用 Icinga 的接口获取数据。Icinga 提供了 RESTful 的API，只需要后端程序用一个固定的身份账号去取数据，封装一层后可以增加权限控制、自定义提醒等逻辑，实现比较灵活，页面也可以用已有的组件和风格，完美集成。当然，缺点也比较明显，要封装调用API，并重新开发页面。

总结

以上就是我今天花了一个多小时了解了 Icinga 系统后所想到的，在接下来的项目应用中，我应该更多是关注它提供的 RESTful API，结合我们项目和公司的实际情况去搭建一套实用的监控系统。Bug 是不可避免的，那就让我们在 bug 出现时就知道它的存在，迅速解决它吧。