开发者学堂课程【3天吃透 Prometheus：Prometheus 监控系统】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18452
Prometheus 监控系统
内容介绍:
一、监控系统基础概念
二、 Prometheus 快速入门
三、部署 Prometheus
四、 PromQL 基础
这次的训练营其实话题应该涉及的会比较多，尽量的把这些个涉及到的话题或者我们计划在内的话题以比较快速的方式给大家讲述完，但是我也有理由相信三个晚上不到六个小时的时间，没准在有些地方我们只能走马观花、浮光掠影了。
今天我们主要会讲到监控系统的一些个概念，还有 Prometheus 系统的一些快速入门，当然我们重点会放在最后，带领大家部署运行 Prometheus ，而后使用 node Exporters完成对节点和应用的监控。我们使用各种各样的 Exporter，我们把它统一以后称为叫做 Exporters来进行再进行暴露，后续的其他话题我们会在后面来进行展开。
一、监控系统基础概念
1. 监控系统发展史
相信很多朋友或许有所了解，并不是一个新生事物。到今天为止，有人把它总结为我们的监控系统已经经历过三代了：第一代主要是以监控网络设备和网络流量为主的时代，尤其是网络设备。
在那种场景或者在那个时代中，我们主要通过 SNMP 协议来监控 IT 信息系统当中的交换机、路由器、网关，当然也包括操作系统本身等等，只不过这些硬件或者操作系统需要内置的 SNMP 协议的支持，而 SNMP 是上个世纪80年代左右所设计的网络管理协议，尽管这期间应该说叫再三版本迭代，但事实上这种简单的设计名副其实，是名副其实的简单，以至于说到后来我们 IT 系统进一步复杂之后，各种各样的监控系统尽管向后都兼容了 SNMP ，但他们不约而同的几乎都抛弃了 SNMP 。这个是应该有所了解的，除非那些老的设备不得不支持的话，那么当今这个时代的监控系统，相信很多朋友一定是耳熟能详的，比如说像 Zabbix ，也包括我们今天提到的 Prometheus ，另外还有像 Cacti 、Nagios 等等，我们都可以算得上叫做当今的一些系统系统。
这个监控系统通常应该具备几个基本的特性，那我们后面还会讲到，比如像数据的采集，对我们监控目标的数据的采集、存储、告警和展示等相关功能，这其实也就是一个完整的监控系统所应该具备的基本功能。后面我们会说第三代，也是目前来讲在一些大厂已然开始进行的这个监控系统，他们或多或少的进入了像比如像基于 Data 驱动的 Date Ops，以及基于AI驱动的 AI Ops。这样的概念也就意味着在其背后都要或多或少依赖于一个立体监控，马上我等会也会讲到在一个立体监控系统的支撑下，完成对于系统运行状态的分析和监视，然后最后反馈到或者回馈到系统支撑上去。我相信朋友们应该知道 IT 信息系统其实就是组合了各种各样的组件来协同工作的，但是有一句话大家应该听说过：不稳定是系统的恒态；稳定的只是其中的一种特殊表现形式。而且大多数系统本身都不是自制的，就算拥有控制器，在本质上来讲，随着时间的推移，它依然无法自制，所以在这种情况下，我们对这种非能自制的系统必须作为人为的使用者来讲，来对这个系统做一个深入的监控，去了解它的运行特性，而后做出相应的决策，那我们不但要做事后监控，还要做事前监控或者叫做事先监控。
我相信到今天为止，很多朋友应该把体检当成一种习惯了，因为人体是世界上最复杂的宏观系统之一了，那这种复杂的宏观系统内部的各个器官间的组合和运作逻辑，我们不能相信他们一定会在任何时刻虽然表现的稳定，但不一定没有故障，不一定背后没有问题，因而我们可能需要进行体检什么之类的。同样的道理，我们的 IT 系统是一样的，所以监控系统对于我们的 IT 系统是一个基础设施，是一个必不可少的组件，而由于现代的人工智能的发展，还有存储系统的演进，所以 Data Ops和 AI Ops 甚嚣尘上，以至于有些大厂已经开始或多或少地去卖弄 Data Ops和 AI Ops 的相关概念了。不过我们依然把话题集中在我们的基础监控系统之上。
2. 监控系统组件
监控系统有四个基础功能。指标数据采集（抓取）、指标数据存储、指标数据趋势分析及可视化、告警。
一般而言，它无非就是对于每一个被监控的目标或者我们关注的信息系统的相关组件，比如它可能是一个主机、一个交换机、一个路由器、一个网关，也有可能是一个应用或一个基础设施服务，甚至还可能是某一个业务的特征，这都有可能。那不管怎么讲，各位应该想必肯定知道的是我们的应用或者我们 IT 信息系统的底层基础设施，无论如何都要运行在主机之上，无论这些主机是纯硬件的或者是物理主机还是虚拟甚至是容器，都可以把它统一成为我们的基础设施层。就这么个基础设施，我们要对它内部运行的各种关键的数据（我们通常把它称为叫随时间而变化的数据，即所谓的指标数据）进行采集，采集下来之后我们就是有了一个又一个所谓的点状数据，这些点状数据也称为叫样本，各位应该知道叫做样本数据。
这些样本数据为了能够做事后的分析和趋势分析，那我们通常需要把他存储下来。如果我们的监控目标非常的多，很显然这个存储系统所需要存储的数据量也必然会很大，否则他何以支撑 Data Ops和 AI Ops 这样的概念。显然，对存储系统的性能，所以说所谓的我们的性能表现，尤其是连续写入的性能表现上或者说持续写入的性能表现上，必须要可圈可点，要能支撑现代的中大型 IT 信息系统的需要才可以。另外我们存储下来的所有的样本数据，或者我们存储样本数据并不是目的，我们基于这些样本数据做一些分析来事先得知系统运行状态，甚至是预测出随后是否有可能会出现问题，才是我们的根本目标。
另外，没准我们为了能够更好的展示我们监控的或者采集的数据的结果，我们需要给他做一些可视化。通常情况下我们的监控系统有一个好的、直观的、美观的，甚至带有一定意义上的分析功能的 UI 界面，这里边有很多朋友听说过 Zabbix 有自带的，然后像 Open-Falcon 这样的系统或者夜莺这样的系统的界面非常非常的炫，再不然就是一个通用的前台界面 Garafana 等等。但不管怎么讲，监控系统如果没有 UI ，很显然在当今这个可视化和 D 代码作为趋势的时代，那这也是一种很 low 的表现。
告警功能：很显然也应该是我们监控系统的基础或者叫做核心功能。毕竟采集下来那么多样本数据，我们不可能人为的二十四小时盯着不放，所以系统内部应该有一个守护进程，他随时去观测着或者叫监视着特定的样本序列或者特定的指标序列是否有异常发生。异常的判定标准通常是一个表达式，这个表达式通常是一个 ball 型表达式，那么一旦满足我们的表达式就认为就有异常发生了，而后我可以触发一种媒介，然后把这个信息通知给用户。注意，这里我们提到一种称呼，称之为 medium 。那通知的方式有很多种，比如说钉钉，国内熟悉的DING TALK 、 WeChat 就是我们的微信，当然也包括最为通用普遍的，我们的邮件等等都可以，这是我们所谓的告警机制。
3. 监控体系
要想在我们当今的 IT 信息系统当中能够有着很好的和完善的监控体系，那我们通常自底向上需要监控很多组件。
其实这个概念我刚刚给大家提到过，比如像系统层监控，包括我们要监控我们的硬件、网络、操作系统等其中各种关键指标，比如像系统当中的 CPU ，还有我们 Load 系统负载、我们内存资源的状态，我们的交换内存的状态，磁盘状态，我们当前系统运行的进程的数量，以及内核参数的调整或者变动等等。鉴于时间有限，我这不会一一的描述，回头朋友们拿到我们 PPT以后自己看就行，我们只需要各位了解的是我们有系统层监控、有中间件及基础设施内容服务的监控、应该有应用层的监控，另外还有业务的监控，同时也有一些业内的朋友称之为还有一层叫做端监控。那我们通常应该对一些比如像我们的 APP，移动设备端的APP或者是某一个特定的程序，它自身的表现来进行监控等等。
4. 云原生时代的可观测性
大体上刚才我们提到过可观测的系统，现在有一个统一的定义：立体监控。
一般而言我们要监控一个 IT 信息系统的三个维度：第一是指标，那其实就是随时间推移而产生的一些与监控相关的可聚合的数据点。注意这些概念，它们这些离散数据，但通常具有聚合和分析的特性；第二种是日志监控，指标信息如果说只能给我们提供一些点状的及组合成趋势的分析的结果，它也需要有一些近似分析的机制，如果要获取更加精细的或者是精确的数据，通常应该使用日志监控。而日志也有结构化和非结构化的，大家应该也知道这些概念；随后还有链路跟踪系统，比如像业内也是非常有名的，它其实主要是在分布式历程当中用的比较多，大家应该知道的，就是分布式链路跟踪或者叫分布式链路调用当中，对于每一个调用大概所经历的时长等性能数据，还有调用本身所输出的状态数据进行收集等等，那这种就叫链路跟踪系统。分布式调用链的跟踪，目前业内的工具也非常多，比如像 Zipkin 、 Jaeger、SkyWalking 、 Pinpoint 等等。监控系统 Prometheus 是最为重要代表；日志系统目前来讲大家知道 ElasticStack 还有 PLG Stack 目前来讲也是最突出的、典型的这个开源代表。后面混沌工程系统大家应该知道，像阿里的ChaosBlade，另外还有那个的ChaosMonkey等等，都算得上是 SRE 工程当中不可多得的优秀工具，那么他们也是我们监控系统当中用于能够更好的让监控系统提前发现问题，或者结合我们监控系统提前发现问题的一个测试工具。好的，那这是云原生时代的可观测性要求要实现的，或者要求我们要达到的可观测性系统所应该具有的立体监控的概念。不过我们今天的 Prometheus 仅仅是可观测性大气当中的一个维度，叫做指标监控当中最为典型的代表。
5. 著名的监控方法论
这里我们简单的说一下监控方法论，以便于后面知道我们为什么要监控或者我们为什么要强调其中的某些监控指标。
在我们监控领域当中有这样三个著名的监控方法论：第一个是 Google 的四个黄金指标，它最早由 Google著名的那本 SRE 的书所带给我们。那很多人就此了解了所谓的应用监控的四个黄金指标，它主要是帮助衡量终端用户的体验、服务中断、业务影响等一些层面的问题，特别适用于应用和服务的监控。那另外一个概念就是 Netflix 的 USE 方法，有同学应该听说过就是所谓的 Utilization Saturation and Errors Method ，主要用分析系统性问题，简单来讲就是 USE 特别适合用于主机级别的监控，很多指标的概念。另外 Weave Cloud 的 RED 方法它是基于 Google 的四个黄金指标的原则下，结合 Prometheus 以及 Kuberneters 容器实践，细化和总结出来的一个方法论。
然后这快速过一遍。首先对于Google的四个黄金指标来讲：
他讲到了我们有四个特别重要的要监控概念概念：第一个叫叫延迟，第二叫流量 Traffic ，第三叫做错误 Errors ，第四个叫饱和度。我可以认为流量其实是一个衡量服务的容量需求的；而延迟则是服务所需要的时长；错误的话，各位应该容易理解，简明之意；而饱和度就是衡量资源的使用状况的。后面我们给大家演示，比如像主机级别的监控是 node Exporters 的时候，我们会尝试带各位利用 node Exporters 自己输出的一些指标来做，比如像 CPU 利用率、 CPU 饱和度， CPU 队列等相关功能的监控，包括还有内存等相关功能的监控，因为这些才是我们真正能了解系统本源问题或者叫最核心、最根本问题的一个非常重要的基础的指标。大家知道监控的指标非常非常多，我们肯定不能每一个都关注，我们必须抓住关键指标，所以这就是所谓的监控方法论带给我们的作用。
另外一个就是 USE 方法。
USE 方法更适用的是主机级监控，就是刚才所说的使用率、饱和度、错误等等已经介绍过了。
那另外一个 RED 方法。
它其实也关注几个关键指标，只不过它的指标这个 Rate 、 Errors 、 Duration ，就是所谓的叫做请求的速率、请求的错误数和每个请求的时长。
话虽如此，无论哪一种方法论，在我们适配到我们的监控系统之上的时候，必须理解我们采集的数据样本基于某种分析形式或者聚合逻辑进行数据分析和聚合的时候，要明白每一种统计方法的优缺点，而后我们把这些统计方法优缺点结合起来，进行扬长避短，去找到最适合的那个监控目标或者最适合的那种监控逻辑。
二、Prometheus 快速入门
接下来我们就来快速说一说，进入 Prometheus 的话题。
首先 Prometheus 是什么？相信各位应该知道它是一款监控系统，同时它自身也是一个所谓叫做时序数据库，我们称之为叫做 TSDB 。所谓时序数据库，你可以理解为就是去存储那些随时间流逝而不断产生的数据。当然我们刚才说过它的功能并非止步于 TSDB ，而是一款设计用于进行目标监控的关键组件。在 Prometheus 当中 target 是一个非常重要的概念，但是这个 target 却可以代表着很多能够输出指标数据的组件，它包括但不仅限于主机也可能是某一个应用程序，也可能是某一个服务，甚至也可能是 Kubernetes 之上的 Ingress 这样的逻辑组件等等。这点各位要注意，等会我会再次强调。而结合 Prometheus 是自己系统内的，回头我为了表达的方便就不再完整的称为叫 Prometheus ，我们干脆就把它称为叫 Prom 。
结合生态系统内的其他组件，比如像 Pushgateway 那还有 Altermanger 和Grafana 等等，我们可构成一个完整的 IT 监控系统。
时序数据是什么？
刚才给大家讲过了，其实就是在一段时间内通过重复测量这个概念，注意这个概念叫做测量，而获得的观测值的集合，然后将这些观测值我们可以绘制于图形之上，那这个时候它应该会有一个横轴一个纵轴，一般来讲纵轴它代表的是我们的值，横轴就代表了我们时间的流逝，这几点都要注意。一般而言我们服务器的指标、应用程序的性能数据还有网络数据，其实这些能够随时间流逝而不断采集的、不断有数据点出现的，都可以称之为叫做时序数据，这是我们时序数据概念。
那 Prometheus 能够在时序数据上做什么文章？首先我们来看 Prometheus 究竟是怎么工作的，从最简单的逻辑上来讲， Prometheus 把每一个能够正常输出指标数据的，注意是能正常输出，叫做指标数据的组件。刚才我提到过它很有可能是一个容器，很有可能是个虚拟机，很可能是个物理服务器，也有可能是一个应用程序，甚至还有可能是一个 Ingress ，我指的是 Kubernetes 里的 Ingress 这样的逻辑组件。那么只要能够被 Prometheus 作为指标产生方来使用的话，那我们都可以把它称为叫做 target 那这个 target 我们把它理解为就是所谓的网络端点，然后 Prometheus 是基于 HTTP 协议，从每一个被监控的网络端点上周期性的去采集称之为叫做指标数据的这样的，或者称之叫指标数据的离散点，并存储在本地以后，随着时间流逝，进而形成所谓时间序列的这么一个监控系统。
注意这里面有几个基本概念，第一我们称之为叫做基于 HTTP 协议来进行工作。第二 Prometheus 的工作方式是著名的监控系统当中的两种工作模型当中 pull 和 push 模型当中，他工作于第一种叫拉取的模型，好处在于任何能够输出指标数据的本身不需要做任配置，我们只需要在 Prometheus 上指定要监控谁，他就能到那个对应的 target 之上抓取指标数据了，而每个 target 就是一个网络端点，由所谓的IP地址，一般而言或者主机名加端口组成。那么说白了就是它应该是一个服务，那这时候 Prometheus 会扮演客户端到这个服务上请求对方，说把你的指标数据给我，那于是这个指标数据就被 Prometheus 拿到，然后 Prometheus 在本地存储一下，这中间通信的时候用的是 HTTP 协议，当然我们也可以把它组织为 HTTPS ，所以我们说这是一个所谓叫做 HTTP call 的形式来完成的。
那另外 Prometheus 其实支持三种类型的途径，从目标上抓取数据的。这些各位要知道，我们的监控有白盒监控和黑盒监控两个概念。这里我做一个简单介绍，白盒监控你可以理解为是一种自省方式，也就意味着被监控系统内部能自己生成指标等监控系统来采集的时候，它自己直接吐出来就行了，这种我们称为叫白盒，拥用有自省功能。那另外一个我们有所谓的黑盒监控，对黑盒监控而言，就意味着我们对于目标系统没有任何侵入性，只是在一旁看着他的状态，看着这家伙比如在大街上你监控着每一个来来往往的人去看其中某个人快到了上去扶他一把，像这种我们认为叫做黑盒监控，我们对他们本身没有侵入性、侵扰，那这种我们称为叫基于探针的监控方式。那 Prometheus 机支持多种监控方式，而如果我们基于白盒监控的话，一般来说我们通常需要这三种途径来完成指标数据的获取：第一，我们称之为要通过 Exporters 来完成，这个 Exporters 其实是一个统一的或者是一个组合概念，它里边包含了各种服务、各种系统、各种组件的这个所谓的叫做指标数据获取机制、获取器或者称叫暴露器，之所以如此，那是因为很多系统在早期设计的时候，并不兼容 Prometheus 自己的指标格式，因而我们需要在那个对应的系统之旁额外加一个附加组件，它一方面作为那个服务的客户端抽取出来传统指标数据，而后自己再格式化为有 Prometheus 兼容的数据以后报给或者在 Prometheus 来采集的时候响应给 Prometheus ，这种我们称为 Exporters；第二个称为叫 Instrumentation ，这个我们称之为叫测量系统。那测量系统我们可以理解为就是应用程序自己内置的,是新式的，本身就支持 Prometheus 兼容格式的指标数据，所以 Prometheus 直接向他来采集就行了。这种我们称为叫Instrumentation 内建了 Prometheus 的指标暴露器；第三个我们称为 Pushgateway 主要是指我们被监控的目标当中有一些有可能是短期任务或者是批处理任务，它本身不可能去暴露任何指标，也很难通过一些 Exporters 去监控的指标了，那这个时候我们就只好基于 Pushgateway 的方式来进行工作。原因在于那些短期或者短生命周期的任务很有可能它启动时间不确定，结束时间不确定，因而一般是使用推送的方式来提供指标，而我们Prometheus本身是不支持 push 机制，它就是 pull机制，所以我们可以借助于 Pushgateway 的机制让这些短期任务能够送给我们的 Pushgateway 而后再等 Pushgateway 暂存下来之后，可以接受 Prometheus 以 pull 的方式就是以拉取的方式，仍然过来去采集数据的。
1. Prometheus 生态组件
Prometheus刚才说过了刮擦的三个途径，那我们 pull 和 push 已经解释了。那我们来看看 Prometheus 生态组件。这个组件其实对我们来讲至关重要， Prometheus 只是它的监控系统或者完整意义上监控系统当中的一个组件，完整意义的 Prometheus 监控系统大概有这样几个组成关键组成部分：第一 Prometheus Server 我们以后把它简称为 Prometheus ，或者我们以后简称的 Prom 指的也是这个 Prometheus Server 本身；第二个组件是 Alertmanager， Prometheus 是一个比较怪异的设置，他自身虽然是一个监控系统，但告警功能并没有内建，或者至少说真正发送告警的这个功能没有内建，其内部能够生成告警信息，但至于如何发送告警，我们需要一个外置的组件来实现，这个称谓叫 Alertmanager 那 Alertmanager 就可以通过各种所支持的或者用户配置的媒介来完成这个对应 Notification 的发送。这一点大家知道比如像E-MAIL，当然老外们、可能我们的同行他们可能会使用 Pager Uuty，还有Chat当中的像 Slack 等等，那我们可能能更加用的或者更加易用的，应该是 DING talk 、 Wechat之类的这样的组件。另外一个组件我们称之为叫做 Examination，就是所谓的 Application 内建的直接能够输出 Prometheus 兼容的指标格式的一个客户端库，当然这一般是一些新式应用程序能支持，不支持的那我们就用 Exporter，所以它的一个重要组件叫 Exporter 。
再接着 Prometheus 自己虽然内建了一个 UI 接口，但这个 UI 我们通常把它称为叫做表达式浏览器，这个表达式浏览器是提供给我们去调试 PromQL 的表达式的，但他展示的那个界面简直是丑爆了，而且本身也没有提供给我们保存下来查询语句以便于随后再用的这样的功能。所以我们一般需要外置一个第三方的 Dashboard 的来作为展示界面，这个组件我们称为叫 Grafana。对应一下我们前面所讲到的监控系统的四个核心组件，首先第一指标数据的采集，那是 Prometheus 自己来完成的，就这里所看到的组件叫 Scriping ，我们把它称为叫刮擦，有人把它翻译成叫刮擦，我们以后把它统一称为叫采集或者抓取都行，叫指标数据的采集，它是周期性的到 Application 之上或者到 Exporters 之上去采集数据的采集下来之后存储在内部， Prometheus 自己内置了一个 TSDB ，注意它内置了一个 TSDB ，而且是自己设计的，目前用的是v3.0系统，是自我开发的，而且也开源出来可供第三方使用的，叫做时序存储系统，接着在 Prometheus 的内部有一个 Rules and Alerts的接口，这个接口我们把它叫 PromQL 合适一点， PromQL 就是 Prometheus 内置的查询语言，而后我们把这个查询语言之上可以构建出来规则，指的是记录规则和告警规则，把它存储下来，随后告警规则可以在触发告警信息之后，由 Alertmanager进行报警。接着我们现在的系统，大家应该知道 IT 系统越来越动态化了，所以我们要把每一个系统纳入了监控系统中来，要单独的静态配置恐怕不合适的。所以我们的还内置了 Service Doiscovery 的功能，它支持基于文件的、基于 DNS 的、基于 Kubermetes的、基于 Consul 的、etc 等等市面上非常主流的各种服务发现注册总线或者叫工具，目前来讲我们的 Prometheus 几乎都能支持到，所以它特别适用于我们当今动态构建 IT 信息系统环境。那所以这是为什么 Prometheus 能够成为 CNCF 旗下重要的或者叫很早期就纳入进去的产品，而且成为第二个毕业的产品，这个都应该知道。这是 Prometheus 的生态组件。
