重磅推荐
这是一本关于如何应对不可信设备的书籍，所有设备实际上都不太值得人类信任，但是它们和我们的幸福却息息相关。我用不着讲述一系列恐怖故事来向读者说明流行的计算机系统在故障发生时怎样。如果你拿起了这本书，说明你已经意识到了这些问题：层层叠叠的库相互依赖着，在抽象、脚本小子（script kiddy）、病毒、DDos攻击、硬件故障、终端用户错误、后门、飓风等抽象概念中隐藏着无数的问题。无论根本原因是恶意入侵还是意外发生，你的系统将会出故障，当它们出故障时，能将你从宕机中挽救回来的只有两个办法：冗余和监控系统。
要先选对方向
从概念上来说，监控系统是很简单的：一个外部系统或一个系统群，主要工作就是监视其他系统是否出现问题。比如，监控系统会定期连接某台Web服务器以确保它能正常响应，如果出现问题则给管理员发送通知。虽然这听起来简单，但是现在的监控系统已经成为昂贵、复杂的软件系统，其中有很多系统的Agent（代理）大小已经超过了500MB，拥有专用的脚本语言，现货标价超过6万美元。
如果一个监控系统能够正确地实施部署，它会成为你好的伙伴。它能在小故障演化成危机前通知管理员，并帮助架构师弄清对应于互操作性（interoperability）异常问题的模式。一个优秀的监控系统能够帮助负责安全的同事将所关注的事件关联起来，为网络运维中心员工展示带宽瓶颈所在，并从业务依赖的关键系统中提取数据，以便为管理层提供他们急需的高层可视化信息。一个优秀的监控系统能帮助用户支撑起服务级别协议（Service Level Agreement，SLA），甚至能在夜晚帮助用户按照预定步骤解决问题，而不用打扰任何人。优秀的监控系统能够帮助用户节约经费，在复杂环境下保持系统的稳定，并使所有人都能安心。
如果实施得不好，监控系统就会带来严重的破坏。拙劣的监控系统会在整晚如同狼那样嚎叫，不会让任何人睡好觉，从而导致没有人再会关注它。它会在用户安全方面的基础设施上安装后门，从其他项目中榨取时间和资源，并在健康检测的过程中，占用大量的网络资源拥堵用户的网络连接。拙劣的监控系统如同吸血鬼一般。
遗憾的是，次就选对方向，对于监控系统的部署来说，没有想象得那么容易。以我多年的经验，拙劣的监控系统不太可能存活到问题被修复的那一天。拙劣的监控系统成为所有人甚至是被监控系统的重担。在这种情境中，很容易明白为什么大企业和政府会雇佣专职的监控专家，并购买标价为6位数的软件，因为他们清楚，次就“选对方向”是非常重要的。
小型或中等规模的公司以及大学的环境会比较复杂，有可能比大企业还要复杂，但是他们明显不会那么奢侈，也不会拥有价格昂贵的工具和专业知识。面对他们分布在各地的校园和分支机构，部署一套精心构建的监控平台将会是一个挑战。但是，在过去的13年里，在花费了相当多的时间负责监控系统的构建和维护工作后，我想告诉各位读者，不仅“选对方向”是可能的，而且还可以是免费的，只不过需要几分辛勤、一些开源工具以及少许的想象力。
为什么选择Nagios
在我来看，Nagios这款系统和网络监控工具，是目前可用的、开源的或其他方面中棒的一款工具。它模块化的设计、直观的监控方式，使其很容易使用，而且高度可扩展。进一步来说，Nagios的开源许可证使其免费可用，并很容易扩展以满足用户自身的特殊需求。Nagios擅长与其他开源工具互操作，而非帮你完成所有的工作，这也是其灵活性所在。如果读者想通过本书寻找一个整体化的软件解决方案，能够通过勾选一系列复选框来解决所有的问题，那我可以很明确地说，本书不适合你。但在放下本书之前，希望你能继续阅读一到两个段落，看我是否能够说服你—那种整体化解决方案不是你真正寻找的。
而现实中，绝大多数商业化产品都搞错了方向，因为它们解决问题的方式是假设所有人都希望采用相同的解决方案。在某种程度上来说，这是事实。拥有大量计算机和网络设备的用户都希望如果某些地方故障时能够收到通知。所以如果读者希望销售监控软件，很明显的方式就是创建一款软件，它要了解如何监控现有计算机软件以及网络设备。但对于那些销售监控软件的人来说，他们认为监控系统是个一站式解决方案，在这场较量中，谁能监控的东西多，谁将终胜出。
我使用过的所有大型商业软件似乎都遵从着这一逻辑。与（Google的）Borg不同，这些商业软件有条不紊地寻找着新的计算机设备并将必要的监控代码加入解决方案中。更糟糕的情况是，某些公司通过直接收购那些已经知道如何监控大量计算机设备的公司，并将这些公司的代码集成到自己的产品中。他们很快痴迷于功能，并创建了一份庞大的产品功能列表，上面写满了支持的设备。因为他们有软件工程师，所以售前工程师会来到你的办公室，露出一排整齐洁白的牙齿，笑着对你的经理说：“没问题，我们的系统可以监控这个。”
问题就在于监控系统不是一站式解决方案。在它能够解决问题之前需要完成大量的定制工作，监控软件的销售者和设计实施软件的工程师之间的差异就在这里。当用户试图构建一套监控系统时，一款通过点击复选框的方式来进行监控的软件不会是用户想要的，用户真正需要的是可以很方便地监控需要监控的设备。专有解决方案往往关注要监控什么，而忽略如何监控，这使得专有解决方案很难满足实际应用。
比如，使用Ping程序。我所用过的所有监控系统都会使用ICMP回显请求，或者叫做Ping，以这种或那种方式来检测主机可用性。如果想控制一套专有监控系统如何使用Ping，则可能会立刻发现架构上的限制。比如想设置ICMP包发送的数量或者想根据包往返时间的毫秒数而非简单的通过/失败，来发送通知。在更复杂的环境下，可能必须使用IPv6的Ping，或者在Ping之前先进行端口试探（PortNock）。这个问题从整体、功能上的解决方式是这些改变意味着核心应用程序逻辑的改变，因此，必须实施。
在我使用过的商业化监控应用程序中，如果上述Ping的例子可以引申，那它们可能需要在监控系统专用脚本语言中重新实现Ping逻辑。或者换句话说，就是不得不完全抛弃内置的Ping功能。对用户来说，可能对Ping检测细节上的控制不一定有价值，但是如果用户连基本的Ping都无法控制，那么在用户环境中，对其他更重要的检测，用户又有多少能够完全控制呢？他们假设知道用户想如何Ping某个设备，至此，游戏结束，他们永远不会再次考虑这个问题。为什么呢？因为Ping功能已经在产品功能列表上了。
目前，监控设备要面向层出不穷的设备，而Nagios关注的是模块化，Nagios包含很多插件，即专用监控小程序，为专用设备和服务提供支持。Nagios不会去增加特性而搞军备竞赛，硬件支持方面是社区驱动的。当社区成员需要监控某个新设备或新服务时，就会有人编写新的插件并发布，速度往往比商业应用程序支持同等服务更快。实际上，Nagios将永远支持用户所需的一切，而且无须对Nagios进行升级。Nagios还提供了两全其美的方案，当用户需要支持时，有商业化的选择，也有兴旺繁荣、乐于助人的社区通过众多的论坛和邮件列表提供免费支持。
选择Nagios作为监控平台意味着监控效果只受你的想象力、技术能力以及管理环境的限制。Nagios能够到达你想监控的任何目的，而且过程极为简单。尽管Nagios能完成商业应用程序所做的一切，或者更多，无须安装笨重不安全的Agent，但它常常无法与商业监控系统相媲美，因为当分析表格时，Nagios没有那么多的检测项目。实际上，如果他们统计正确，Nagios本身不做任何检测，因为从技术上来说，它并不知道如何进行监控，它希望你能告诉它如何监控。“如何”监控这个问题，很难通过一个复选框来回答。
这本书讲些什么
尽管Nagios本身很难，但它是无数工具中能够组建开源监控系统的。同时，它的文档完备，不仅拥有一系列书籍、精湛的在线文档，还有生动翔实的邮件列表。我撰写此书的本意是补充文档中漏掉的部分。这本书不是关于Nagios的，而是讲解如何使用Nagios构建一整套监控平台，更多讲述的是构建监控平台的过程，而非配置某个监控工具。
在本书中，我会介绍一些常用的配置模板，但是如何配置和安装Nagios不是我的重点。我关注的是带领读者构建一套优秀的监控平台，为读者介绍一些能够增强Nagios功能并简化配置的协议和工具。读者需要深入了解Nagios内部的工作机制，这样才能够根据自身需求对它进行扩展。因为Nagios的功能远远超出你的想象，所以在本书中，我会花一些时间展示它的强大能力。后，我还会介绍一些与Nagios关系不大的内容，比如实践、SNMP、时序数据的可视化，以及微软脚本相关技术，如WMI和WSH等。
重要的是，我将以不同的方式介绍Nagios。提前介绍它有效的调度和通知引擎，这样在讨论内部机制的时候就能够简洁明了一些。我将重点介绍插件定制和调度等，使读者尽早了解核心内容，而非将这些重要信息放在很少有人阅读的高级部分中。
尽管本书各章节内容有些许独立性，但是我尽可能使这本书成为重要参考资料，涵盖了一系列重要信息，因此建议读者从头读到尾，略过你已经熟悉的内容。本书文字不是很多，但是信息量很大，甚至在监控方面有经验的老手也能发现一些有用的至理名言。
本书各章节相互依赖，在介绍更为普遍的监控概念时，我也会随意介绍一下某些Nagios特有内容的细节。因为在软件安装前，需要做出很多重要的决定，所以我以第1章的内容作为开始。该章会让读者考虑进行监控的动机是因何产生的？如何取得成功，比如如何开展实施工作，涉及哪些人，要避免哪些问题？
第2章基于第1章的通用设计原则，从零开始介绍Nagios的基本原理，会让读者从细节上明白Nagios的工作机制，但没有提供很具体的配置指令，不会让你淹没在配置的细枝末节里。这里离配置透明化还有很长的一段路要走。
在能够配置Nagios监控环境之前，我们需要先进行安装。第3章将会帮助读者通过源代码或者包管理器安装Nagios。
第4章讲述配置，这是令人畏惧的一章。首次进行Nagios配置对大多数人来说没什么乐趣，但是我希望通过自下而上的方式，只记录常用和必需的指令，提供常用的示例，并指出对象之间的引用关系及如何引用，尽可能减少大家的痛苦。
很多用户在初次使用Nagios之后就无法离开它了，并且厌恶使用其他的工具。但是，如果大家对Nagios都有点儿抱怨，那肯定是配置了。第5章讲了一些题外话，并提供了一些有效的工具，以简化配置过程。这些工具包含自动发现工具，还有图形用户界面等。
在第6章，我们终于做好了准备，去了解系统监控的本质工作，并提供了一些具体的案例：包括一些Nagios插件配置语法以解决现实世界的问题。以监视微软Windows系统环境作为开始，然后介绍了针对UNIX的监视，后介绍“其他系统”的监控，其中包含了网络设备以及环境传感器。
第7章是第2版新增的部分。在过去的5～6年中，大规模网络环境下Nagios的扩展已经成为Nagios系统管理员处理的有意思的问题。设备虚拟化和符合成本效益的云服务的爆炸性增长，需要掌控大量小型节点组成的大型并发处理架构。该章介绍几个工具和策略能够使你将监控的负载分散，并建立一个稳定的大规模监控平台对数万节点进行监控。
第8章讲述了一个我感兴趣的主题：数据可视化。优秀的数据可视化能够解决其他方式无法解决的问题，我很高兴现在能有一些选择，包括那些即将诞生的工具。通过流行的可视化工具，如RRDTool、Ganglia以及Graphite等，可以很容易地将每天Nagios提供的时序数据绘制出来，该章所讨论的不仅仅是折线图。
第9章也是第2版中新增的部分包括，描述了Nagios的商业版本—Nagios XI。创建它的人也是Nagios的创始人，Nagios XI使用了本书所介绍的多种工具构建而成，是真正集成和易用性的杰作，使Nagios监控变得如此简单，甚至我母亲都可以使用（当然，我母亲曾为嵌入式FLIR系统编写了经优化的交叉编译器，希望各位读者明白我的意思）。
读到后，读者应该已经清楚规则了，第10章就要教各位读者如何打破这些常规了。就我所知，该章是介绍的Nagios事件代理接口的纸质内容。事件代理是目前Nagios中强大的接口，掌握它带给各位读者的回报是能够独自重写第2章，读者能够从根本上改变Nagios的运作或扩展它的各个方面，以满足自身的任何需求。该章叙述了事件代理的工作机制，并带领读者构建一个NEB模块。
这本书适合什么人
如果你是一个系统管理员，负责着一堆UNIX、Windows系统和各类网络设备的管理工作，并且需要一个便宜的监控系统，那么这本书正适合你。与你期望的正好相反，监控系统的构建不能掉以轻心。虽然监控系统可能会与环境中所有基于TCP的设备进行交互，但是只需要一丁点这方面的知识。不要以为这会给你多少喘息的时间，系统监控工作教会我的东西比我在职业生涯中做的其他工作学会的更多，并且在我来看，不论你了解多少，使用监控系统都会是不断地挑战假设，加深你对事物的了解，不断扩展你的所学。
为了有效地利用本书，你应当灵活掌握那些经常使用的文本型网络协议，如SMTP和HTTP。尽管它也能与Windows服务器交互，但因为Nagios的守护进程是运行在Linux上的，这使其有很重的Linux风格，即基于文本，所以熟悉Linux或POSIX类的系统是很有好处的。尽管对编程的技能要求不是很严格，但是你好熟悉一些编程技能。本书中有不少代码，但我尽可能地使其直观易懂。但是第8章使用了大量C语言，而代码是在UNIX Shell或Perl中编写的。
在阅读本书的过程中，的要求就是当你了解主题的相关内容时，要长期保持开放的好奇心。如果有什么内容看不明白，别灰心，尝试在在线文档中查找下，或者在邮件列表中提问，甚至给我发邮件咨询，我会尽我所能帮助你。
祝你阅读愉快！
Dave
感谢
我亲爱的妻子Cynthia，她的耐心、鼓励以及美丽，我爱她。
Ethan Galstad，Nagios的创始人，是他的积极促成了本书第2版的出版。
该项目的技术评审都非常出色—伙计们，谢谢你们！
后，十分感谢Prentice Hall出版社的编辑们！他们可不像《蜘蛛侠》或《古灵侦探》中的编辑。Debra Williams Cauley和Kim Boedigheimer都是勤勉、能干的专业人士。他们极其耐心、乐于助人，我很感谢他们为我耗费的时间和精力。
感谢大家！
关于技术评审
Mark Bainter
Mark Bainter领导的系统管理员团队为消息系统的客户们提供大容量邮件系统外包监控和管理服务，拥有超过15年的系统管理员经验，专门从事系统集成、监控与自动化。他是自学成才的博学家，还是一位爱用长词的老顽固。Mark近与他的爱妻和4个孩子定居在德克萨斯，业余时间他喜欢读书、做木工以及陪他的妻子移居各地。
Mike Guthrie
Mike Guthrie是Nagios Enterprise的首席开发工程师，已经为Nagios Core、Nagios XI以及Nagios Fusion开发了很多新功能和附件。Mike使用PHP完成大多数的开发工作，特别喜欢前端Web开发和数据可视化的相关工作。非工作时间里，喜欢和家人待在一起、外出游玩或修缮他的房屋。
Mathias Kettner
Mathias Kettner是Check_MK、MK Livestatus以及Nagios其他附件的作者。他负责德国慕尼黑一家迅速成长的公司运营，该公司专门负责为基于Nagios的监控系统提供专业支持和软件开发。
【媒体评论】
无论你是一个对网络、系统、IT监控知之甚少的新手，还是经验丰富的Nagios管理员，本书都会对你有所帮助。
—— Nagios创始人兼总裁，Ethan Galstad
【作者简介】
David Josephsen
资深系统运维专家，拥有超过10年的行业从业经验，擅长于在复杂的、大规模的网络环境下维护UNIX系统、路由器、防火墙、负载均衡等设备，对Nagios有深入的研究。现担任DBG公司的系统工程总监，负责维护一群分布在各地的服务器农场。除本书之外，他还撰写了《Ganglia系统监控》一书的部分章节。目前他正在负责编写《Login》杂志中的“iVoyer”专栏，发表了大量关于安全、系统监控、反垃圾邮件等技术文章。
【免费在线读】
第1章
佳 实 践
监控平台的构建是一项复杂的任务。监控系统要能够有效地与环境中的其他系统交互，并且要适用于各种客户，不论是菜鸟还是专家。监控平台的构建不仅需要技术能力，还需要精心的规划、全局的视角以及良好的人际沟通技巧。
可能重要的是，所构建的监控系统不能对现有系统造成影响。与优秀的系统相比，拙劣的监控系统会产生一系列的影响，不仅会占用网络、系统资源，还会产生安全问题，甚至会影响到信任它的运维人员。“首先，不要带来伤害”这一信条不仅适用于医师，也适用于正在构建监控平台的你！
本书的第1章包含了一系列的建议，这些建议都是从邮件列表中一点一滴收集而来，它们出自于Nagios的用户列表、系统管理员以及来之不易的经验。我希望本章能够预先帮你做出重要的计划决策，避免一些常见的问题，以确保构建出来的监控系统是巨大的财富，而不是沉重的包袱。
1.1 系统监控的过程方法
优秀的监控系统可不是由管理员闭门造车一个个脚本写出来（这样写出来的系统往往如同摇摇欲坠的空中楼阁），而是有条不紊地创建出来，管理员创建这样的系统不仅要获得管理层的支持，还需要对环境有清晰的认识—包括程序和计算环境，毕竟这些环境也是他们运维的。
如果对环境认识不清，会很麻烦。还是举例说明这个问题吧：如何确定哪些是关键系统，需要通过特定监控手段判断出它是否出现故障？但是对如此简单的问题，现实中常常会上演这么一幕：
经理：你把我加入到监控系统中，我想接收所有系统的告警消息。
管理员：所有的？
经理：是的，所有的告警消息。
管理员：呃，好的。
—第二天
经理：昨晚传呼机响个不停，害我一夜没合眼。这意味着什么？
管理员：哦，服务器1的/var分区满了，连接站点Site5的VPN隧道时断时续。
经理：你就不能通知我实际的问题吗？
管理员：这些就是实际的问题。
大学、医院及企业等机构之所以必须要通过HIPPA、Sarbanes-Oxley、PCIDSS、SSAE16等认证，就是为了要掌控其IT的过程方面。当今，多数组织无论规模大小，都制定了完善的应急计划，以应对糟糕事情的发生。灾难恢复、业务连续性、危机计划等工作，都是为了确保运维人员对业务的关键系统有所了解，在危机时刻到来时按照步骤操作就能保障系统的正常运行，或者在系统被破坏时能及时恢复。此外，这些认证也同样可以确保管理层为避免关键系统故障而进行过相关检查：如安装冗余设备或保存离站的磁带备份。
无论出于什么理由，这些应急计划的过程方法似乎都遗漏了监控系统。大多数监控系统都是因为1～2个小型技术团队对此有特殊需求，而作为兴趣项目上线的。通常情况下，多数团队都是各自使用自己的监控工具，无视组织内部的其他监控手段，这里似乎没必要连累别人。虽然这种系统监控方式可以满足个人或小团队的一时之需，但当规模扩大时就会慢慢暴露其弱点—由于早期缺乏规划，使其在发展过程中慢慢变成需求实现的堆积，整个系统将会变得十分脆弱，而用户的组织将会成为终的受害者。
为了理解为何这个问题如此危险，则要考虑到在缺少过程化实施的监控框架的前提下，数百个关键重要的问题基本上无法回答。比如下面这些问题：
系统监控所消耗的总体带宽是多少？
为确保监控系统正常运行，客户端所需的UID是什么？
路由器或者其他系统依赖于什么？
在主机和监控系统之间，是否有敏感信息以明文传输？
如果有必要为监控某个进程编写一个脚本，那么也同样有必要思考当系统运行的这个脚本故障时会发生什么，或者是否会出现这样的情况：某人的账户被禁用但他写的脚本还在。治标不治本的方式，是迄今为止常见的系统监控方式，这种方式带来了太多的问题。
我们前面所举的例子中，其核心问题就是没有标准能够明晰地定义什么是一个“问题”，因为监控系统部署时，这些标准还不存在。我们的经理感觉看不到系统的问题，而为他提供了详细信息的时候，他依然感觉没有获得什么有价值的信息。这就是为什么过程方法非常重要。负责监控项目的人在工作前应当明白：哪些系统对组织的正常运作起到关键作用，管理层对于这些系统正常运行时间的期望值是什么。
明确了上面两个问题之后，就能将策略制定为详细的支持和扩展计划两部分。应当对关键系统的优先级及必要部分进行定义。这并不是说例子中的管理员在服务器1的/var分区满了的时候不应发出通知，而是说，在收到通知的时候，他应该明白该通知是什么意思。管理层是希望他立刻修复还是明天再说呢？还应通知谁呢？如果他不响应会发生什么呢？将这些信息定义明确也对管理层有帮助。只有明确地定义了问题的构成，管理层才能提出自己的见解，比如对哪种告警需要问询，可能更重要的是他们什么时候才能回去睡觉。
小公司可能只有一个兼职的系统管理员，很容易陷入治标不治本的监控怪圈。想象一下，一个只有4个人的公司，还需要依照运维制度执行，这种做法看起来不仅愚蠢还浪费时间，但在小型环境中，事故响应处理制度确实更为重要。通过精心构建的监控系统来贯彻深思熟虑的制度，将会使问题得到快速响应并系统化，否则，小公司一旦出现问题就将面临崩溃。
理想情况下，一个监控系统应当执行组织的制度，而非仅仅将问题反映出来。如果管理层期望有人能在10分钟内查看服务器1的所有问题，那么监控系统应当给我们的管理员提供明确的指示（比如优先级）、确认告警消息的机制以及告警的自动升级—例如，超出10分钟的时候通知其他人。
那么我们如何知道哪些系统是关键的呢？因为公司高层为公司正常运营负全责，所以应该由他们来决定，这也是让管理层参与进来的重要原因。如果你认为这开始听起来像灾难恢复计划的工作，那么说明你已经领先了。灾难恢复的工作主要是确定关键系统从而定义恢复的优先级，规划监控平台的时候也一样。实际上，如果已经制定了灾难恢复计划，那么就参照灾难恢复计划继续吧，因为关键系统已经圈定了。
关键系统虽然已由公司高层确定，但不一定都适用同一个原则，例如：“服务器1上的所有问题要在10分钟内查看”，很可能公司高层只是定义了逻辑实体，例如“邮件系统是关键系统”。所以当关键系统确定后，实施人员应该对每个关键系统的组件进行分析。在这个过程中，一定要保证所有利益相关方都参与进来。邮件系统管理员将能提出一些好的想法，比如邮件系统的组成、邮件监控的标准—如果没有这样的标准，那么系统管理员将不可避免地切换回自己的监控工具。
上述工作要与尽可能多的团队合作，并获取信息，如果无法制定一个解决方案满足所有人的需求，那么至少要满足所有关键系统监控的特定需求。如果已有自定义的监控脚本，千万别错过，尝试将它们整合到系统中。每个小组都趋向于信任自己已经在使用的工具，所以整合这些工具可以使你得到部分的支持。Nagios在这方面的优势很明显，可以按照自身调度计划和新增规则调用外部监控逻辑。
【内容简介】
本书是介绍Nagios的权威指南。详细讲解了整个监控技术，演示了*做法，揭示了常见的错误及其后果，以及如何避免。提供了所有配置和运行方式，并探讨如何编写自定义模块与基于Nagios事件代理API。
本书从实际出发，在开篇就系统运维中的监控提出一系列需求，从而展开对Nagios系统的初步介绍（第1~2章），随后从实用的角度，全面、详细地讲解了Nagios安装、配置的相关内容（第3~4章）。通过简化配置、实施监控等工作（第5~6章），用大量的示例展示Nagios的实际能力。然后，在扩展方面介绍了一些常用的方案（第7章），并从原理、案例到后的DIY，一步步带领读者进入数据可视化的世界（第8章）。此外，还介绍了Nagios商业版本——Nagios XI的功能特色（第9章）。后，介绍Nagios事件代理（NEB），并用C语言实现完整NEB插件（第10章），使读者进一步掌握NEB的工作机制。
【目录】
译者序
序言
前言
第1章 实践
1.1 系统监控的过程方法
1.2 处理和开销
1.2.1 远端处理与本地处理
1.2.2 带宽方面的考虑
1.3 网络位置和依赖关系
1.4 安全
1.5 沉默是金
1.6 监视端口与监视应用
1.7 谁来监控这些检测插件
第2章 运作原理
2.1 主机和服务范例
2.1.1 从头开始
2.1.2 主机和服务
2.1.3 相互依赖
2.1.4 主机和服务的消极面
2.2 插件
2.2.1 退出代码
2.2.2 远程执行
2.3 调度
2.3.1 检测间隔及状态
2.3.2 分散负载
2.3.3 信息采集和并发执行
2.4 通知
2.4.1 全局陷阱
2.4.2 通知选项
2.4.3 模板
2.4.4 时间段
2.4.5 计划宕机时间、状态确认以及升级规则
2.5 I/O界面总结
2.5.1 Web界面
2.5.2 当前状态
2.5.3 报表
2.5.4 外部命令文件
2.5.5 性能数据
2.5.6 事件代理
第3章 Nagios的安装
3.1 操作系统支持及FHS
3.2 安装步骤及先决条件
3.3 安装Nagios
3.3.1 configure
3.3.2 make
3.3.3 make install
3.4 安装插件
3.5 安装NRPE
第4章 Nagios的配置
4.1 对象和定义
4.2 nagios.cfg
4.3 CGI程序配置
4.4 模板
4.5 时间段
4.6 命令
4.7 联系人
4.8 联系人组
4.9 主机
4.10 服务
4.11 主机组
4.12 服务组
4.13 升级规则
4.14 依赖关系
4.15 扩展信息
4.16 Apache配置
4.17 GO
第5章 Nagios配置文件引导
5.1 开发脚本模板
5.2 自动发现
5.2.1 Check_MK
5.2.2 Nagios XI
5.2.3 自动发现：已死还是永生
5.3 NagiosQL
第6章 监视：通过Nagios插件监控
6.1 本地查询
6.1.1 Ping检测
6.1.2 端口查询
6.1.3 多端口查询
6.1.4 更复杂的服务检测
6.1.5 使用WebInject和Cucumber-Nagios进行端到端监控
6.2 监视Windows
6.2.1 Windows脚本开发环境
6.2.2 COM和OLE
6.2.3 WMI技术
6.2.4 WSH：用还是不用
6.2.5 VB：用还是不用
6.2.6 Windows脚本开发的未来
6.2.7 切入正题
6.2.8 NRPE
6.2.9 Check_NT
6.2.10 NSCP
6.3 监视UNIX
6.3.1 NRPE
6.3.2 CPU
6.3.3 内存
6.3.4 磁盘
6.4 Check_MK
6.5 监视“其他内容”
6.5.1 SNMP
6.5.2 使用SNMP进行工作
6.5.3 环境传感器
6.5.4 独立传感器
6.5.5 LMSensor
6.5.6 IPMI
第7章 Nagios的扩展
7.1 调整、优化以及一些组成要素
7.1.1 NRDP/NSCA
7.1.2 NDOUtils
7.2 使用二级Nagios守护进程进行分布式被动检测
7.3 事件代理模块：DNX、Merlin以及Mod Gearman
7.3.1 DNX
7.3.2 Mod Gearman
7.3.3 Op5 Merlin
7.4 分布式仪表板：Fusion、MNTOS以及MK-Multisite
第8章 可视化
8.1 Nagios性能数据
8.2 RRDTool：基础
8.2.1 初识RRDTool
8.2.2 RRD数据类型
8.2.3 心跳周期和步进周期
8.2.4 小值和值
8.2.5 循环归档
8.2.6 RRDTool创建语法
8.2.7 RRDTool图形模式
8.2.8 RPN
8.3 数据可视化策略：三位系统管理员的故事
8.3.1 Suitcorp：Nagios、Nagios-Graph以及Drraw
8.3.2 singularity.gov：Nagios和Ganglia
8.3.3 Massive Ginormic：Nagios、Logsurfer、Graphite及RRDTool以外的生活方式
8.4 DIY仪表板
8.4.1 了解自己正在做的事情
8.4.2 RRDTool抓取模式
8.4.3 GD图形库
8.4.4 NagVis
8.4.5 GraphViz
8.4.6 迷你图
8.4.7 使用jsvis的力导向图
第9章 Nagios XI
9.1 它是什么
9.2 如何运作
9.3 有什么好处
9.3.1 美观的界面
9.3.2 集成时序数据
9.3.3 模块化组件
9.3.4 强化的报表和高级可视化功能
9.3.5 内置插件和配置向导
9.3.6 运维方面的改进
9.4 如何上手
第10章 Nagios事件代理接口
10.1 C中的函数引用以及回调
10.2 NEB的架构
10.3 使用NEB实现一个文件系统接口
10.4 DNX，实际的示例
10.5 总结
【编辑推荐】
（1） 拥有10余年工作经验的资深运维工程师撰写，Nagios创始人兼总裁亲自作序推荐，权威性毋庸置疑（2） 深度阐述系统监控的**实践和运作原理，全面而系统地讲解Nagios系统监控的各项功能、技术和方法，为构建高效的企业级监控平台提供有效指导
