开发者学堂课程【3天吃透 Prometheus：监控系统和 Prometheus 基础】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1244/detail/18444
监控系统和 Prometheus 基础
四、总结
总结一下就是大体上一个监控系统，它的主要组成为，首先得执行数据的采集，采集依赖于我们系统自身得有一个采集器，也得依赖于对应的监控系统，要么有代理，要么有其他的输出接口，一般而言，我们称为叫被监控端要有代理。监控代理或者称为叫监控客户端都可以。也有一种可能就是应用程序自身就自己暴露指标了，就表示应用系统自己有自己的测量系统，叫应用程序，应用程序自带仪表盘，直接看到仪表盘就行，把内部数据做了expose。这是第一个概念叫采集。采集有多种方式，它也未必能够应付所有的场景，所以也有了所谓的黑盒监控，我们要下探针进行监控，还有黑盒监控直接下探针。对于传统网络设备来讲，比如说我要监控一个交换机，交换机恐怕自己也未必使用什么高级的方式向外露的接口，而用的都是比较传统的SNMP简单网络管理协议，这是一种非常传统的能够让我们监控网络设备内部的工作状态的相关的一个接口，大多数网络设备都带，到今天来看真的显得很粗陋，但是呢他也确实是这些网络设备上不可多得的，不需要改进的这种接口。毕竟我们很多的网络设备它为了把更多的资源拿来去实现数据报文处理，而不应该拿来去做应用方面的操作的站的一个。
第二个是要数据采集下来，要存储，存储还要提供一个分析引擎，里边可能还要自带上刚刚说的聚合函数之类的很多聚合，根据趋势分析函数做一些简单的线性回归分析，做些预测等等，这是第二点。存储我们讲过，有人用SQL存储，有人用noSQL存储，包括k/v，document，column列式存储，，还有时序存储等等。有一个网站叫DB-engines，里面对各种各样的存储做了解释，期中可以看到各种存储的上升和下降等。这是第二点存储和分析，多数只能做一些简单的聚合分析，而更复杂的分析，就要做一些趋势预测，那就要做 AI ops 或者 dataops 了，通过深度学习，线性回归等各种来找到系统发展趋势，预测系统的故障这种系统，当然这已经超出我们的范围了。
第三个叫展示，展示通常就是用非常直观的数据展示面板或者称之为叫图形来帮我们展示，像柱状图，雷达图，线状图等等，在excel当中应该都接触过。所以第三个叫展示。但无论如何你都必须得有展示接口，像 zabbix 有内建的 zabbix 的 web，像 Prometheus 自建的有表达的浏览器，只不过他的展示界面非常鄙陋，因为市面有非常多的对接的展示工具做工作，比如有 grafana，grafana 可以把prometheus 作为数据源来进行展示，它无非就是利用prometheus 内置的数据查询和内接接口来查询，聚合 top 来进行展示，grafana 支持的数据源有数十种之多。
第四个叫告警，告警是将一种持续的异常状态反馈给或者叫通知给用户，叫这叫报警，这里所的报警其实就是通知要打电话告知对方，当然只不过我们的系统可能不会打电话，那我们需要有很多等媒介来进行通知，这个媒介包括我们经常能用到的，能触达到用户的联系方式。比如像最容易理解的短信，email等。现在还有很多即时通信，比如微信，钉钉，国外的slack等，这个就叫做媒介。当然要想通知到那
个人，还必须有端点，就像是手机号，就是媒介到达的位置。
以上就是一个监控系统的四大核心功能。当然报警也不能随便报警，要根本指标，比如我们存多少数据，存哪些数据，如何分析如何展示，如何告警都要进行定义，所以出现了很多方法论。国外有一本书就叫《监控的艺术》，是不可多得的好书。它里面讲到了用好监控系统应该有哪些注意事项，遵循好哪些逻辑。
也有一些组织提供的方法论，能够很好的提供我们监控信息，比如说整个业务当中一定有核心业务链条，报警的时候，通常应该首先报核心业务出了故障，周边业务出故障以后，虽然也应该让用户知道，但如果同时出现我们得有优先级。然后报警的时候，最好能报告对应发生了什么问题，而不要分析原因，因为只有人才能分析清楚程序，机器分析的一般不一定准，你只要告诉用户出现什么问题就行了，而不要试图分析这个问题到底是以什么产生的，让用户淹没在一大堆的信息当中而不知所措。为了能够尽可能的压缩报警的可能性，不至于让用户每一天都收到几百个报警，以至于后来就麻木了，于是就选择性忽视，这种结果报警就形同虚设。为了避免这种问题，我们应该尽可能的减少报警次数，要报有效信息，那怎么报呢？其中奈飞公司有很多方法论在目前在互联网上有很多产品被大家喜欢，其中在主机及指标监控方面，它有一个USE理论，叫利用率，饱和度和故障率。
所以监控cpu应该从这三个维度去监控，而不要有空就看内核空间利用比例是多少等，这种对我们来说并没有用处。
总得来说大家应该知道，我们应该用一些监控方法论来指导我们更好的去使用监控。这比我们安装的监控系统要重要的多的多的多，因为监控系统的安装和配置实在不是一件多麻烦的事情。第一级叫安装和配置，第二是使用的工具，第三我们最好能超越这个工具，能发现工具的弊病，我们甚至还能自己写一些东西，能完善它，这是所谓的运维工程师或者叫运营技术运营的三个进阶路线。
五、常见的开源实现
对于监控系统已经做了个基本的描述，接下来说一说常见的开源实现，比如传统的上个时代的实现，如cacti，cacti是一个很好的数据的抓取和存储感觉，但他不会报警，他的报警是一个短板，人们使用nagios弥补，所以当时人们既要学cacti，也要学nagios，而且cacti的数据抓取的定义还要再借助于别的应用来实现，实在不方便。但是在上个十年初期，确实是是主流软件，因为zabbix还没有成熟起来，而在zabbix成熟起来后，迅速的cacti和nagios就没落了，现在用的人不多了，但是知道目前zabbix依然无法取代nagios强大的报警能力。而现在使用的prometheus本身就有很好的discover能力，能动态纳入各个发现的对象而无需手动配置。
这比起zabbix那个时候好用很多，zabbix虽然到今天为止也能支持discovery，但discovery机制比较低级，用起来很难受，所以说真正的原生时代的监控zabbix已经不适用了，也有人用国人开发的监控系统，其实有些做的也很好，只不过国人开发的这种监控系统，如果是开源的话，他们多数都是个人在公司为了做出业绩来，为了使得自己的kpi更好看，那做的人一旦跳槽以后，这个系统可能就不再维护，或者他的继任者就未必会，比如像著名的open falcon，创始人已经跳槽，就不再适用。
我们接下来以 Prometheus 为例，来介绍系统的采集，存储，展示，报警等功能的实现，同时介绍如何把他对接到现在比较主流的编排系统中，来去解控系统。
其实 Prometheus 的创始者原来是 google 公司的员工，但他后来到 soundcloud 公司中去模仿这个系统，brog 系统是模仿得 K8S，而 Prometheus 是模仿的 borg 系统，所以知道他更加适用于coopernatice的。Prometheus 已经研发很多年，但是在15年才正式发布，属于 CNCF，现在已经是2.x版本。
Prometeus必须有很多特点才使得它那么流行，第一他的 metric 有独创的指标格式，称之为 Prometheus 格式，这个格式现在流行到只要创造出来的应用都会内置一个仪表盘，保留出来的格式都是 Prometheus 的格式或是它的兼容格式，而且更重要的是 metric 支持多维度的标签，而且每个独立的标签组合都代表一个独立的时间序列，我们称之为样本数据。
他的模式定义非常的随意，在一个独立的字段上定义一个标签，他的标签就会自动生成时间序列。但是越自由，通常需要自己做到的管理也就越多。第三可以对数据进行聚合、切割、切片、内置等各种高级操作机制。
另外支持双精度浮点型数据，因此所表达的数据类型更加强大。但是 prometheus 也有缺点，比如他所存储的样本数据都是双精度浮点型数据，这就意味着他不可以存储文本，所以没办法去采集日志存储下来。以上就是对 Prometheus 的简单的特点的介绍。
六、Prometheus 的工作系统
Prometheus 是怎样工作的?
首先，Prometheus 是一款时序(time series)数据库;但它的功能却并非止步于 TSDB， 而是一款设计用于进行目标（Target) 监控的关键组件；就是指它带有采集器，而这个采集器具有高效灵活的配置能力，因而从某种意义上来讲，监控能力才是根本，而时序数据库是附加的，但是不能存储长时间的数据。
第二，结合生态系统内的其它组件，例如 Pushgateway、 Altermanager 和 Grafana 等，可构成一个完整的 IT 监控系统。因为 Prometheus 自己内置了存储器，又自己内置的存储能力，监控系统的数据采集模型有两种，第一种叫做 pull，第二种就叫 push，无论是 pull 还是 push 都是针对监控系统来讲的，pull 就是自己拿来数据模式，push 就是由监控端自己推给 Prometheus service，这两种数据采集模式各有优劣，但是 Prometheus 只支持 pull 模型，但是有些情况下 Prometheus 没有办法去主动拉取，只能借助一些软件，叫 pushgateway，被监控端将数据推给 pushgateway，然后 Prometheus 就可以去 pushgateway 上去拉取数据。
Prometheus 有内置的 tsdb，但是只能存储短期数据，如果要长期存储还需要拉取远程系统 database 来实现。Prometheus 有一个非常强大的内建引擎，可以提供 SQL 式的查询，叫 Prometheus查询语言，所以我们要学 Prometheus 最关键的就是学习 QL，这就是 Prometheus 最基本的组织构建。
当然还有最重要的是 Prometheus只能查询，不能报警，所以还得再对接一个组件叫做 alertmanager，它不仅能给 Prometheus 报警，而且也可以给其他系统报警，属于通用。所以 alertmanager 对接 promql，当触发时使用它进行报警，给用户发通知，Prometheus 只是产生告警信息，而真正发告警的却要借助于其他。
也有很多应用程序并不带有内置的仪表盘（内建了测量系统，让 Prometheus 可以直接去拿走），因此对这些监控应该安装代理，让这些的代理去抓取数据，转换成 Prometheus 可以兼容的程序，我们把这些对应的应用程序的指标暴露器，我们称之为 exporer，市面上很多应用程序都是这样的没有自带的仪表盘，所以要各自安装指标抓取代理器。
Prometheus 提供了很多指标暴露器，同时还有很多第三方的暴露器，如果都没有，你也可以自己开发，开发并不难。
