海量运维监控系统规划与部署（基于Linux+Nagios+Centreon+NagVis等）
随着互联网大潮的迅猛来袭，以及对于传统行业的不断渗透，国内企业的信息化发展也取得了前所未有的成就，无论是部署规模还是运维规模都变得庞大起来。伴随而来的企业信息化需求逐步迈向多元化、层次化、异构化，使得IT基础框架和上层应用日益复杂。对于从事企业IT运维工作的管理人员和技术人员来讲，为了提升信息服务质量、确保信息安全，如何及时获得信息系统告警信息、迅速定位故障原因、快速高效地处理各类IT问题、降低故障率和故障响应时间等等，就成了亟待解决的问题和难点。目前，很多企业的核心业务都已经完全信息化。为了确保业务稳定可靠、快速有效地开展，企业经常会运用多个信息系统进行消息传递和系统交互，从而加大了故障定位的时间和问题解决的难度。面对服务器宕机或者业务中断，每一位负责任的IT运维管理人员在面对用户的投诉、领导的问责、同事们的紧张时，无不在殚精竭虑地思考如何能够快速准确地定位系统故障，及时采取有效手段使故障能够快速解决，业务能够及时恢复。如此一来，研发并部署一套适合企业自身特点的，能够统一管理和展现各种监控资源，实现集中告警，全面协助IT运维管理人员实时掌握系统整体运行状态，快速定位故障，缩短处理时间的企业级海量IT运维监控系统就显得迫在眉睫了。
1.1 什么是IT运维监控系统
既然IT运维监控系统这么重要，那么究竟什么才是IT运维监控系统呢？
所谓IT运维监控系统，有如下两层含义—“监”指的是对其他服务器的检测、监视；“控”指的是对其他服务器的控制，掌控。IT运维监控系统往往是一套独立的信息系统、或者是若干信息系统的集合，用以对其他信息系统进行问题检测，甚至能够实现对其他信息系统进行部分或者完全的远程控制。
例如，就服务器检测而言，监控系统能够周期性地连接到一个HTTP服务器上，检测其是否能够正常响应浏览器的请求。又例如，监控系统能够接收系统管理人员的指令，在被监控的服务器上执行一个脚本，完成某项控制类操作等等。
如果实施得当的话，一套好的IT运维监控系统可以成为各类信息技术人员最好的朋友。它能在信息系统出现灾难之前就提前告知系统管理员某些细微的故障症候，使管理人员能够未雨绸缪，及早采取措施避免系统发生不可修复的错误。它也能够记录系统某些规律性的行为，使管理人员借以梳理并总结出信息系统的普遍行为，规划出系统的运行负载和服务能力。IT运维监控系统还能够协助信息安全工程师发觉系统运行中的异常信息，能够实现IT运行的可视化，以帮助企业高层及时掌控信息系统的实时状态。如果IT运维监控系统更加智能的话，它甚至在发现故障之后自行解决故障，而不用值班人员在发现故障后凌晨给系统管理员打电话惊醒对方的美梦。也就是说，好的IT运维监控系统能够给企业信息技术人员和管理人员注入正能量，使大家能够非常愉快地投入每天的工作，而不是充当救火队员时刻紧张地准备冲到第一线。
但往往理想很丰满，现实很骨感。很多时候，我们遇到的往往是糟糕的监控系统，它带给我们的只有种种的不快，例如如下场景，您是否似曾相识：
l某些监控系统在遇到系统故障时，常常不报警、或者总是报警，不是让管理人员挨上级批评，就是被频繁的报警短信或者电话逼疯。一般来说，前一种情况往往是由于监控系统长时间没有得到有效维护，继而导致无法发出有效报警引起的；而后一种情况则是由于监控项得不到合理调整而频频触发监控阈值引起的。
l某些监控系统往往在被监控端部署庞大的客户端程序，长时间运行后产生各种各样的问题，例如消耗服务器资源、触发服务器过度负载、引发安全漏洞、产生庞大的网络流量等。
l某些监控系统缺乏服务商良好的技术支持。随着监控项的增多，监控项报警的能力逐渐丧失，效率越来越低，或者服务商提供的服务费用较高，增大了企业的运营成本。
l某些监控系统技术封闭，管理人员缺乏对该系统的全面了解，在出现报警故障等问题时无法寻找有效的技术支持，影响系统安全。
l某些监控系统架构封闭，可扩展性较差，无法针对业务灵活地添加或者调整监控项。
l某些监控系统不支持监控数据采集入库、数据展示、报表统计等功能，导致管理人员无法针对系统性能数据进行故障趋势分析和容量分析。
在当下国内的IT生态环境中，中小型的企业和初创的互联网企业占据绝大多数，它们普遍有着和大型企业一样甚至更为复杂的IT基础设施和业务系统，却不能拿出和后者同样的预算来雇佣同样高水平的24小时IT监控专家，更无法短时间内掏出一大笔钱来购买昂贵的商业监控软件或者相应的技术服务，长期承受着大型商业监控系统软件提供商或多或少的忽视。与此同时，这些企业的核心业务又离不开IT技术的推动，更无法承受IT系统不可用带来的种种损失。如果能够存在一套物美价廉的监控系统，既能适应中小型企业多样架构的IT环境，又具备良好的扩展性和兼容性，无疑会受到这些企业的热烈欢迎。在此，我向大家隆重推荐一款开源IT运维监控系统软件组合-Linux、Nagios、Centreon和NagVis。从操作系统到监控软件，从配置管理工具到可视化监控视图管理工具，这组软件将能够满足中小型企业甚至大型企业多样化的IT监控需求。借助其高效可扩展的架构设计和智能灵活的监控插件，能够满足各类纷繁复杂的监控需求。一句话概括来说：只有您想不到的，没有它做不到的。
1.2 开源监控软件之崛起-Linux、Nagios、Centreon和NagVis
谈到开源监控软件，就不能不提到在业界众所周知的“四大”IT运维监控软件提供商-BMC、CA、HP和IBM。根据Gartner的报告，这四位软件厂商在同领域解决方案中仍然占据着统治性的地位。但这并不意味着“四大”厂商可以高枕无忧了，根据同一份报告，它们同样面临着内部的互相竞争以及来自开源监控软件的竞争。例如，调查报告显示，有29%的受访者认为可以在自己企业内部部署开源监控软件，而且这个比率还在不断升高(Gartner报告：“Challenges Loom for 'Big Four' IT Operations Vendors”April 20，2005）。
“四大”公司的IT运维监控解决方案作为一种成熟的、企业级IT运维管理平台，其优异表现是我们有目共睹的。但纵使是最为强大的武器，如果没有一个好的指挥官和一支卓越的实施团队，不懂得如何发挥武器的强大战斗力，那也不可能取得太多辉煌的战果。在“四大”IT 运维监控系统部署和运行的一些实践中，就出现过各种各样的误区，其中有商务上的、有管理上的、更有技术上的原因，以至于将系统的部署以及后续运维带入了窘境，这种情况在IT运维管理年预算不高的中小型公司中很常见。
Nagios是于2002年异军突起的一个轻量级的开源IT运维监控框架，它原来的名字叫Netsaint，是出于监控网络设备的目的而开发的。在2002年问世之初，略显稚嫩的它面临着What’s up Gold、Big Brother、Host Monitor等小型监控软件，以及其他一些检测主机是否在线，是否存活的简单监控工具的强有力竞争。在1.x的版本中，1.2发行版就已经非常稳定了，自此以来Nagios逐渐赢得了用户的信任，反过来又给它的开发者—Ethan Galstad以更强的信心投入到后续开发中去。从最初的简陋个人工具到无所不能的监视利器，对于正面临重量级企业运维监控系统的高昂成本和维护压力的IT运维工程师和管理人员而言，Nagios的出现为曾经阴霾的天空带来了灿烂的阳光。
作为开源家族中的重量一员，Nagios在设计之初，只能运行在Linux操作系统上，如Redhat、CentOS、Debian 和 Ubuntu等主流Linux发型版本中，大都能够看到Nagios（从版本1.0到3.0）的发行包。值得一提的是，Nagios在Linux的32位版本和64位版本中都工作得很好，因此操作系统版本位数并不是部署和运行Nagios的障碍。一般来说，Linux操作系统系统安装完毕之后，需要安装一系列Development包，才能正常地编译、安装并运行Nagios。除了主流Linux操作系统之外，部分商业Unix操作系统，例如AIX、Solaris，它们的高版本也都能够良好地运行Nagios。但与安装后便已具备Nagios编译和运行环境的Linux系统不同的是，这些商业Unix系统必须手动安装了诸如GCC、Mysql、Perl等必须的编译工具和运行环境之后，才能和Linux操作系统一样，编译和运行Nagios。
俗话说，智者千虑，必有一失，愚者千虑，必有一得。诚然，Nagios作为出色的开源监控框架，其稳定性和安全性毋庸置疑。但是，众所周知，Nagios是出了名的“难搞死”，其可用性和界面友好性一直是运维监控管理人员吐槽的对象。Nagios基于Web的用户界面完全是基于CGI编写，由C语言直接生成Html代码，其风格仍然处在上个世纪，对于现在见惯了各种华丽界面的用户来讲，确实是风格丑陋。更让人难以接受的是，Nagios的配置文件至今仍然基于文本，需要用Linux下的文本编辑器编辑管理。且Nagios的不同配置文件之间关联复杂，当Nagios启动的时候需要检测配置文件之间，以及配置文件内各配置项之间的关联是否合乎规范，否则就会报出校验失败的错误信息，导致无法启动。
作为Nagios的开发者和维护者，要保持Nagios作为一款监控框架的严谨，就需要在安全稳定和易用友好两者之间做出取舍。由于Nagios是一款用来监控生产系统核心服务器的监控软件，其稳定性和可靠性应该是首要考虑的对象。基于以上权衡，Nagios的开发人员选择安全而忽视界面友好度也就可以理解了。在Nagios的发行版中，包含了一个简单的CGI用户界面，该界面向Nagios用户提供了简单的告警展示功能，但不包括任何配置文件管理、用户管理等后台配置管理功能。为了弥补这些缺陷，开源世界的各位大神们就努力开发了一系列的Nagios后台管理工具和前台展示界面，例如Nagios V-Shell、NagiosQL、ICINGA等，其中最著名的莫过于法国人开发的Centreon这一款软件。
Centreon是一款Nagios的前端管理软件，拥有其他Nagios管理工具所无法比拟的优点。Centreon具备强大的模板管理工具，支持批量添加主机和服务，能够自动建立主机和服务之间的关联，采用了AJAX技术，能够实现Web界面的自动刷新、ACL权限管理、日志管理、告警展示图形等功能。Nagios通过NDOUtils插件将监控数据写入后台MySQL数据库中，而Centreon可读取这些监控数据并实时地展示各类告警信息。使用Centreon的Web界面可以轻松地对Nagios进行配置管理，相较于以编辑文本的方式管理Nagios而言，很大程度上减轻了系统管理员的负担。因此，完全可以使用Centreon和Nagios来轻松搭建企业级的分布式IT运维监控平台系统。
有了开源的IT运维监控框架Nagios，以及开源的Nagios后台管理工具Centreon，我们的企业级IT运维监控平台独缺一款监控大屏展示工具，这方面的佼佼者无疑是NagVis。作为Nagios的图形化展示插件，顾名思义，NagVis即是Nagios Visualization（Nagios可视化）的简称。NagVis允许用户上传一张PNG格式的图像作为背景，将被监控的主机或者服务以监控图标的形式摆放在背景地图上，以实时地显示这些被监控对象的状态。NagVis采用了AJAX技术，用户通过浏览器就可以任意地将被监控对象图标摆放在背景的任何位置。NagVis会根据对象的状态显示不同的图标：红色表示紧急状态（CRITICAL），黄色表示警告状态（WARNING），绿色表示正常状态（OK），以及一个灰色背景的问号表示未知状态（UNKNOWN）。除了上述图标之外，NagVis还允许用户自定义文本标签，允许用户在监控对象之间做连接线以标注对象之间的依赖关系。用户可以用这些丰富的监控图标、连线、标签和背景来实时展示企业级IT运行环境的各类细节信息，并将这些信息投放在监控中心的大屏幕上供实时查看。
使用Nagios、Centreon和NagVis这三剑客，再加上Linux集群环境和MySQL数据库，构成了一套一体化企业级IT运维监控平台，省时省力省成本，能够使您的IT运维工作如虎添翼。
1.3 Nagios简介
作为一款开源监控软件，与其他众多开源或者商业监控软件的功能类似，Nagios可以持续监视并检测主机以及主机上众多应用程序的运行状态，并且探测到这些监控对象是否工作正常，一旦发生意外，即可及时发出告警信息。同时，与其他监控软件的不同之处在于，Nagios并不会对这些主机或者应用发起主动检测，而是使用各种类型的插件—运行在被检测主机上的上的各类代码片段，来执行这些繁重的检测任务。作为一种框架式的监控软件，Nagios能够在很大程度上减轻其所在监控服务器的负载，是一种模块化和灵活化的架构。
与其他闭源的监控系统不同的是，Nagios遵循了开源模式，其优势就是能够随需应变地进行扩展而不用担心任何不便。与企图大包大揽的商业监控软件不同，Nagios可以出色地与其他众多的开源工具进行交互，直至众星捧月，独步江湖的地位。
随着现代企业IT系统规模的日渐庞大，已没有哪个企业的IT运维部门能够承受日复一日的人工巡检工作。企业的网络范围和服务边界的不断扩展，IT运维部门迫切希望在系统崩溃或者服务不可用的第一时间得到通知，可以提前公关并安抚客户，而不是被动等待客户的投诉或者抱怨。而Nagios，这一广受欢迎的开源世界明星，正好解决了此类问题，使得系统管理人员能够提前感知系统故障并施展必要的预防措施或者解决手段。
Nagios能够在系统发生警告（Warning）或者紧急（Critical）状态时迅速地通知相关人员，而什么情况下会产生警告信息或者紧急信息，则由系统管理员提前指定。通常情况下，Nagios提供一个Web形式的信息系统状态汇总，以绿色、黄色、红色分别标明某一系统处于正常、告警、紧急状态。此外，Nagios还能够将告警信息通知给特定关联的系统管理人员，无论是通过电子邮件还是借助手机短信，系统管理员都会在第一时间得到系统状态的最新通知。
1.3.1 云计算和海量运维监控的最佳选择
服务器数量的激增，分布式部署范围的扩大，愈发要求监控工具具备全局的监控和展示能力。传统的运维监控人员通常只要面对几十台或者上百台服务器，规模不会太大，而且由于提供服务的种类较为分散，单个群集的规模也很小，往往只有最多2个节点。对于此类环境而言，普通的商业监控系统或者简单规模的Nagios监控系统即可满足需求，无分布式部署要求。但在大规模分布式集群中，工作任务和工作性质明显不同，首先，运维人员面临的服务器动辄就是三五千台甚至上万台，量级大幅提升；其次，分布式操作系统提供存储、CPU调度能力、内存使用、网络等功能，是基本资源的包装整合，从逻辑上看，相当于一台计算机；最后，基于分布式系统开发的应用相当于一个分布式数据仓库和大数据平台，用户可以在上面做ETL处理、SQL查询、数据导入导出等基本操作，以及实现一些MATLAB、统计软件等功能。要满足以上要求，普通的商业监控软件和集中方式部署的简单监控系统已经力不从心，海量数据运维人员要有更强大的整体把控能力，使用Nagios的分布式部署特性和插件机制打造弹性扩展和不断进化的监控体系，对机房网络、带宽、硬件、服务器的性能进行实时监控，以及支持上层应用监控，实现数据分析等，做到对各个方面的情况了如指掌。
面对上万台机器，好几十个模块，几十万个监控项，想要了解哪些机器监控项缺少、 哪些机器监控项异常、今天有哪些监控项报警、报警了多少次、团队中每个人每天收到多少报警、哪些是可以系统自动处理不报警的等，都需要从监控数据入手。Nagios能够做到使运维团队对整个平台的监控有直观而全面的了解，并在数据的指导下动态调整监控项和阈值，持续完善监控系统。
大规模的互联网公司都极其详细地定制化监控需求，具备自主开发监控系统的强烈渴望。而Nagios能够融入用户多年的运维监控经验，支持自主打造个性化监控系统，并且根据业务需求不断进行优化和完善，这正是商业监控系统做不到的。弹性的Nagios监控平台是一套统一的分布式监控平台，支持系统监控、网络监控、客户端监控、容量监控、 趋势监控等，能自动添加基本监控，对服务器、虚拟机、应用VIP、网络设备、Java应用等能提供准实时预警、报警。在被动监控模式下，从数据采集到发出报警仅需要短短几秒钟，让运维人员第一时间掌握服务的健康状况。同时，它还具备多种故障预测及发现方式、丰富的数据图表展示、容量规划和报警，以及视图的定制等功能，是云环境和海量运维监控的最佳选择。
1.3.2 Nagios的主机检测与服务检测
Nagios的应用场景一般分为主机检测和服务检测。主机检测-即对一台服务器的检测，通常是使用简单的“ping”命令来检测主机是否存活。而服务检测就可以包罗万象了，从对网络服务，例如HTTP、SMTP、DNS服务等的检测，以及进程检测、CPU负载检测、日志文件检测等，通通都可以纳入服务检测的范畴。值得注意的是，Nagios仅在认为有必要的情况下才执行主机检测，例如，只有当某台被检测主机上的所有服务检测项都不可达时，Nagios方才执行主机检测，即使用ping命令检测该主机是否在线。否则哪怕在被检测主机上仅有一项服务可以被检测，而其他服务项均存在异常，Nagios的灵活检测机制也会认为该主机是正常的，并不会使用ping命令执行对该主机的存活性检测并将主机判断为宕机状态。
最简单的网络服务检测手段包括查看指定端口是否开放，以及网络服务监听是否正常，但是并不能判断到被检测的网络服务是否真正运行正常，是否确实在对外提供服务。Nagios却能在网络服务检测的百尺竿头上更进一步。例如，对SMTP（简单邮件传输协议）服务而言，Nagios能够检测到邮件服务器是否能够向客户端发送了“220”的输出信息，即SMTP问候信息（当邮件服务器上的SMTP服务接受一个客户端发起的SMTP连接的时候，它会向那台客户端发送一个问候信息，这些信息作为邮件服务器的标识，而且发送问候信息的目的就是告诉对方邮件服务器已经准备好了）。再比如，对于数据库服务而言，Nagios能够检测到该数据库服务器是否能够解析并返回SQL查询请求。因此，在服务检测的深度和广度方面，Nagios均能够做到锦上添花的效果。
Nagios在设计之初，就考虑到了网络拓扑图中主机之间的依赖关系检测。在事先配置好主机依赖关系的前提下，如果目标主机宕机，Nagios会将该主机标识为“不可达”状态，与之存在依赖关系的相关主机及相关服务都不会被检测，监控人员因而避免了无关告警信息的狂轰滥炸，可将注意力集中在关键主机及服务项的监控方面。另一方面，借助于依赖关系检测及告警，系统管理员也可以在纷繁芜杂的告警或者故障信息中准确定位根源故障，并有助于问题的第一时间解决。
1.3.3 监控信息的提供者
与众多传统监控工具相比，Nagios的亮点在于其遵循完全开源的模式以及插件式的架构设计。Nagios的核心逻辑并不包含任何的主机检测或者服务检测，相反，Nagios使用名为“Plugin【插件】”的一小段脚本或者小程序来执行检测。Nagios提供了能够在各类操作系统平台上执行最基本类型检测的插件库，可以执行操作系统CPU、文件系统、内存、换页空间、网络服务等基本指标的检测。对于想掌握操作系统及相关进程基本运行信息的系统管理员来说，这些检测项就已经足够了。如果还嫌不够？想要关注更多主机上的服务状态，或者想要关注关键业务的运行状态？没问题，Nagios提供了完美的答案—只要您有基本的编程知识，并掌握一些编程语言的话，完全可以编写自己的插件检测程序。但是在尝试定制化开发检测插件之前，别忘了到网络上搜寻一下是否已经有类似的插件程序存在。经过这么多年发展，Nagios已经具备大量拥趸，开源世界的贡献者们已经为其开发了大量且多样的检测插件，可以大大节省监控管理员的插件开发负担。在Nagios的官方网站上，可以找到海量插件，从主机到数据库、从网络设备到存储设备、从硬件检测到机房环境检测，应有尽有。
Nagios的检测插件通常是运行在被检测服务器上的一小段程序，常见的是由脚本类编程语言，例如Bash、Perl、Python等语言编写。Nagios插件可以输出OK、WARNING、CRITICAL、UNKNOWN四类状态，分别代表被检测项处于正常、警告、紧急以及未知四类运行状态。
插件式检测机制意味着Nagios可以检测任何IT系统——只要该系统能够支持脚本检测，传递OK、WARNING、CRITICAL和UNKNOWN等状态信息给Nagios。也就是说，Nagios的检测对象在范围上没有任何限制，只要系统管理人员能够找到一种途径让系统能够传递各类性能数据或者告警数据。例如，可以将基于红外传感器的温度探测系统所发送的温度数据以及告警信息传递给Nagios监控系统，从而实现机房温度探测和机房安全检测。
1.3.4 及时的通知机制
Nagios设计了一个复杂而精巧的告警消息通知机制。借助于该机制，管理人员可以设定，当特定类型的通知消息（主机或者服务的警告、紧急告警信息，或者故障恢复信息等）发生后，并非系统里所有联系人员都会接收到该通知消息，而是只有预先定义的联系人组（contact group）里的人员才能够接收这些通知消息。同样地，管理人员也可以在联系人组里设置多种级别的通知消息接收策略，如进一步转发这些通知消息，抑或是忽略这些通知消息。
在Nagios的消息通知机制中，如果某项主机或者服务被全天候监控，并不意味着系统管理员必须时刻准备接收通知消息而无法得到片刻休息。管理人员可以指定Nagios在每周的工作日——比如周一至周五的早8:00至下午5:00——将告警信息通知到个人，其余时间可以不通知。如果系统管理人员接收到告警通知消息，在规定的时间段内仍旧无法解决问题，Nagios可以将该服务告警信息进一步通知到更高一级别的联系人，这就是Nagios的告警消息通知“升级【Escalations】”功能。如果不采取通知升级功能，问题就有可能一直暴露在工程师层面无法解决，更高一级且拥有更多资源权限和管理权限的人员迟迟得不到通知，导致后果的蔓延和恶化。
Nagios能够运用自由定制的、多样化的外部通知机制，将多种告警信息及时准确地传递给管理人员。借助于邮件系统、短信网关、语音服务器、微信等多种通知手段，系统管理员可以第一时间从多种途径接收到Nagios系统传递的各类通知信息。
Nagios不仅提供了多样化的检测机制和通知机制，还为系统管理员提供了WEB界面，有助于查看丰富的告警信息。无论管理人员想查看信息系统的监控状态总揽，或者技术人员想查看单独的主机或者服务监控项的详细信息、主机组或者服务组的概要信息，Nagios总是为不同角色的人员提供不同的监控视图，有助于一目了然地获知系统的各类故障。
系统管理员当得知某个主机监控项或者服务监控项出现问题，但短时间内不会造成影响的时候，可以直接联系在值班室的同事，将告警监控项设置为“已确认【Acknowledged】”的状态，标明该主机或者服务的告警信息已经被系统管理员确认为不会造成影响，以便于大家将注意力集中在其他关键监控项上。同样地，系统管理员还能够为主机或者服务监控项设置计划停机时间段，避免Nagios在此类时间段仍然发出不必要的告警信息。
Nagios还提供了历史日志查询功能。管理人员可以按照选定时间段浏览Nagios的各类运行日志信息——哪位系统管理员收到了告警通知消息，以及在过去的时间段内有哪些主机或服务产生过告警信息等等。
1.3.5 从外部系统接收信息
在前述的消息通知机制中，Nagios使用手机短信、邮件服务等外部系统发送各类告警信息，但相反的路径同样可以。通过一个独立的接口，外部的独立系统也可以向Nagios发送状态检测信息，甚至是命令——从重启Nagios到各类检测指令无所不包。利用该反向机制，外部的独立系统可以向Nagios传递信息，如Syslog日志信息等。在外部系统集成方面，Nagios没有任何限制。例如Nagios支持分布式监控，这也使得位于不同网络服务区域的多台Nagios服务器能够向中心Nagios服务器发送各自所辖网络区域内的主机服务和服务状态检测信息。统一的视图使得IT运维监控系统的分布式部署、统一监控不再是难以企及的梦想。
1.3.6 Nagios与Linux的关系
Linux操作系统是UNIX操作系统的一种克隆系统，它诞生于1991 年的10 月5 日（这是第一次正式向外公布的时间）。Linux借助于Internet网络，通过全世界各地计算机爱好者的共同努力，已成为今天世界上使用最多的一种UNIX 类操作系统，并且使用人数还在迅猛增长。回到上世纪90年代，Mandrake Linux还是唯一的Linux发行版，而今天，Linux发行版的数量变得数不胜数。这款操作系统现在有100多种。这也是开源软件具有的优点之一。
在Linux的诸多发行版当中，Ubuntu、Linux Mint和PCLinuxOS 被认为是新用户最容易上手的。而Slackware Linux、Gentoo Linux和FreeBSD是需要经过大量的学习后，才可以有效地加以利用的更先进的发行版。 openSUSE、Fedora、Debian GNU / Linux和Mandriva Linux操作系统一直遵循“**”，意味着具备一定基础的用户可以选择这些发行版。 而Redhat Enterprise Linux和CentOS是企业级的发行版，对于那些偏好稳定性，可靠性和高级尖端功能的企业级技术人员特别合适。
Nagios最初设计为运行在Linux操作系统上，但因为Linux脱胎于UNIX操作系统，故其他来源于UNIX的操作系统，例如Solaris、BSD、AIX以及苹果公司的Mac OS X操作系统，都可以运行Nagios。甚至有人声称在微软的Windows操作系统上安装了Cygwin（一种能够在Windows平台上运行的UNIX模拟环境的工具）之后，也可以成功运行Nagios。但笔者建议这种部署方式只能在测试环境下供爱好者研究所用，在正式的生产环境中，还是应该选择企业级的Linux操作系统。
在接下来的章节中，我们主要以RedHat Enterprise Linux Server 6.5 X86_64位发行版作为主要研究对象和Nagios的运行操作系统。
1.4 Centreon简介
与Nagios一样，Centreon也是一款著名的开源监控软件，由法国人在2003年开发。Centreon的历史更为传奇，它最初是由默默无闻的公司新人（新人的创造力往往是惊人的，但很少像Centreon的开发者们这么能持之以恒地坚持一个项目并持续创新）在工作之余且没有预算的情况下开发的。但是现在，Centreon已经走出法国，在全世界得到大范围的应用，甚至出现在著名IT咨询公司Gartner 的报告中。
或许是由于Nagios项目的成功，在项目创建之初，无论是在创始人心目中，还是在众人的眼中，Centreon还是作为“Nagios的WEB前端管理界面”而出现的，是Nagios的众多用户界面插件中毫不起眼的一个小角色。但随着Centreon项目的演化，其变得日渐强大，逐渐成为一套完善而又齐全的IT运维监控解决方案，同时具备了优异而又稳定的用户界面和活跃的开源用户社区，成为开源监控系统中的一位重量级玩家。
与Nagios简陋的WEB用户界面有所不同，Centreon拥有完整的企业级IT运维监控管理界面。Centreon提供了监控系统的实时监控界面和后台管理界面，并辅以各种类型的图形、表格、图标，用来显示监控平台搜集到的各类性能数据，以及平台本身的运行统计数据。Centreon提供了各种类型的模板，帮助用户批量创建各类监控模型，避免了在Nagios上需要逐一创建的大量重复劳动。与一切依赖手工配置的Nagios相比，Centreon提供了建设企业级监控系统所需要的一切自动化工具和设施，这正是Centreon得到更大范围运用的根本原因。
Centreon在IT运维监控方面正在创建一种模式—逐渐替代曾经被认为是不可替代的商业监控系统，实施成本低廉且固定，不会因部署范围的扩大同步增加费用。随着社区版用户的增多，Centreon正在形成一种自下而上的互联网文化，在这个开放社区里，活跃用户的意见得到了充分倾听，有价值的意见在新的Centreon发行版本里得到采纳。例如，Centreon的配置界面集成了全新的模式，引入了用户模板、各类主机和服务监控模板、自定义宏、模板之间的关联和继承等等，这一系列的改进有助于用户创建更多的监控服务和更大规模的部署。此外，Centreon的用户界面得到了进一步改善，提供了基于关键字的监控项过滤、基于组的过滤、停机维护时间管理和告警日志管理等，Centreon甚至还提供了报表功能，支持报表导出为CSV格式。
遵循开放模式带来的第一项好处在于，Centreon能够集成多种必要组件，包括多个Nagios服务器，从而构建一个分布式的企业级IT运维监控系统。Centreon可以连接多个Nagios服务器，将来自多个源头的告警信息汇聚到统一的监控告警视图中。Centreon的监控项配置功能可以在多个Nagios服务器之间保持配置文件的同步，避免了Nagios分布式架构中配置文件不统一的问题。与Nagios的多样化插件机制促使自身保持灵活开放的模式一样，Centreon的分布式管理机制能够使其管理下的多个Nagios服务器之间保持监控任务的负载均衡，从而使得Centreon在管理多样化监控项及分布在不同地理位置的服务器监控方面表现优异。
该模式的第二项明显优势在于，Centreon能够基于自身的访问控制列表（Access Control List，简称ACL）实现精细化的访问管理，通过设置安全策略来保障用户只能看到被授权访问的资源，从而实现自定义的访问控制。相较于Nagios采用简单的、基于Apache的网页用户授权和认证机制相比，Centreon的访问控制机制更能满足企业级IT系统的信息访问控制策略，在满足大型企业信息安全及业务访问需求方面无疑更胜一筹。
Centreon的灵活性及用户成熟度使其成为IT运维监控人员眼中的佼佼者，其部署规模稳步增长。围绕着Centreon，用户群逐渐分化为两种：一种是追求完全自定义界面的用户，另一种则是追求更广泛监控信息和监控报表的用户，前者追求华丽的外表、后者则更注重详实的内容，可谓相得益彰。
在Centreon开源社区版的基础上，其开发团队还陆续推出了Centreon MAP、Centreon BAM和Centreon BI等商业产品。Centreon MAP是Centreon的可视化监控视图界面，允许系统管理员以图形的方式定制自己的可视化监控界面。Centreon MAP可以定义类似于微软Office Visio类似的网络拓扑图、应用拓扑图、地图以及业务流程等逻辑或者物理视图，可以直观地为用户呈现业务流程全景，有助于用户在故障时准确定位故障点。而借助于Centreon BAM，用户可以定义业务流程中的关键节点，实现关键业务流程的风险监控，进而完善企业信息服务，例如ERP服务的高可用性。最终，由Centreon BI向用户提供性能报表和设备故障率统计，用于后续的容量管理和问题管理。在Centreon的生态环境中，从底层检测数据的采集，到中间数据逻辑处理，再到前台展示，各个层级都能够通过灵活的界面进行配置，便于用户能够从业务视图、逻辑拓扑、设备管理、告警统计、业务流程展示等角度对IT运维监控工作做全方位展现，实现了“一屏在前，全局尽显”。
限于Nagios的开发团队在推陈出新上的乏善可陈，Centreon团队在两个方面做到了改进，站在了巨人的肩膀上。改进之一是基于原有的Nagios核心引擎打造了新一代的Centreon-Engine引擎，改进之二是创建了Centreon代理程序，用以替代Nagios的NDOUtils工具。
1.4.1 Centreon引擎
Centreon-Engine，又称Centreon引擎，是在Nagios核心引擎基础上演进而来的另外一个分支。其目的在于，通过发布一系列Nagios核心引擎的补丁，丰富Nagios核心引擎的特性。其相较于Nagios引擎的核心变化在于改进Nagios性能、解决Nagios长久以来被忽视的bug、以及添加各类丰富的特性以满足用户期待等等。
1.4.2 为什么要有Centreon引擎
在过去的数年中，Centreon从Nagios中获益良多，围绕着这两款软件周围，产生了诸多活跃的用户群体，以及他们所做的一系列杰出工作。但是，在过去的3年中，这股激情和活力在Nagios方面明显下降。Nagios的开发者们选择了另外一条道路，倾向于借助Nagios向用户提供专业的监控服务，换句话说，Nagios不那么自由了——尽管仍然遵循开源模式，但是变得越来越商业化。当然，换个角度看，这种变化未尝不是好事，一方面它证明了Nagios在当今世界的用户群体越来越广泛，另一方面专业的服务也利于Nagios的进一步推广。但是，对于开源世界和自由社区来讲，Nagios越来越晦暗不明的开源定位和前景使它的号召力未免越来越暗淡无光。
至今，自Nagios的第3版于2008年推出已经过去了近6年时间，在这6年时间里，Nagios的改进十分有限。对于精通C语言且关注Nagios的开发人员来说，由于Nagios核心开发团队的封闭性和排他性，很少能够参与到Nagios的改进工作中，这不能不说是一个遗憾。
开源社区的卓越用户们很久以来就持续关注该问题，包括Centreon的开发团队，以及其他Nagios的分支版本，如Icinga等，都在尝试着推动Nagios的改进。用户愈加认识到，Nagios的迟迟不更新已经影响到了它的进一步推广，一些重要的特性必须体现在Nagios中，才能满足用户的要求。但遗憾的是，由于Nagios开发团队的封闭性，这些具备激情和技术能力的开发者们的意见并不能得到立即采纳。即使是到了2013年9月20日，Nagios推出了其正式的4.0版本，但由于存在一些不足甚至不合时宜的特性，也不能完全令用户满意。
由于Nagios面临的挑战持续存在，而开发者们的意见又迟迟得不到采纳，故开发者们将热情转移到了Nagios的分支版本中，产生了诸如Centreon-Engine等Nagios的派生版本。无论是直接修改Nagios官方的源代码，抑或是重新派生出新的Nagios分支版本，至少开发者们的意见在这些分支版本中得到了充分的体现。
1.5 NagVis简介
截至2013年，Nagios已经走过了11个年头，在这11年中，Nagios已经赢得了巨大的成功、收获了广泛的赞誉，但在这个社交媒体和移动互联网大行其道的关键时刻，一些人也敏锐地意识到，Nagios的用户界面十几年中几乎没有任何变化，已经无法满足普通用户挑剔的眼光了，急需升级更新。如果Nagios社区不能提供对用户友好的监控界面，Nagios的进一步推广将会非常困难。面对这些批评，Nagios的开发者们仍旧坚持朴素的、非商业化的用户界面，甚至将其作为Nagios的传统而在后续的作品中传承。
但对于用户意见一向反应敏感的开源社区却坐不住了，在推出了Nagios的管理工具——Centreon之后，开源社区再一次推出可以与商业监控系统视图管理工具相媲美的Nagios平台界面展示插件（addon）——NagVis。该插件可在一张监控地图上自由组合并展示Nagios收集到的性能信息和故障告警信息，为习惯了Nagios传统的CGI界面的人们带来了眼球上的震撼。
NagVis是Nagios社区群体中的一个重要插件（在Nagios的术语中称为addon，不是Plugin），负责将Nagios的监控信息可视化，即向用户展示Nagios的监控信息。在企业级IT监控中心的大屏幕上，我们往往可以看到NagVis的身影。NagVis的独特之处在于，它可以允许用户自由选取并上传一张自定义的背景图片（在NagVis术语中，称为“地图”，即maps），并且能够在背景图片上摆放各类图标——代表被监控主机或者被监控服务，每个图标都可以展示各自代表的被监控主机或者服务的实时状态。如此一来，用户通过观察图标的颜色，就能及时了解到系统的最新状态。
如此一来，NagVis借助简单而又实用的设计迅速虏获了大批的拥趸，为用户带来了各式各样的监控界面设计方法。例如，用户可以将一张地图作为背景，在地图上相应的地点建立机房、机柜、服务器图标，在服务器故障之后就可以做到迅速定位。又比如，用户可以借助Visio等建模软件设计业务逻辑图作为背景，再引入相关联的服务器图标和服务监控图标，共同构成对于关键流程的监控视图。当服务器或者服务发生告警后，用户可以第一时间感知故障，并借助流程图判断业务受影响的范围和程度。
1.6 为什么要基于开源软件构建IT运维监控系统？
要回答此问题，我们首先还是要思考一下商业IT运维监控解决方案存在的种种缺陷。
与基于开源软件所构建的监控系统之灵活多样性相比，商业监控软件企图提供的是一套覆盖范围广、监控项目全的一揽子解决方案。商业监控软件首先假设所有人需要的是同一套解决方案。就某种程度而言，确实存在诸如此类的需求——尽管企业部署了多种多样的IT系统，但都希望在某些服务宕机后及时得到通知。因此，商业监控软件厂商为了卖出更多的监控软件，自然希望自己的产品能够包罗万象，监控范围囊括世上所有已知的软件或者硬件设备。能够监控的设备越多，潜在的客户就越广，最好将让自己的监控产品做成包罗万象的服务，使自己与客户的交易达到一锤子买卖的效果，这是大多数厂商希望达到的目的。
在工作实践中，大家可能会遇到如下的现象。用户考虑到自己的业务越来越依靠IT系统的24小时不间断运行，迫切需要上马一套监控软件来帮助自己监控信息系统，甚至能够预测系统未来的运行趋势。同时用户了解到某几家厂商的商业监控软件在业内很有名气，于是分别向对方发送了邀请函，希望通过对比的方式选择适合自己的IT运维监控产品，并希望立竿见影地见到系统实施的成效。只要软件厂商符合条件且对用户的需求感兴趣，大多会派几名市场人员和售前工程师抵达用户现场，打开花哨PPT的同时向用户不遗余力地推销自家的产品，做出一个大而具有诱惑力的实施方案，对于用户的需求一概说YES。用户自然喜出望外，与心仪的厂商一拍即合，共同签订了合同——当然分为两部分，软件授权费用（一般按照监控节点数购买）以及实施费用。但是到了实施阶段，项目往往陷入了僵局，说好的种种承诺没有兑现，规划好的实施范围开始缩水。甚至隔了几年之后，用户都找不到当初的实施人员协助自己解决问题——用户惊讶地发现该公司的项目团队已经解散！
这是一种矛盾，用户和监控系统厂商两者之间都存在一定的问题。从用户角度来讲，由于自身存在专业技术上的不足，以及对需求理解的不全面、不深刻，往往对即将实施的系统存在幻想，希望一劳永逸地解决问题，偏偏没有意识到监控系统的成熟度往往是伴随着使用者对自身信息系统了解程度的成长而不断增长的。从厂商的角度而言，用户的预算已经被监控软件授权费用占据了很大一部分，剩下的有限实施费用均摊到实施团队，面临高额的人员成本。往往是项目实施一结束，就存在大批人员跳槽的现象，为后续的系统维护升级工作带来诸多不便。这种用户和监控系统厂商的矛盾一直存在，最终可能会走向好坏两种局面——好的局面是双方会坐下来协商解决问题，维持着系统能够正常运行；坏的局面是双方的矛盾达到积累到一定程度达到纷争的地步，用户被迫舍弃这个系统重新开发。这样一来对双方都有损失，用户损失的是系统安全、时间和成本，而厂商损失的则是利益与口碑。
伴随着用户的日益成熟，现在这种现象越来越少了，花哨的PPT和美好的承诺再也不能轻易忽悠用户去花费几十万甚至上百万购买一套庞杂但并不贴身的监控系统。对于需要时时刻刻关注的IT运维监控系统而言，用户对其开发和部署已经逐渐有了自己的考虑。也许就是因为这许多年的折磨（建立项目后，不成功，重建，再次失败的循环往复），以及从中汲取的教训，用户已经组建了自己的IT运维专家小组，已经可以在内部参与甚至主导这种系统的开发工作中了。
伴随着这种演变，用户的技术团队对于监控系统的理解和要求也越来越高。用户逐渐了解到监控系统并非想象中的一次性交钥匙工程，而是在实施之前需要大量的客户化和自定义需求的工程。用户逐渐意识到，商业监控系统厂商能够提供的，也许并非想象中的可以随心所欲监控任何设备和软件的完美监控系统。与其花费精力选择商业监控软件，考察它们哪个能够监控更多的系统，不如将注意力转移到如何打造一个适合自身的个性化监控系统，以及如何更有效地监控自己所关注的项目。
以监控系统中常用的检测网络是否通畅的Ping命令为例，商业监控系统都采用向目的地发送一个ICMP （Internet Control Messages Protocol，即因特网信报控制协议）报文，并向用户报告是否收到一个应答消息，来检测目标服务器是否在线。但假如用户想进行多样化的Ping检测，例如向目的地发送指定数量的ICMP报文、或者想根据Ping命令结果的RTT时间长短报警而非根据主机在线与否报警。更复杂的检测命令还包括使用IPV6 Ping命令进行检测，或者在使用Ping命令检测之前先进行端口试探工作。以上个性化甚至定制化的Ping检测都超出了商业监控软件的能力，以至于受到了绝大多数商业监控软件的忽略。
从监控系统而言，用户愈加认识到对监控项进行个性化定制的重要性。而Nagios作为杰出的开源监控软件，其关注点正在于无与伦比的灵活性。Nagios使用简单的、被称为“插件(Plugin)”的小程序或一小段脚本对用户的业务逻辑、软件、硬件、甚至机房环境进行全方位，自定义的检测。相比商业监控软件之间进行的“军备竞赛”而言，Nagios的监控武器更为犀利，往往一招致命。一旦Nagios用户有了监控新设备和新软件的需求，新的监控插件就会迅速出现，提供比商业监控软件更快更精准的监控功能。实际上，Nagios能够监控你能想到的任何事物，用户需要做的仅仅是配置管理而已。
选择Nagios作为企业级监控平台，意味着你的监控工作只能被想象力、技术能力和眼光见识所拘囿，换句话说，只要你选择Nagios，只有你想不到的，没有后者做不到的。但同时也别忘了，相比商业监控软件轻而易举的安装配置过程而言，伴随Nagios的却是一条充满荆棘之路。随着Nagios的安装，你会发现没有任何可供选择的选项，事实上，Nagios自身并不了解“如何”监控，而是希望用户自己能够对监控需求和监控手段有深刻了解，从而告诉Nagios去监控。换句话说，Nagios的灵活性体现在用户需要自己选择检测插件或监控插件，必要时编写适合自己的插件，来部署到Nagios上实现自己想要的监控。
接下来的章节中，我将带领大家从头开始构建一套企业级IT运维监控系统。从Linux操作系统安装，到Nagios、Centreon和NagVis软件的安装、部署、管理，再到监控系统构建方法论，从底层检测数据的采集，到中间数据逻辑处理，再到前台展示，最终完成系统构建，便于用户能够从业务视图、逻辑拓扑、重要设备、告警统计、业务流程展示等多角度对IT运维监控工作做全方位展现，实现了“一屏在前，全局尽显”。
目录
1 企业级IT监控系统概述 23
1.1 什么是IT运维监控系统 23
1.2 开源监控软件之崛起-Linux、Nagios、Centreon和NagVis 25
1.3 Nagios简介 27
1.3.1 云计算和海量运维监控的最佳选择 29
1.3.2 Nagios的主机检测与服务检测 30
1.3.3 监控信息的提供者 31
1.3.4 及时的通知机制 32
1.3.5 从外部系统接收信息 33
1.3.6 Nagios与Linux的关系 34
1.4 Centreon简介 34
1.4.1 Centreon引擎 37
1.4.2 为什么要有Centreon引擎 37
1.5 NagVis简介 38
1.6 为什么要基于开源软件构建IT运维监控系统？ 39
2 企业级IT运维监控系统的构建-从源代码到企业级系统 42
2.1 可供选择的操作系统 43
2.1.1 选用Red Hat Enterprise Linux作为操作系统 44
2.1.2 选择部署方式 45
2.2 服务器安装规划 45
2.2.1 服务器参数规划 45
2.2.2 服务器存储规划 46
2.3 Linux的逻辑卷（LVM）管理机制 47
2.3.1 为什么要使用LVM 47
2.3.2 LVM基本概念 48
2.3.3 操作系统分区划分样例 49
3 配置VMWARE虚拟机 52
3.1 新建虚拟机向导 53
3.2 VMware的联网模式简介 58
3.2.1 虚拟网络设备 58
3.2.2 虚拟机联网方式之桥接模式（bridged networking） 60
3.2.3 虚拟机联网方式之网络地址转换（network address translation，简称NAT）模式 61
3.2.4 虚拟机联网方式之仅主机（host-only networking）模式 62
3.2.5 关于虚拟机联网方式中的DHCP服务 63
3.2.6 选择Nagios虚拟服务器的联网方式 63
3.3 完成虚拟机创建向导并查看配置清单 64
4 为虚拟机安装RHEL操作系统 66
4.1 引导菜单 66
4.2 操作系统安装欢迎界面（语言及键盘布局） 67
4.3 存储设备选择 68
4.4 主机名与网络设置 70
4.5 时区选择 72
4.6 磁盘分区设置 73
4.7 划分文件系统 75
4.8 安装操作系统软件 85
4.8.1 格式化虚拟机硬盘 85
4.8.2 选择操作系统安装类型 88
4.8.3 安装操作系统 92
4.8.4 操作系统初始化配置 93
4.8.5 创建操作系统账户 95
4.8.6 设置操作系统时间 96
4.8.7 设置Kdump 98
4.8.8 操作系统网络配置 99
4.8.9 yum源配置 100
5 Nagios的安装 104
5.1 Nagios安装前的准备工作 104
5.2 创建Nagios用户和组 106
5.3 编译并安装Nagios 107
5.4 安装Nagios插件 112
5.5 配置Nagios的WEB用户界面 114
5.6 SELinux 116
5.7 访问用户认证与授权 117
6 NDOUtils安装 122
6.1 配置并编译NDOUtils 122
6.2 拷贝编译后的文件至运行目录 124
6.3 检查MySQL的配置 126
6.4 创建NDOUtils数据库表 127
6.5 配置NDOUtils 135
6.6 添加ndo2db为系统服务 139
7 Centreon的安装与配置 144
7.1 什么是监控以及如何监控 144
7.1.1 监控已经不再局限于基础设施 144
7.1.2 基础设施监控 145
7.1.3 应用程序监控 146
7.1.4 SLA监控 147
7.1.5 业务活动监控 148
7.2 究竟什么是运维监控 149
7.2.1 运维监控的原则 149
7.2.2 主动监控模式 149
7.2.3 被动监控模式 150
7.3 SNMP 151
7.4 Centreon-不仅仅是包装后的Nagios 153
7.4.1 MERETHIS公司简介 153
7.4.2 Centreon的功能 154
7.5 Centreon的架构 156
7.5.1 系统组件 156
7.5.2 数据存储 158
7.5.3 检测命令 160
7.5.4 调度进程 161
7.5.5 其他兼容Centreon的调度引擎 162
7.5.6 代理进程 162
7.6 后台服务和定时任务 164
7.6.1 centcore服务 165
7.6.2 centstorage服务 168
7.6.3 定时任务 168
7.7 系统架构-简洁及分布式 172
7.8 捕获SNNP trap告警信息 175
8 Centreon的安装 177
8.1 安装前提 177
8.2 安装Centreon监控系统中央服务器 180
8.2.1 系统软件需求 180
8.2.2 部署Centreon监控系统 187
8.3 安装后配置 199
8.4 Centreon的WEB用户界面 206
8.5 Centreon的语言设置 207
8.6 Centreon的数据库连接配置 208
8.7 通过Centreon激活Nagios监控 209
8.8 安装过程中的问题解决 213
8.8.1 Export时显示sudo相关错误 213
8.8.2 在/var/log/messages中出现Warning: queue send error错误 215
9 Centreon的管理 217
9.1 Centreon的调度进程和代理进程 217
9.2 Centreon对于Nagios调度进程的管理 217
9.2.1 Files选项卡 219
9.2.2 Check Options选项卡 221
9.2.3 Log Options 选项卡 224
9.2.4 Data选项卡 227
9.2.5 Tuning选项卡 228
9.2.6 Admin选项卡 230
9.2.7 Debug选项卡 231
9.3 Centreon对于NDOUtils代理进程的管理 232
9.3.1 General选项卡： 233
9.3.2 Database选项卡： 233
9.3.3 Retention选项卡 234
9.4 Centreon对于ndomod的管理 234
9.5 Centreon的实时监控 236
9.5.1 主机和主机组 236
9.5.2 服务、服务组和元服务 237
9.5.3 硬状态和软状态 239
9.5.4 状态波动与状态特殊震荡 240
10 Centreon的实时监控 242
10.1 专注于实时监控的Centreon 242
10.2 Centreon的通用监控 244
10.3 状态总揽视图 246
10.4 全局健康视图 247
10.5 主机的实时监控 248
10.6 主机的详细信息视图 250
10.7 服务的实时监控 255
10.8 在实时监控界面中进行监控项相关操作 260
10.8.1 主机和服务操作概述 260
10.8.2 处于告警状态下的主机或者服务进行确认 262
10.8.3 计划停机 265
10.8.4 添加备注 269
10.8.5 对于调度任务的直接控制 270
11 Centreon的配置 275
11.1 Centreon的监控对象模型 275
11.2 通用功能配置界面 276
11.3 Nagios配置文件的生成与部署 281
11.4 宏、检测命令与检测插件 285
11.5 检测命令与检测插件 289
11.6 执行周期 294
11.7 主机模板和服务模板 298
11.8 主机和主机组 305
11.9 主机的配置界面 306
11.9.1 通用配置选项卡 307
11.9.2 “关系”选项卡 310
11.9.3 “数据处理”选项卡 311
11.9.4 “主机扩展信息”选项卡 312
11.10 主机组 313
11.11 服务 314
11.11.1 “服务配置”选项卡 314
11.11.2 “关系”选项卡 317
11.11.3 “数据处理”选项卡 318
11.12 元服务 318
11.13 被动监控模式和SNMP trap（SNMP陷阱） 323
11.14 通知 330
11.14.1 通知策略定义 330
11.14.2 为主机和服务配置通知策略 334
11.15 通知消息联系人、联系人组以及联系人模板 335
11.15.1 配置通知消息联系人/用户 336
11.16 Commands通知命令 339
11.17 Escalation-告警通知的升级 340
11.18 性能图形 344
11.18.1 相关定义 344
11.18.2 查看图形与进一步分析 345
11.18.3 配置性能图形相关属性 350
11.18.4 配置性能曲线相关属性 352
11.19 利用性能图形实现早期预警 355
11.20 报表 359
12 Centreon的管理和优化 361
12.1 Centreon的管理菜单 361
12.2 通用选项 362
12.2.1 Centreon的通用选项界面 362
12.2.2 Centreon的监控选项界面 365
12.3 CentStorage的相关配置 366
12.3.1 性能数据的配置管理 368
12.3.2 度量和计量 370
12.3.3 监控性能指标的相关操作 370
12.4 访问控制列表（ACL） 371
12.4.1 访问控制列表的配置与管理 373
12.4.2 访问组 378
12.5 调度进程的运行时统计信息 379
12.6 Centreon监控平台的备份与恢复 381
13 NagVis的安装与配置 388
13.1 NagVis的地图 390
13.2 NagVis的运作机制 391
13.3 NagVis的安装 391
13.4 Nagvis的配置 400
13.4.1 配置NagVis的默认参数 403
13.4.2 配置NagVis的后台数据源 405
13.5 NagVis地图介绍 407
13.6 NagVis的地图的配置管理 409
13.7 NagVis中背景图片的管理 410
13.8 配置NagVis的监控地图 412
13.9 设置NagVis图标的超链接 414
13.10 设置NagVis的WEB界面为自动登录 417
14 构建企业级IT运维监控系统 420
14.1 IT服务管理和ITIL 420
14.2 IT运维监控系统与ITIL的关系 421
14.2.1 ITIL的产生与发展 421
14.2.2 ITIL的管理框架简介 421
14.2.3 运用ITIL解决企业IT服务管理面临的问题 425
14.3 企业级IT运维监控系统的构建与实施 429
14.3.1 咨询与梳理步骤 429
14.3.2 互联网运维监控实践 433
14.3.3 提升监控及预警能力 434
14.3.4 监控及预警质量的持续改进 436
7.1 什么是监控以及如何监控
7.1.1 监控已经不再局限于基础设施
就本书所述的企业级IT运维监控系统而言，已经不仅仅局限于对于IT基础设施，例如服务器、网络、防火墙等对象的监控了。各种复杂的企业对象，例如业务应用、服务水平协议中定义的各项IT服务指标、以及整个业务流程，都已经变成运维监控系统的监控对象。
提起运维监控系统所使用的检测手段，无论哪个领域，基本的检测手段都是相似的：
可用性检测。例如，为了检测一台服务器、一组交换机、或是应用程序开放的端口，人们经常使用ping命令或者telnet命令来实现。更进一步，人们在使用ping命令进行服务器可用性检测时，往往会接着进行性能检测，例如会搜集命令返回的数值，以检测网络的延迟（Latency）。
性能检测。性能检测往往会记录一组数值，并与相关项的阈值进行比较。例如，记录CPU的占用率、磁盘的读写繁忙程度、或者进程的数量等等
完整性检测。该类别的测试时为了验证某些监控项是否完整合规以及是否符合业务逻辑。例如，日志文件中的关键字检测、某一大小不符合常规的临时文件、最近一段时间的交易数量、两个系统之间业务数据的不一致等等。以上列表远远不够，因为每一个公司都有自己的监控性能指标。甚至更进一步，完整性检测可聚合多个独立的监控指标形成一个集合，以全面度量和预警公司的某类业务流程，例如监控某一业务系统的整体可用性。
7.1.2 基础设施监控
IT基础设施的监控是迄今为止运维监控系统运用最为广泛的地方，它涵盖了由服务器和中间件组成的复杂网络内部所有的硬件以及软件层面的监控。以下是对IT基础设施监控范围的一些举例：
网络监控
1) 路由器和交换机可用性监控
2) 网络连接延迟时间及误码率监控
3) 带宽监控
4) 路由器协议一致性监控及VLAN监控
IT基础设施监控
1) 机房温度及湿度监控（借助合适的传感器）
2) 磁盘及网卡IO吞吐量监控
3) 备份磁带库监控
4) RAID状态、存储状态、冗余电源状态监控等等
系统监控
1) 系统的文件系统、CPU、内存使用率监控
2) 系统日志监控
3) 系统换页空间监控等
中间件及应用程序、业务监控
1) 进程监控
2) 执行一次简单业务查询的速度监控
3) 虚拟环境下的虚拟机数量及状态监控等等
7.1.3 应用程序监控
应用程序监控的最终目的是确保应用程序正常运行，从而确保业务的连续性。在很多大型企业中，仅仅监控应用程序的端口状态、应用进程状态或者线程状态是远远不够的，尽管这些监控某些情况下有效果。除此之外，还有必要按照应用程序实际运作的那样，由相关监控项不断执行相应的应用程序功能测试，通过模拟实现应用程序可用性监控。
一般来说，需要为执行应用程序监控任务而设计专门的检测项，该类检测项会执行特定的应用场景，并检测场景输出值是否与预期值一致，例如：为了检测供应链系统是否可靠，专门设计订单创建以及取消检测项。另一方面，如果应用程序在出厂时已经由厂商内置了功能检测插件，那我们在设计相关功能检测项的时候，只需要调用该插件即可，省去了设计检测项逻辑的步骤，更加方便。
需要指出的是，安全问题应该引起特别注意，要为应用程序监控项创建专门的用户，且配置有限的权限。这样一来，监控系统所做的模拟操作才不会与正式用户所做的相混淆，并且便于审计。
7.1.4 SLA监控
SLA服务水平协议（简称：SLA，全称：Service Level Agreement）是在一定开销下为保障服务的性能和可靠性，服务提供商与用户间定义的一种双方认可的协定。此开销通常是驱动提供服务质量的主要因素。一个完整的SLA同时也是一个合法的文档，包括所涉及的当事人、协定条款(包含应用程序和支持的服务)、违约的处罚、费用和仲裁机构、政策、修改条款、报告形式和双方的义务等，同样服务提供商也可以对用户在工作负荷和资源使用方面进行规定。
传统上，SLA包含了对服务有效性的保障，譬如对故障解决时间、服务超时等的保证。但是随着更多的商业应用在互联网上的广泛开展，越来越需要SLA对性能（如响应时间）作出保障。实际上，SLA的保障是以一系列的服务水平目标（SLO，Service Level Objects）的形式定义的。服务水平目标是一个或多个有限定的服务组件的测量的组合。一个SLO被实现是指这些组件的测量值在限定范围里。SLO有所谓的操作时段，在这个时间范围内，SLO必须被实现。但是由于互联网的统计特性，不可能任何时候都能实现这些保障。因此SLA一般都有实现时间段和实现比例。实现比例被定义为SLA必须实现的时间与实现时段的比值。
例如：在“工作负荷<100 事务数/秒”前提下，早上8点到下午5点服务响应时间<85ms，服务有效率>95%，在一个月内的总体实现比例 >97%。
根据上述定义，在本书的IT运维监控系统中，对于SLA的监控，被分解成为对于具备阈值的一些控制点（服务水平目标）的监控，只要这些控制点不超过阈值，那么SLA就认为是正常的。例如，某个电商网站的可用性SLA监控可以被分解为以下关键控制点（SLO）的监控：
1) 平均页面访问时间不超过2秒
2) 主页面显示正常
3) 联系人页面显示正常
4) 订单流程正常
以上4个关键控制点组成了该电子商务网站的可用性SLA，如果这些关键控制点正常，那么该购物网站的可用性SLA就是正常的。
7.1.5 业务活动监控
业务活动监控（business activity monitoring，BAM）这个术语是在2002年由咨询公司Gartner Group提出的，是基于企业应用集成的，用于监控企业运营状况的软件技术。它提供对业务绩效指标的实时访问，以改进业务运作的速度和效率。BAM用于描述一些新兴的能力，这些能力将一些关键技术集中起来，从根本上改变业务系统的状况。
BAM是应用集成技术中发展最为快速、对业务进行优化最有效的手段，其宗旨在于实时获得业务流程运行的状态，自动提供客观分析报告，以改进、优化业务流程，其改进包括技术层面，也包括人员、管理层面。业务活动监控的目标是提供当企业的业务环境发生变化时能够及时了解业务事件的能力，这样就能做出及时的决策。通过提供实时的信息，BAM 方案可以减少成本和加速执行企业事务。BAM 通过采集业务流程运行的实时信息，调用BPM对业务流程进行管理，使企业具备了敏捷型企业所要求的素质，能够快速地响应市场变化，快速地调整业务策略，快速地实施业务流程，同时根据反馈的信息对业务流程进行快速地优化调整。
在我们的运维监控系统中，对于业务活动或者业务流程的监控同样是通过在流程中设置关键监控点（SLO控制点）和指标项来完成的，最好的表现形式是在一张反映业务流程的大图上进行关键节点的展示。
例如，同样是对于电商网站的监控，业务活动监控主要从以下方面着力：
1) 网站可用性和每个页面的可用性检测（适用于章节7.1.4提到的SLA监控）；
2) 网站的订单数量检测；
3) 通过网站接收的订单数量与后台ERP系统订单数量的对比检测；
4) 处于“准备”阶段的订单数量；
5) 订单的平均等待时间和每个时段的等待数量等等。
7.2 究竟什么是运维监控
7.2.1 运维监控的原则
一般来说，IT运维监控系统有两项基本原则：
1. 对被监控的元素要有最小的干扰
2. 确保被监控元素之间具备最大独立性
设想我们将运维监控系统部署在虚拟机环境下，该监控系统除了负责监控企业内部其他IT基础设施外，还同时负责虚拟机自身的性能监控和业务监控。从运维监控系统管理员的角度看来，自然是在虚拟机上配置的监控项越多越好，但监控项的增加可能会导致虚拟机性能的下降，意味着监控系统干扰了自身的性能。因此，从安全和影响范围的角度出发，最好避免尽可能多地在客户端安装脚本和影响性能的各种插件，要尽量从监控软件端搜集被监控端的各类性能信息和故障信息。
基于以上原则，Centreon主要使用两类运维监控模式：主动模式和被动模式。相关内容将在下面的段落中详述。
7.2.2 主动监控模式
主动监控模式是最为经典的，它由发送查询请求，接收并分析查询结果构成。主动监控模式一般遵循以下3个步骤：
1. 监控服务器向被监控端发送请求
2. 被监控端返回监控查询结果
3. 监控服务器分析查询结果、判断并显示被监控项的状态
主动监控模式是运用最为广泛的模式，采用轮询以及请求—响应的机制，具备很高的可靠性，在常见的IT运维监控系统中，有2项主流技术是基于主动监控模式的：
SNMP（Simple Network Management Protocol，简单网络管理协议），是采用主动监控模式的标准技术，也是应用最为广泛的监控技术。
WMI（Windows Management Instrumentation，Windows管理规范），是Windows平台核心的管理技术，用户可以使用 WMI 管理本地和远程计算机。
以上2类协议是运维监控系统的首选，因为它们符合监控系统应遵循的第1项原则，属于操作系统或者设备自身原生（Native）支持的监控协议，对于系统自身运行有最小的干扰程度。然而，对于专有系统、需要经特殊逻辑执行监控的系统、以及不支持通过SNMP以及WMI等非侵入式监控的系统而言，Nagios还提供了可以安装在这些系统上的客户端监控代理——即NRPE（Nagios Remote Plugin Executor，即Nagios远程插件执行器）来执行监控。顾名思义，NRPE是用于在远端服务器上运行检测命令的守护进程，它接收Nagios监控端检测命令的驱动，调用检测插件执行检测，并返回检测结果。同时，通过Centreon也能够以更便利的方式管理NRPE。
除了以上方式之外，还可以通过一些标准的硬件、软件管理协议监控相应的硬件和软件。例如，通过IPMI(Intelligent Platform Management Interface，智能平台管理界面)协议来管理硬件设备，通过JMX（Java Management Extensions，即Java管理扩展）来管理基于Java开发或者基于Java封装的程序、系统、设备等等。还有基于SSH或者Telnet协议的监控，但与上面介绍的各类监控方式相比，基于SSH或者Telnet方式的监控会显著提高监控端以及被监控端的CPU负载，不建议大规模使用。
7.2.3 被动监控模式
与主动监控模式不同的是，基于被动监控模式构建的监控服务器从不主动发起对被监控端的查询，而是化主动为被动，等待各个监控端主动上报自己的状态。与主动监控的服务器相比，基于被动模式的服务器不发起轮询请求，更少耗费自身资源，往往能够管理更大规模的IT基础设施和网络系统。
另外，很多设备部署在企业内部网的DMZ（DMZ是英文“Demilitarized Zone”的缩写，中文名称为“隔离区”，也称“非军事化区”。它是为了解决安装防火墙后外部网络不能访问内部网络服务器的问题，而设立的一个非安全系统与安全系统之间的缓冲区）区，受到防火墙及路由器等安全设备的严密保护。如果不想调整防火墙策略，并且想要部署此类设备监控的话，采用被动模式监控机制，由设备直接向中央监控服务器发送设备健康信息或者告警信息也是可行的手段。
在被动模式下，省去了监控服务器发起轮询、等待并获取被监控项轮询结果这一流程，以及期间的时间延迟等开销，可以达到近乎实时的监控效果。如果在Centreon中部署了采用被动模式的被监控机，任何监控项一旦出现问题，几乎可以立即反映在Centreon的报警界面上，相比而言存在速度上的优势。
采用被动模式的监控系统唯一缺陷就是可能存在告警信息不及时的问题，一旦监控项出现问题，无法向外发送最新的告警信息，那么监控中心就有可能仍然显示为设备正常，但其实已经影响到业务运行了。
页:
[1]