7、监控集群/13、尚硅谷-Linux云计算-监控- Nagios/39、尚硅谷-Linux云计算-监控- Nagios 相关原理

欢迎大家继续收看上硅谷的Linux云计算视频。大家好，我是汪洋老师。这节课呢，我们去学习我们的监控技术。拉过呢，也是属于一个非常老牌的这么一个监控服务。往前倒了几年，它是比较主流的这么一种监控环境。那我们在讲解我们的监控服务的时候，也会有对应的侧重点。比如我们讲监控会讲三个不同的种类，对吧，第一个开。第二个拉，第三个ZBS。我们会把较大的重心把它转移到我们的Z身上。原因是什么呢？因为现在我们的大部分的新构建的服务都是使用ZS去进行监控的。收集数据的。而开和在新环境中使用的是已经非常之少了。甚至可以说是。疯魔了，你要吧。那对于我们为什么还要学习那和开呢？就是给大家了解一下它的相关的一些知识点以及简单的原理即可。

万一，如果你去的新公司。他们用的还是这种老牌监控服务器，那你是不是还是需要对它有一定了解的？那对于那来说呢，我们会分为三个片段，第一个是讲我们的相关的原理性东西。他的一些监控的方式啊，它的不同点啊。以及它的监控的数据的获取过程啊，对吧，这都是属于这一个片段里，我们去讲解的。第二，构建我们的拉监控。带大家去从头到尾详细的构建一下我们的S集群，对吧？好，第三个添加一台我们的监控主机，Linux的，Windows的我们都添加一台。那首先我们先看第一个片段，也就是它的相关性原理。那拉其实在当时跟开是属于那种相辅相成的这么两款监控服务器，虽然他都他们都是干监控的。

但是他们的侧重点不太一样，有点类似于我们的Di和my circle之间的关系，对吧？并不是谁取代谁。叫noodle对吧，并不是谁取大写。他们是一个相辅相成的关系。那为什么这么去描述呢？我们在这里可以给大家看一下他们之间的对比。首先，开题侧重的是收集数据和图像展示。它侧重的是服务和主机当前的状态。这个怎么去理解呢？凯里会把我们定义的需要保存的时间内的所有的图片都会保存下来。这个我们在之前添加我们图形的时候，在添加的时候，我是不是也给大家说了，诶底下有一个保留选项对吧，默认是一个月。

那也就意味着，如果我想收集查看一下15天之前的这么一个图形环境的话，图形信息的话，在开里是可以完成的。但是如果你的服务出现中断以后，其实开迪不会太友好的告诉你，你的服务器已经死了。你需要自己去判断。对于来说呢，它就比较简单了。它呢，主要的侧重点就是主机和服务当前状态是否可用。哎，不是告诉你五天之前这台主机怎么怎么怎么怎么样。我只告诉你现在。甚至你想问答五天置顶的他都没有。因为它是一个临时缓存保证数据的方案。对于开开里里面来说，它的所有数据的展示都是由我们的图形完成，对吧。对于那它是有这么几个阀值去决定的。第一个。OK。

代表这台主机处于一个正常状态。对吧，没有任何意外，正常工作。第二个。Warning。代表什么警告级别对吧？警告级别，那什么叫警告级别呢？我可以定义一个罚值，当CPU到达85%的时候。你通知我一下。使用量比较大了，当95%的时候，你告诉我，哎，我快不行了。快不行了，还没不行呢，对吧，所以这两个阀值对于85来说可能就是ing级别。对于95来说就是另一个级别了，叫。Tickle。Critical。叫严重警告。严重警告怎么理解啊？就是我快不行了，赶紧来救我吧。是快不行了，那什么时候不行呢，Unknown。

Unknown。我已经不行了。这台主机我已经收收集不到它的信息了，属于一个下线状态对吧。那这个呢，就是我们这四个阀值，就是我们比较重要的在拉里，它能给你显示出来的这么一个标号。当然还有一个叫潘。这个不太常见，原因是什么呢？只有你在添加新主机的时候。正在向新主题收集数据的时候，才会显示出判定状态。也就是这是一个过程。法制。那这是他们在侧重点。展示的时候哪上面的不同点。那还有就是收集数据的不同点。Cady是通过我们的SNNP去收集数据的。标准方案对吧。

但是不是那么灵活，原因是什么呢？SNP也没有把所有的需要数据的数据都容纳进去。如果有一些比较特殊的一些数据，对于SNP的数据来说是比较费事的，因为它不支持本身。对于来说呢，它是通过脚本收集数据，也就意味着只要我们能定义出来对应的收集数据的脚本，你就能监控到对应的数据。因为他没有采用标准方案，这是可以自定义的。比较灵活。那这就是开和NAS的一个简单的对比，从这里也可以发现出来，对吧。对于生态环境人来说。我既需要。可能半年，可能一年或可能一个月，这台机器的所有的数据信息。我既也需要NAS给我呈现出来当前的状态。所以这两方面是都需要的。那怎么办？那就都构建。也就是原来我们可能会比较采用的方案就是开，构建一个构建一个开，也可以判断这台机器之前之前CPU怎么样啊，内存怎么样等一些信息。对于纳者来说，我可以判断当前服务的状态是否正常。

那当然这些问题呢，在我们后面去构建Z的。都不存在了，对吧，一个全部搞定。那。接下来我们继续往后看。呢，是通过我们的脚本收集数据的，这个没问题，但灵活性带来的提高的同时，也会带来另一个东西，就是复杂性的提高。我们在那里定义一台监控主机，定义一个监控的类型是非常费事的。那拉克斯本身也知道。那他怎么办呢？为我们做了一个简单的分类。便于我们去理解这些监控的资源对象。好，那我们过来看一下。首先呢，分为这么几类，第一类我们的主机和主机主。

那主机的概念可能是一台我们的Windows服务器，可能是一台Linux服务器。一台交换一台路由都可以当做一个主机。那如果我们想监控一个，比如一台外部服务器的CPU资源，我要先定义监控这台主机，再定义在这台主机里监控CPU资源，这样才可以。所以主机的定义基本上是必须的。那主机主是什么东西呢？给大家举个例子对吧，比如我现在有100台web服务器。那这100台外部服务器定义的监控的类型可能都是一致的，比如监控CPU，监控内存，监控阿帕奇的当前的状态，对吧？或者是并发量等等。那在这种情况下呢，我们就可以把这100台主机加入同一个主机组里。协同管理。类似于我们Windows中的。玉的概率。

统一管理，集中化管理。好，下一个服务或资源。那刚才我们也给大家提到了，对吧，我如果想去监控一个。外部服务器的幺这台服务器的CPU资源的话，我要先定一个幺这台的主机，在主机下定一个服务或资源。这个服务和资源可能就是CPU的当前利用率、内存利用率等等，这就是服务或资源。那服务组怎么理解呢？相同的服务或相同的资源，我们也是可以把它加在同一个服务组里的。那这样的话同理是不是还是便于调用啊？好，下一个联系人，联系人组。那我们刚才也说过了，对吧，对于我们的na来说，它的侧重点就是监控当前的故障，如果出现故障以后是不是应该报警啊？报警给谁啊？可不能打110对吧。那应该给谁啊？给我们的零是运维。

Linux运维，我们在接到信息以后，我是不是才会去处理这台机器，或者是。发送信息给我们的什么监控人员，监控人员对吧，都是可以的。那联系人呢，我们也会去定义，当我们这个资源出现我们的unknown啊，或者是可的状态的时候，就应该发送至我们的。对应的运维人员解决处理。那当然，如果是一个运维组或者是一个监控组的话，那里面有很多人，那是不是也应该去发送。时段怎么理解呢？并不是所有的。机器或所有的资源都需要七乘24小时乘365天工作的。举个例子，比如我现在有一个我们的。测试环境。什么叫测试环境啊，就是用于我们的。一些开发人员去测试它的代码的执行效果，或者是执行我们的状态是否正常的。

测试完了以后，是不是才能把它部署在我们的生产环境中，对吧？那对于测试环境来说，它也是需要一定的监控的。那。监控如果在周六的时候给你打个电话，或给你发个信息说，诶。你的。我们的什么所谓的，呃，测试环境，哪台哪台服务器死了，恢复一下结果你现在在休假。这是不是有点难受啊？那对于我们的测试环境来说，它的稳定性要求又不是那么高，那只要在正常的工作日把它解决是不是即可？所以对于这类型的一些监控来说，我们是不是就可以把它定义一个时间段？比如一乘五乘24小时，就周一到周五，然后24小时全部监控。周六周天放个假休息一下是吧。那当然，如果是线上环境的话，必须70乘24乘365。这是毋庸置疑的。下一个命令。

命令它的主要意义呢，就是我们去监控对应的CPU资源的话，它是需要有对应的指令去调用的。那在这里呢，就是命令。并且这些监控对象，它最终的结果是全部组装在一起协同工作的，并不是我定义一个监控对象就可以工作，他们一般来说都会相互配置。相互调用。我第一个资源或定义一个服务需要调用到迷。那并列会指定对应的联系人组以及报警的时间。那当然我定一个服务和资源的时候，服务和资源又要属于一个主机下。这是毋庸置疑的。那我们再看下一个，它是怎么样去获取数据的。在这里呢，它不同于我们之前所谓的开体，它通过SNNP收集数据，对吧，那在这里呢，它是由NAS自己去收集数据。调用对应的脚本，对应的脚本返回数据以后传递给那核心程序。

在这里会得到这么一种体现。那在这里我们也可以看到对吧，这是拉屎的核心程序。这哪个服务。我们先看第一个。Check s by z check by z check by z。你会发现它的定义脚本名字都是check下划线。切个下划线，切个下划线，切个下划线对吧，后面两种我们先不看。Check下划线就是我们在NAS里的一个脚本的定义格式。一般都会这么去定义。首先我们先看第一个收集方案。在这里你会发现，诶，对应的C端上面有个service，也就是跑了一个服务，可能就是阿帕奇对吧。那如果那想收集数据的话，在插件管理器这里会出现一个pluging，也就意味着对于那来说，我们也需要去安装插件管理器。

它不同于katy，是一个可选项。在这里你可以理解为这是一个na的附件，这是B选项。好，那插件管理器安装过以后呢，插件管理器会去管理这个小脚本或者小命令去向对方去收集数据。那比如这个可能是通过我们什么是所谓的呃，TT。去检测这个端幅是否是否启动正常的，如果检测通过以后，它是不是要返回对应的数据，然后呢，返回到我们的核心队列去进行对应的展示。下一个。对于我们的类Linux操作系统的red系来说。它是不是只要是我们的red德系基本上都是默认安装SSSHD的，这肯定是没问题的，对吧。这里借助了一个SSH的脚本，通过插件管理器去管理，你会发现这里的顺序颠倒了，对吧。

怎么理解，诶，对方也安装了一个plug。这个plugin有什么意义啊？举个例子，我现在有一堆脚本。谁去拿着用呢？就是plugin去拿着用。也就意味着真正的调用者是plug plugin去调用这些脚本说，诶，这个脚本去给我拿它收集一个数据，诶，这个脚本你去到这台数据收集数据。都是plug去调用的。能理解我的意思吗？所以如果我在这里把plug安装在了对他对方的机器上了以后。那所以呢。这里是收集数据方了。只不过是通过SSH把数据传给你而已，原来是我这边主导收集数据，现在是数据推过来。由谁推，由这个plugin去推。

这是第二种在NAS下的收集方案。第三种。非常重要，也是我们在类unix操作系统里用的最广的一种，它这里用了一个NRPE的插件。在这里RP会以一个守护技能的方式在这里去运行。需要大家注意一下。那当然对方呢，也需要安装一个RP的一个脚本，NRP的脚本已经包含了我们在unix操作系统下大量的一些收集数据的方案了。我们也需要借助插件管理去去通过对方的RP收集数据，也就意味着我会向对方的NRP发起指令，我说NRP，你帮我收集一个什么什么什么信息，NRP收集完成以后会返回数据给我。那当然这方也需要去安装一个plug，负责我们的NRP的完善工作。第三种。

第四种。对于我们一些交换机或路由器来说呢，它是没办法去安装对应的脚本。或叫定义脚本的对吧。因为他都是一个死的。不是一个开放系统。前面呢，我们都可以把它叫做一个。被动方案，什么叫被动数据，被动给我。我问你要你再给我肯定是被动的，那这里呢，叫做主动方案。也就是你不问我要，我就主动提交给你了。谁好谁坏。其实各有优缺点，对吧。对于主动的方案。他可能比如错误故障，我现在感觉我要死了，立马告诉我服务器，哪个是服务器，他是不是就立马知道了。对于我们的被动方案呢，他是不是要经过一定的循环时间以后，比如五分钟以后，他可能再问我一次啊，还活着吗？对吧，如果刚问完，这台机器就已经崩溃了。

那也就意味着我的故障时间是不是已经在五分钟了？那这样的话，这样去描述的话，你会发现诶，主动模式这么友好啊。非常友好对吧，那其实我们在想一个问题。如果现在我出现了大规模的断电。同时有1万台服务器同时向我们拉过，告诉他，他死了。你那个会崩溃吗？这是第一个问题，第二个问题，如果这量主动方案这台机器还没来得及告诉他死了，他就已经下线了。你觉得那知道他死了吗？所以主动模式你可以理解为你可以把它当做一个添加的服务。但是不能把它当做主要的收集手段。万一这台服务器网线断了，系统直接崩溃了，你是没有任何的消息获知他已经死亡了。

所以，被动依然是我们的主要方案。你说被动不是会有延时吗？你可别忘了，咱们构建高可用服务为的是什么？为了是不是就会出现这种意外？既然我有高回放的话，那在一定的时间内，我是不是都是可以接受的，在监控服务里，在真正的生态环境中？十分钟能够达到，正常人员能够接收到信息已经是非踌快的了，20分钟左右都是都是比较合理的。能理解我的意思吗？不可能，这边机器一死，那边立马接受，立马处理。这样太理想化。对于我们的机器的压力也比较大，因为你的循环时间非常小。经济节点过多的话，他肯定承担不了。这是我们的。袁立新介绍。需要大家好好的去理解吸收一下。那这节课呢，我们就先讲到这里。下节课再见。