2.Prometheus 监控技术与实践 --- Prometheus基本概念及部署

Posted 2021-08-30 enlyhua

2.1　Prometheus架构 
	关键工作流程可以总结如下：
		1.Prometheus 服务器周期性的或者在设定的时间段内，可以通过下面的方式获取内容。
			a) 从配置好的job或者exporter 中拉取 metric
			b) 接收从 Pushgateway 推送过来的 metric
			c) 从其他的 Prometheus 服务器中拉取 metric
		2.Prometheus 服务器获取到的数据存储在本地后(也可以选择远端存储)，通过一定规则对数据进行清理和整理，并且把结果存储到新的时间序列中。
		3.Prometheus 服务器定时查询已经定义好的规则，若发现满足定义的触发条件，便将alert信息推送至已经配置好的 Altermanager。
		4.Alertmanager 收到 alert 信息后，根据配置文件对接收到的alert信息进行处理(聚合，去重，降噪)，然后将它们转化为网页，电子邮件等方式发出
		告警。
		5.最后通过 PromQL或者其他API可视化的展示收集的数据，例如自带的 Prometheus Web UI，Grafana 可视化收集查询数据等。

	Prometheus 在记录纯数据时间序列方面表现的非常优秀。它既适用于对服务器硬件各项指标的监控，也适用于对高度动态的面向服务架构的监控。在当下比较火的
微服务生态圈中，它对多维度数据收集和查询的支持比较具有特殊的优势。
	
	Prometheus 的基本原理是通过http协议周期性获取被监控组件的状态信息，任意组件只要提供http接口就可以接入到监控系统中，不需要如sdk的集成过程，这就
使得 Prometheus 可以更好的适应虚拟化，如vm或Docker容器的环境集成。当使用者监控的服务出现故障时，它可以快速的定位和诊断问题。每个Prometheus服务器都
是独立的，不依赖于网络存储或其他远程服务。当基础架构的其他部分损坏时，可以快速恢复，并且不需要设置大量的基础依赖架构。
	
	与此同时，Prometheus 也有不适用的应用场景，例如，使用者要求统计数据 100% 精确时，那么它不那么适用，因为它收集的数据还是有可能不够详细和完整的，例如
精准实时计费的服务平台应用环境就不适用。

2.2　Prometheus快速部署 
	2.2.1　使用二进制文件快速部署 
	2.2.2　使用Docker快速安装 
		docker pull prom/prometheus
		docker run --name prometheus -o 9090:9090 prom/prometheus

	2.2.3　Prometheus Web UI 
		http://localhost:9090

2.3　Prometheus相关概念 
	2.3.1　数据模型 
			prometheus 将所有数据存储为 时间序列数据，每个时间序列数据都具有带时间戳的数据流，数据流都由其指标(metric)名称和一组
		键值对(也称为标签label)唯一标识，即不同的标签代表不同的时间序列。我们可以基于这些标签很容易的对监控数据进行聚合，过滤和整理。
		除了存储的时间序列，prometheus 还可以作为查询结果，产生临时的派生时间序列。

		1.metric
			metric 即指标，指定监控目标系统测量特征，可以理解为定义了某个监控指标类型名称。指标是随着时间将数据点链接在一起的标识符，是 Prometheus
		的核心概念之一。Prometheus 会将指标存储在其时间序列数据库中，可以对它们进行查询操作，以了解被监控目标随时间的变化情况。当有多个服务公开相同的
		指标时，为了对其进行区分，需要添加Label内容。一个指标由以下几个字段组成：
			1.指标名称
			2.任意数量的标签，当然也可以是0个，表示为键值数组
			3.当前指标值
			4.可选的指标标准时间戳

		2.label
			label 即标签，支持 Prometheus 的维度数据模型，是一个关键部分。相同监控指标名称的任何给定标签组合，都会标识该指标的特定维度实例化，基于这些
		维度，Prometheus 可以使用查询语言对数据进行过滤和聚合。更改任何标签值，包括删除和添加，都将创建一个新的时间序列。

		3.sample
			sample 即样本，按照某个时序以时间维度采集的数据，有序的样本形成了实际的时间序列数据列表，每个样本包括2方面内容：
				1.一个float64类型值
				2.毫秒级精度的时间戳

			对于没有按照顺序收集的样本，Prometheus 会将其丢弃。

		4.notation
			notation 即符号，Prometheus 时序格式和 OpenTSDB 类似，是用符号表示时间序列的。在指定一个指标和一个或一组标签时，时序序列通常使用以下
		格式标识：
			<metric name>{<label name>=<label value>, ...}

			监控指标名称(metric name)用来说明被监控样本怎么称呼，标签反映的是当前样本的特征维度。

	2.3.2　Metric的四种类型 
		Prometheus 客户端提供了四种核心指标类型。目前，它们仅在客户端库(以支持针对特定类型的使用而定制的API)和wire协议中有所区别，Prometheus在服务端
	还没有充分使用这些信息。

		1.Counter
			Counter 是最常用的指标类型，是一个严格的另加指标，有如下特点：
				1.其值只能从0开始，不会减少，可以理解为一个计数器，一种累加型的指标。
				2.重启进程后，会被重置。

			该指标通常用于跟踪事件的数量和大小，可以用它来记录服务请求次数，任务完成数，错误发生次数。常用的场景有接口请求次数，操作重试次数和消息队列数量
		等。对于命名为 Counter 类指标的最佳做法是使用 _total 后缀。

			在实际应用场景中，大部分指标为 Counter 类型，因为该类型不会在两次采集间隔中丢失信息。

		2.Gauge
			有些数值可能会随着时间的推移而上下浮动，这时可以使用Gauge类型的指标来跟踪此数据，Gauge 类型的指标是一种常规的指标，反映系统当前状态的快照，
		是一个对瞬时测量，特点如下：
			1.测量值是一个瞬时的数据，其值可以任意增加或减少
			2.重启进程后，会被重置

			Gauge 类指标通常可以用来记录cpu使用情况，内存使用情况，磁盘当前和已经使用的空间容量，网络使用变化，温度变化，业务类游戏的在线人数统计和
		订单数量统计等等。

			Gauge 类型指标适合记录那些无规律变化的数据，而且两次采样之间可能会丢失某些变化的数值，当然随着时间周期的粒度变大，丢失关键变化数值的情况
		也会增多。

		3.Histogram
			Histogram即直方图，形状与柱状图相似，用于表示在一段时间范围内对数据进行采样，对指定区间以及总数进行分组统计。典型的应用有请求连续时间，响应
		时间大小等等。在 Prometheus 系统中的查询语言中，它有三种作用：
			1.对每个采样点进行统计，对应到各个分类值中及bucket(称为桶)
			2.对每个采样点知累积和(sum)
			3.对采样点的次数累积和(count)

			关于 Histogram 类型，使用的查询会对服务器的cpu有一定的消耗，最直观的反应就是查询结果的返回耗时情况。需要记住，每个独特的标签组合都被视为
		一个单独的时间序列，因此，通常的做法是尽量保持bucket的数量较小，以及直方图上的其他标签数量较少。

		4.Summary
			Summary 即概率图，类似于 Histogram，常用语跟踪与时间相关的数据。典型的应用包括请求持续时间，响应大小等。Summary 同样提供样本的count
		和sum功能；还提供 quantiles 功能，可以按百分比划分跟踪结果。

	2.3.3　Jobs 和 Instances 
		在 Prometheus 中，任何被采集的目标，即每一个暴露监控样本数据的http服务都称为一个实例(Instance)，通常对应于单个进程。而具有相同采集目的的
	实例集合(比如可伸缩或者可靠性而复制的流程)称为作业(Job)。

		Prometheus 在采集目标数据的同时，会自动在时序的基础上附加如下标签，用于识别被采集的目标：
			1.job : 配置目标所属的job名称
			2.instance : 被采样目标url中的 <host>:<port> 部分

2.4　Prometheus核心组件 
	1.Prometheus 服务器
		主要用于收集每个目标数据，并存储为时间序列数据，对外可提供数据查询支持和告警规则配置管理。

		Prometheus 服务器可以对监控目标进行静态配置管理或动态配置管理，它将监控采集到的数据按照时间序列存储在本地磁盘的时序数据库中(也支持远程存储)，
	自身提供了自定义的PromQL 语言，可以对数据进行查询和分析。

	2.Client Library
		Client Library 是用于检测应用程序代码的客户端库。在监控服务之前，需要向客户端库代码添加检测，从而实现了 Prometheus 中的 metric 的类型。

		客户端库负责所有细节，如线程安全和生产 Prometheus 文本表示格式以响应http请求。由于基于指标的监控不跟踪单个事件，客户端库内存使用不会随着
	事件的增加而增加。相反，内存与你拥有的监控指标的数量相关。

	3.Exporter
		用于输出被监控组件信息的http接口统称为 Exporter(导出器)。

		Exporter 是 Prometheus 系统很重要的组成部分。在实际中收集监控样本数据都是由 Exporter 完成的。Exporter 可以是一个独立运行的进程，对外
	提供一个用于获取监控数据的http服务。Prometheus server 只需要定时通过这些 Exporter 提供的http服务获取监控数据即可。可以理解为类似传统意义上的被
	监控目标的agent，区别在于 Exporter 不会主动推送监控数据到 Prometheus server。

	4.Pushgateway
		Pushgateway 是指用于支持短期临时或批量计划任务工作的数据汇聚节点。主要用于短期的job，此类job存在的时间较短，可能在 Prometheus 来pull之前
	就自行消失了。所以针对这类job，设计成可以直接向 Pushgateway 推送 metric，这样 Prometheus 服务端便可以定时去 Pushgateway 拉取 metric。

		另外当某应用系统的网络环境中，Prometheus server 和 Exporter 不能直接进行通信，我们可以使用 Pushgateway 来进行中转。

	5.Altermanager
		Altermanager 主要用于处理 Prometheus 服务器端发送的 alerts 信息，对其去重数据，分组并路由到正确的接收方式，发出告警。