开发者学堂课程【3天吃透 Prometheus：监控系统和 Prometheus 基础】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18444
监控系统和 Prometheus 基础
内容介绍：
一、监控系统介绍
二、监控系统要点
三、监控系统功能
四、总结
五、常见的开源系统
六、Prometheus 的工作系统
一、监控系统概念
对于运维工程师来讲，或者是对于技术运营为主要职业目标的岗位来说，这样一个相关的岗位的三大核心职能主要包括故障管理，变更管理和资源管理。
其中故障管理那也是所谓 sre 当中的一个非常重要的地方，因为 sre 的全称叫做站点可靠工程师，从某种意义上来讲，它的主要核心职能之一就在于提前发现问题，甚至是能够基于某种趋势，数据或者是服务的运行状态提前发现问题，而后将问题或故障扼杀于萌芽之中，当然这其中也包括一些事先有针对性的，有目的性的设计来完成，因为站点可靠性工程师的最核心目标是要评估站点的可靠性有多高，这里有一个叫做mttr类的概念，mttr称之为叫平均无故障时间，还有平均修复时间等等这样的相关概念，就是指我们要衡量一个站点的可用性到底有多高，它应该是用平均无故障时间除以平均无故障时间加上平均修复时间的，而要想能够有效降低平均修复时间，第一关键任务就是在第一时间能知道发生的问题，而后又能够快速的在第一时间定位出问题来，那剩下的就成了解决问题了。而能够让我们第一时间发现问题的最为重要的工具其实就是监控系统，因为我们自己不可能用一双眼睛，或者说哪怕我们所有团队不停的不间断的监视着我们整个系统运行的每一个角落，那这个时候监控系统是通过所谓能够或主动或被动或黑盒或白盒等方式在我们系统上的各个或多个位置通过下探针或者是加传感器甚至是应用程序或者系统自己直接自带的能够实现向外暴露自己内部运行状态的相关数据，从而能够被我们的统一的，集中式的中央监控系统把这些数据收集过来加以分析，存储，展示等相关功能，这就是他的概念。
二、监控系统要点
（1）主机
我们系统复杂到可能各个角落里边有多个主机在支撑我们系统的运行，这是第一点，无论如何我们都应该有主机存在，即便是我们使用了公有云的服务，没有物理主机，只要我们用的是这种云服务，那我们应该也有虚你的主机。主机有很多对应资源的使用状态或者是消耗状态，我们最起码要知道我们的cpu的队列长度或者cpu的饱和度，cpu的错误率。内存和我们对应的文件系统或者磁盘空间等等，这些我们都得知道，所以系统是我们要监控的第一要点。
（2）网络
但是系统彼此之间要能够通信，那很显然要运用网络。比如我们的应用程序，服务器访问对应的后端db服务的时候，那带宽或者我们对应的网络流量是不是已经打满了，还是说它是能够游刃有余的应付内部的业务需求。峰值的时期大概占有率有多高，波谷时期占有率又有多高，这些我们都要了解。所以第二个我们各个对应的主机之间的通信流量，我们得第一时间知道，很显然这是对底层的基础设施上的监控。那如果说我们要使用Coopernatives那样的容器编排平台的话，我们就可以借助于编排平台更好的为上层应用进行监控，但如果没有这样的编排平台，是我们自己借用传统方式去管理的，那除了我们刚才所提到的主机和主机之间网络的监控之外，我们在业务之上通常还应该监控我们的应用。比如说我们的基础设施层的应用比如db等等，包括负载均衡器，就是我们的接入层等等，这些非常重要的基础设施。我们得对每一个应用加以监控，要了解这个应用本身，它的这个负载状况，它的工作状态。以消息队列为例，我们队列那是不是满掉了等等这些我们也得知道，同样的除了基础设施这类应用之外，我们自己的业务应用，比如我们的电商，电商站点，电商门户，我们的支付系统，商品系统，库存系统等等等等，他每一个对应的应用的业务指标是不是能够正常工作，我们也得知道。
（3）辅助监控系统
所以对于这么一个复杂的系统，有那么多个角角落落需要进行监控。那很显然，我们指望人工的去通过像我们平常经常用的什么top之类的命令来做监控显然是不大现实的，所以这个时候就有了各种各样的辅助监控方式。比如像刚才所提到的黑盒监控，可以通过探针的方式进行监控，这其实指的就是不断的去刺探对应的那个服务的工作特性是不是正常。比如我们通过一些被动的监控一下对方的这个网络通信流量来抓取一下对方的通信流量当中有多少正常报文，有多少非正常报文，这是一种方式。
（4）监控代理程序
还有一种方式是我们可以在对应的系统上给它放进去，给他安装上一些专门的监控代理程序能帮我们去采集对应的指标数据，或者叫对应的监控项，了。比如说在主机之上，以主机为例，在操作系统上我们部署一个应用程序，这个程序不断的请求主机中的内核中所暴露了各种状态信息，比如像cpu的队列，cpu的这个使用率，使用率里边可能还包含大家应该知道的内核空间、使用占用比例、用户空间占用比例、中段占用比例、nice占用比例、空闲比例等等。而对内存而言，更应知道它有什么内存，、总空间大小、正常使用的空间大小、share的空间大小、空闲空间大小等等我们也需要进行监控，那些就是对应的 agent 不断的通过内核当中去采集或者去获取相关的数据，并拿到来解决的。
但是还是那句话，即便是我们在主机下了一个所谓的 agent，但是它未必意味着能够监控每一个应用程序，所以应用程序自己，尤其是现代开发的应用程序，他们通常自己就内部自带了能暴露自己自身运行状态的那些接口。如果没有暴露的话，那这个时候我们就只能使用黑盒的方式，从外部基于探针进行监控，或者我们在外部加一个专门儿的代理去抽取对应的应用程序。一般而言，我们也可以借助一个专门的应用程序，把这些数据周期性的读出来，兼容到我们对应的监控系统上去也是可以的，随后我们在这里下了各种各样的探针或者是内置了各种各样的监控代理程序以后，接下来就应该把它们收集到一个统一的位置，进行统一分析，统一存储了，这样子我们随后把它作为我们的运维工具使用才更加的便捷了。
因而通常情况下我们就应该在整体的核心系统外部部署一个所谓叫做监控系统或者叫监控服务器。而刚才所说到的这些技术手段，主要就是让我们的监控服务器与之进行通信，并获取到对应系统之上的某个特定测量维度。测量维度，就比如让你监控一个人的属性，那你会监控什么呢？比如他的身高，体重是不是发生变化了，那么身高就是一个测量维度，体重也是一个测量维度，要不然就是体脂率等等又是一个测量维度，所以我们称之为对于一个服务而言，有很多测量维度，对一个系统来讲也一样。像刚才提到的cpu空闲比例、cpu消耗在内核空间当中的时间比例等等，这每一个概念就叫一个测量维度，我们期望知道它在哪个角度上或者哪一个属性上到底有怎么样的状态变动，这就叫测量维度，而每一个测量维度我们通常就称之为一个指标。而我们对应的监控系统就要针对于每一个系统之上的每一个测量维度，或者叫每一个指标进行获取对方的数据，然后把它纳入进来之后，用用户所需要的方式提供给用户。
三、监控系统功能
（1）采集
要采集数据的话，要想能够第一时间知道系统是不是发生故障了，是不是有异常了，是不是超出预值了，那必须要持续的监控这个被监控对象才行，持续获取对方的特定维度上的指标数据才可以。而这个持续其实是一种离散性的持续，这个离散性持续就是周期性的去采集，采集其实可能有两种方式，也包括我们刚才所提到的。第一，正常情况下，我们应该有哪些被监控系统上的哪些被监控指标，需要在我们的监控系统上指示明白。比如我们要监控哪个主机，这一个主机叫一个监控对象，那么在这个对象上他可能有很多个或者只有一个监控主机，而在一个主机上我们可能需要很多指标进行采集。注意一个主机并不是一个指标，就像一个人并不是一个指标是一样的逻辑。而且更何况一个主机之上除了系统级指标之外，很有可能它还有基础设施类的应用，业务类应用，甚至还包含跟业务相关的其他的指标。这些每一个指标我们都在采集，所以每一个节点或者每一个主机上都有可能多达上百个指标甚至更多，这点要了解。而这种在一个较大规模的系统当中很显然指标数量多达上万个并不鲜见，而这种周期性的采集就意味着是要针对这多达上万个，甚至是数万个，数十万个指标要不停的按照固定的频率把他的相关数据拿过来，拿过来如果用户不要或者如果用户没看，那可能就丢失了就消失了。因此，为了能够让用户对这些曾经采集到的数据，在这个采集点时间过后再看，那我们应该把采集的每一个指标的每一个时间点的数据，我们称为叫样本数据，都要给它存储下来，才能确保时间点过去之后还能看。不然的话，就像我们自己人为的使用top命令看一个系统上的状态一样，使用top命令top运行完以后，要是没把它存下来，那他下一次刷新的时候就没了。
（2）存储
所以这类样本数据，我们还必须把它存储下来才可以，那这个时候通常需要一个存储系统，要注意的是这儿的数据，我们要针对一个特定指标来讲，看它的数据一定是按照时间顺序生成了很多数据，这样的数据我们通常称为叫时间序列数据，这种数据，它的存储格式类似于一直追加的方式来进行存放的。所以有专门的高性能存储系统就被称为叫做ts db，叫做time series database，这儿主要是使用非关系型数据库。关系型数据库也可以，只不过关系型数据库你的每一次数据写入都得很高的系统性能开销。比如我们要查主件冲突，唯一件冲突什么之类的等等。而且他还要插入到整个数据库里边去，很有可能要把一个本来是一个时序数据要转成离散的或者随机型才能保存下来的，因而对较大规模的系统来讲，如果你使用关系型数据库存监控数据的话，很快对应的后端存储系统就会成为系统性能瓶颈。zabbix 其实默认就是使用关系数据库来存数据的，所以在遇到系统规模到一定程度以后一定会遇到各种各样，我们必须得在后端数据库做各种性能优化或者做措施，很多优化措施才能解决相关问题。当然主要原因它其实就是出现的时间太早了，zabbix 曾经一度也是市面上主流的监控系统，但是随着业务的规模的发展，它已经显得有那么一点点不合时宜了。但是在对应的系统规模没有到那么大的规模的场景当中，zabbix 依然是很好的选择，因为无论是文档还是成熟度甚至是稳定度，zabbix 都是无可取代的。
回来再继续说数据存储，现在的设计的监控系统基本上他们的样本数据存储都使用 ts db 来存放，虽然刚才讲到了 zabbix 使用了MySQL有点落后于这个时代，有点显得不合时宜，但更早的系统 cacti，是使用 Database 来完成的。其实到今天为止不能说不合时宜，只不过说它的这种存储逻辑，而且基于文件系统这一来自己使用独立的存储引擎来管理，可能也确实不是那么好用了。另外，在 cacti 一个时代的同时的监控系统还有很多曾经一度与 zabbix 也能够争锋的监控系统，但 zabbix 以它所谓的功能完备，系统稳定，而且解决方案统一等等或者完整而知名，到后来一直成为非常主流的监控系统。但是当应用发展到以分布式为核心特性，甚至是以微服务为主导的现代应用架构下的时候，zabbix 它对动态的这种监控模式支持不是特别理想，还有它这个采用传统的SQL作为后端存储，都已经成为了一个弊端了，但用 SQL 是足以应付当时的采集需要的。所以每一款系统的存在都有它的历史背景。
我们继续说刚才的话题，对应的，监控系统它要伸出去很多触角，把每一个对应指标的数据都周期性的采集过来的，这个对应的数据项，我们称叫一个样本。这些样本我们只有存储下来才能在之后被应用系统管理，或者被我们的监控人员，被我们的s re工程师去分析，去定位故障，去查看，去预知故障等等。而这些数据我们就称为叫历史数据，因为它是过去采用的历史样本，而多数情况下对于单个指标来讲，我们采集过来的数据，它对我们的意义和作用不大。比如说我们采集出来 cpu 在内核空间的使用比例，它的大小对你来讲有多大的意义吗？通常来讲，可参考价值真的不是特别大，所以一定要明白单个指标的参考价值一般不会特别的大，但是这就意味着我们需要将单个指标给它聚合起来统一分析才能发现其中的问题。这个时候我们提到的概念叫聚合，叫做数据聚合，学MYSQL的时候应该也都了解，有什么学到过一些数学聚合函数，求和计数求平均值等等，但是这些传统的聚合方式对于监控系统可能并不一定能够让我们真正发现潜在问题所在。为什么这样讲呢？比如简单举个例子，比如去游泳了，那么有个河上面有个牌儿，他告诉我们平均水深40公分，那并不算太深。但可能河中间有个洞，大概可能会有30米，那还是不可以去游泳。所以平均值并不一定能够非常浅显的揭示出问题来，反倒很容易被他误判。那同样的逻辑，我们这里也是一样的，我们监控在一个时间序列一个维度上采集过来了很多很多相关的数据，那然后想知道比如他这个平均的趋势大概有多大，我们现在能看到一个所谓的平均均值，以为我们的系统没问题，但事实上很有可能我们系统中出现了问题，出现异常值，但异常值可能被平均下来了。所以在聚合上我们就应该有方差标准、标准差、中位数、分位数、百分位数等等等等来进行做辅助分析，这样子才能更好的去揭示我们对应系统的采样数据中有没有问题。如果没有这样的聚合分析的话，你自己拿着放大镜对每一个序列，一个样本一个样本来看，这恐怕对很多人来讲都是不现实的，所以聚合对监控系统来讲是个至关重要的操作。因而那我们对应的也就意味着我们的数据存下来，不光要存历史数据，还应该存趋势数据。所谓趋势数据就是经过聚合分析以后的数据，这个聚合分析就指的是在原来的这个样本数据的基础之上，还要额外再存一些数据，而存的就是聚合分析的结果。有一个疑问是历史数据需要存很长时间吗？那也倒不必要，因为一个月前的数据或者说一年前的监控数据，对我们来讲可能意义并不是特别的大。只不过有些非常大型公司，它要从过去历史的监控数据来分析过去的访问趋势之类，但是对多数公司来说并没有什么意义。而这个例子就是意识到数据才是未来的金矿，这个时候我们再去看一个小范围的这种监控数据，它通常依然意义可能也不是特别的大，因为它毕竟不是电商的交易数据，不是用户的网站浏览活动数据，那种数据的意义一般不会特别大，所以它存了一年半载也够了，但是趋势数据为了查看我们整个网站的或者我们整个应用的访问变动情况，你可以保存的更久一点，保存五年八年，恐怕问题也不是特别的大，这样至少不至于过于浪费和占用空间。总之对监控系统来讲有一个非常重要的组件叫做数据存储系统，而且可能在性能上要求还比较高，尤其是在我们监控对象非常多的情况下尤为如此。
（3）展示
同样就算有趋势数据，看到很多的数据也很难受，因而我们通常还应该有一个非常直观和漂亮的展示系统，我们称为叫展示接口，比如用柱状图的形式来展示我们的趋势，或者用线状图的形式来展示的波动等等，那很显然比直接看数值要直观多了。毕竟人的大脑从进化的角度来看，他也不是拿来去分析数字的，不是特别适合于能快速处理数字，跟计算机不太一样。因而需要在我们的监控系统上，还要提供一个很好的展示接口，但即便如此，就算有个很漂亮的展示接口，那也得去看他，才能展示出来。
（4）告警
如果对应的用户正在休息，服务器突然出现异常值，而且是大规模的长时间的异常，那怎么能够让用户第一时间知道，所以我们还得周期性的对被监控下来的数据做特定的判定，我们称为叫可以使用一个布尔表达式来判定这个对应的监控的指标，每一个采样点的数据是不是超过了异常值，进入异常阶段了，但是一进入异常阶段就就告诉用户，就打扰用户，其实也没必要这样，这样用户会不胜其烦，就像狼来了感觉是一样的，因而为了避免这种让用户一惊一乍的，比如当一个对应的指标正常，本来是正常的，在我们的预值中，突然间超出预值很多，系统可能出现故障了，但这个状态变化，曾经在讲过叫软状态，我们一般不应该第一时间就开始想办法告诉用户，应该是等这个值持续一段时间，依然一直居高不下，一直超出预值，在这个时候就要把软状态变成硬状态并通知给用户，而这种通知通常叫做告警，就是发送通知信息给用户，统称为告警，说白了就是把这个异常值的信息notification发送给对应的接收人。而zabbix还设计了一些比较高级的玩法，比如这个告警信息，发送一个小时以后依然没能解决，那就升级发送，就发送你的领导，过了一个小时依然没解决，再升级一级，那就发送给公司的领导，因为他可能会认为这个影响面越来越大，影响级别越来越高，必须引起更多人的重视才可以，等等类似这种方式，我们称为叫告警升级。这种升级机制在很大程度上它的有效应用，一定是跟我们的策略有关系的。
