Prometheus在设计之初的定位就是一款实时监控系统。
本篇是监控系列的第二篇文章，介绍云平台下的监控利器Prometheus，从采集格式，采集方式，数据存储，数据分析和数据告警五个角度展开，希望对您理解Prometheus的设计原理有所帮忙。
指标
每种监控系统都有自己对指标的一套定义和规范,指标的数据格式将直接影响对数据的采集和存储,所以定义指标时需要充分考虑通用性和扩展性。
prometheus 的指标定义
Prometheus的所有监控指标被统一定义为:<metric name>[<label name>=<labal value>,...]
指标名称:用于署名指标的含义,指标名称必须由字面、数值下划线或者冒号组成,其中冒号指标不能用于exporter。
标签:标签可体现指标的维度特征,用于过滤和聚合,它通过标签名和标签值这种键值对的形式,形成多种维度。
Prometheus的指标分类
Prometheus指标分为counter(计数器),Gauge(仪表盘),Histogram(直方图)和Summary(摘要)这四类。
Prometheus的数据样本
Prometheus采集的数据样本都是以时间序列保存的,每个样本都由三部分组成:指标、样本值、时间戳。
表面上再着急忙慌，内心世界也要宁静得如同那最温柔而又深沉的湖泊。这，才是我们面对繁忙快节奏生活的最佳打开方式。
数据采集
和采用Push方式采集监控数据不同，Prometheus采用Pull方式采集监控数据。采用push时，Agent主动上报数据。采用Pull方式时，监控中心拉取Agent的数据。
为了兼容Push方式，Prometheus提供了Pushgateway组件，pushgateway组件接收客户端发送过来的数据，按照job和instance两个层级进行组织，支持数据的追加和删除，并且防止数据丢失,还支持本地支持。
实时性
push方式的实时性相对较好，可以将采集到的数据立即上报到监控中心。
pull方式通常进行周期性采集，采集时间为30s或者更长时间.所以对监控系统的实时性要求比较高,建议采用Push。
状态保持
Push方式通常在采集完成后立即上报，本地不会保存采集数据，agent本身是没有状态的，而master需要维护各种Agent状态。
Pull方式正好相反，Agent本身需要一定的存储能力，master 只需要简单的拉取数据，而且master本身可以做到无状态。
控制能力
采用push方式时,控制方为Agent，Agent上报的数据决定上报的周期和内容。
采用pull方式时,Master更加主动，监控采集的内容和频率。
配置的复杂性
采用Push方式时，通常每个Agent都需要配置Master的地址。
采用Pull方式时，通常通过批量配置或者自动发现来获取所有的采集点.相对简单，并且可以做到和agent充分解耦，agent可以不用感知master的存在。
服务发现
分为静态文件配置和动态发现。静态文件配置一般适用于固定的监控环境、IP地址和统一的服务接口的场景。动态发现适合在云环境下使用。在云环境下，动态伸缩的场景和迅速配置的场景。
prometheus通过动态发现方式获取监控对象。
容器管理系统：kubernetes，marathon。
各种云管平台：EC2，Azure和Openstack。
各种服务发现组件：DNS，Zookeeper和Consul。
prometheus与kubernetes 自动发现的流程
1、需要在Prometheus里配置Kubernetes API的地址和认证凭据,这样Prometheus就可以连接到Kubernetes的API来获取信息.
2、Prometheus的服务发现组件一致监听kubernetes集群的变化,kubernetes的相关操作都是在Prometheus有所体现。
数据采集
Prometheus采用统一的RestfulAPI方式获取数据，具体来说是调用HTTP GET请求或metric数据接口获取监控数据。为了高效采集数据，Prometheus对每个采集点都启动了一个线程去定时采集数据。
Prometheus采用两种更新方式。
1、通过prometheus的reload接口进行配置更新。
2、通过kill -HUP Prometheus的进程ID 动态加载配置，从而更新配置(不建议,因为它需要动态获取ID)。
数据处理
Prometheus支持数据处理,只要包括relabel,replace,keep,drop等操作,提供过滤数据或者修改样本的维度信息等功能，Prometheus会从target中获取所有暴露的数据,但某些数据对Promethues是无用的,如果直接保存这些数据,则不仅浪费空间,还会降低系统的吞吐量.Prometheus提供了keep或者drop机制。
设置keep,则会保留所有匹配标签的数据。
设置drop,则会丢弃匹配标签的数据,从而完成数据过滤。
数据存储
本地存储和远程存储。
数据查询
对于Prometheus数据，我们可以通过HTTP来查询，如果是复杂的数据查询，则还可以使用PromQL进行。
和关系型数据库实现SQL解析一样，Prometheus实现了一套自己的数据库语言解析器，最大的区别是支持查询。
告警
告警产生的告警记录并不会立即发送出，而需要经过一个评估时间，如果在评估时间段内的每个周期都触发了这条告警规则，则会向外发出这条告警。
Prometheus本身并不会对告警进行处理，需要借助另一个组件Alertmanager，Prometheus会配置AlertManager的地址，这样Prometheus发出的告警记录便可以被发送到AlertManager进行处理。
主要功能包括，告警分类，告警抑制和告警静默
告警分组指将多条告警记录合并到一起发送。
告警抑制是指当告警已经发出时，停止发送由此告警触发的其他错误告警。
告警静默指在一个时间段内不会发出重复的告警。
AlertManager主要分为两部分，路由和接收器。
在高可用的架构中，每个Prometheus都会配置多个AlertManager，避免单点故障，具体的流程如下：
Prometheus会通过调用AlertManager提供的告警接口将原始的告警消息发送到AlertManager。
AlertManager的API除了接收告警，还接收静默请求，将其分别保存到各自的provide里。
provider提供了一个订阅接口，这样的dispatcher组件便可以获取告警数据，并对告警进行分组，通过用户预先设置的规则进入告警抑制阶段或静默阶段。
如果通过了上面的告警静默阶段，则进入路由分发阶段，最终发送通知。
为避免告警重复发送，引入了Gossip(一种最终一致性协议)
保证每个alertManager的静默配置是一致的，从而保证每个AlertManager都能静默告警。
告警在每个AlertManager之间同步，通过Gossip告知其他节点已经发出告警，如有相同的告警，则需要去重。
在繁忙的工作与生活之中，用心感觉风的温度，看云在空中怎样飘过，倾听雨声，闻闻叶子的味道，这样的人，才是真正热爱生活的英雄。
