8.Prometheus 监控技术与实践 --- Pushgateway

第8章　Pushgateway 
8.1　概述 
	目前为止 prometheus 都是基于 pull 的，即拉取模式。然后，某些情况下，会出现无法从中获取指标的目标场景。原因如下：
		1.由于网络安全性或连接性，使得无法访问目标资源，也就是说prometheus无法直接去拉取各个目标的监控数据；
		2.目标资源的生命周期太短；
		3.目标资源没有可以抓取的端点；

	鉴于以上，我们需要某种方式将时间序列传递或推送到prometheus服务器。

	Pushgateway 是一个独立的服务组件，可在 http rest api 上接收 prometheus 指标，位于发送指标的应用服务程序和prometheus服务器之间。Pushgateway 接收指标，
然后将其作为目标进行抓取，以便将指标提供给prometheus服务器。显然，Pushgateway 不是聚合器或分布式计数器，而是指标的缓存功能提供者。所以可以将Pushgateway视为代理
服务器。
	
	通常推荐pull模式，而不能盲目的使用 Pushgateway，因为有时候会出现如下几个问题：
		1.当部署通过单个 Pushgateway 监控多个实例时，Pushgateway 既可能会发生单点故障，又可能会出现性能瓶颈；
		2.会丧失 prometheus 通过 up 监控指标检查实例健康情况的功能，此时 prometheus 的pull 状态指标只对应的是单个 Pushgateway 服务；
		3.Pushgateway 会对推送给它的所有监控数据进行持久化，即使被监控服务已经下线销毁了，prometheus 还是会获取到过期的历史监控数据。这样，就需要我们手动清理
		Pushgateway上的过期数据。

	由于 Pushgateway 是用于服务级别的指标缓存，对于机器级别的指标，Node Exporter 的 textfile 收集器通常更适用。Pushgateway 不是一个事件存储，虽然可以使用
prometheus 作为 grafana 注释的数据源，但是必须用一些日志框架来追踪发布之类的事件。也就是说我们应该讲 Pushgateway 重点放在监控短生命周期资源(如作业)或短期监控
无法访问的资源上。这样就需要对被监控服务于 Pushgateway 进行关联集成，定时 Push 数据到 Pushgateway 服务上，同时也就无法直接使用已有社区提供的大量Exporter。

8.2　Pushgateway集成 
	8.2.1　软件下载与部署 
		1.Linux 主机下载
		https://prometheus.io/download/#pushgateway

		./pushgateway

		2.docker 下载
		docker pull prom/pushgateway
		docker run -p 9091:9091 prom/pushgateway

	8.2.2　Pushgateway UP状态 
	vim prometheus.yml
- job_name: push_pushgateway
	honor_labels:true  #避免采集数据本身的job和instance被覆盖
	static_configs:
		- targets: ['192.168.31.137:9091']

8.3　Pushgateway数据管理 
	8.3.1 向Pushgateway发送和查看监控指标 
		//将一个监控指标推送给正在运行的 Pushgateway
		echo "some_job1_online_counter 3" | curl --data-binary @- http://localhost:9091/metrics/job/some_job1

		//查看监控指标
		curl http://localhost:9091/metrics 

		//也可以访问
		http://localhost:9091

		可以看到 instance="" 为空，现在我们使用 url 路径指向监控指标添加一个具有实例名称的标签，操作如下：
		echo "some_job1_online_counter 3" | curl --data-binary @- http://localhost:9091/metrics/job/some_job1/instance/game_server

		通常，Pushgateway 中的数据可以按照job和instance进行分组，这2个参数是必不可少的。以上内容中，由于没有提供类型信息，some_job1_online_counter 类型
	的显示是UNTYPED，即无类型标示，也就是说网关不知道这是一个计数器还是其他监控指标类型。但是我们可以通过在推送中传递 TYPE 和 HELP 语句来向监控指标添加类型描述，
	并向指标组添加更多指标，如下:
cat <<EOF | curl --data-binary @- http://localhost:9091/metrics/job/some_job/instance/game_server
	#TYPE some_metric counter
	some_metric{label="label-1"} 52
	#TYPE another_metric gauge
	#HELP another_metric Just an example.another_metric 2019.113
	EOF

	8.3.2 删除Pushgateway中的监控标准 
		如果我们在启动 Pushgateway 服务时，没有进行持久化选项设置，只要 Pushgateway 不重新启动，监控指标就一直保存在pushgateway中，这样我们就可以使用
	pushgateway API 进行监控指标删除操作了，如下:
	curl -X DELETE localhost:9091/metrics/job/some_job1

	//更细化的删除，仅删除特定实例中的监控指标
	curl -X DELETE localhost:9091/metrics/job/some_job1/instance/game_server

	8.3.3 基于推送的Prometheus监控 
		本节中，我们有多个服务节点，每个节点都托管多个服务。

		与之前的 node_exporter 来采集主机监控指标不同，在 node_exporter 和 pushgateway 之间添加了一个转发器，用来切换数据管道的流向。在这里，
	node_exporter仍然监听特定端口以公开监控指标，但只接受内部请求，这样有助于保护节点免受外部恶意访问。转发器获取监控指标并发送给 pushgateway,prometheus
	从 pushgateway 中获取数据，而不是直接从 node_exporter 中获取数据。