前言
当下开源发展超乎想象，连腾讯，阿里这种大厂都在不断追赶各种开源，享受开源的红利。 开源时代的到来颠覆了传统IT生命周期发展的步伐，自研时代的“重开发”，到开源时代的“重集成”，这种“重集成”的就需要强有力的集成运维支撑。开源软件不像企业开发的商业闭源软件，商业软件一般是自完备的，从功能到安全到性能到监控都能自我掌控，开源软件往往在核心功能外的领域不够完备，往往需要企业自己增强。尤其在监控领域比较缺失，而Prometheus正好弥补这个空间，提供一种灵活方便的监控告警解决方案。
Prometheus vs Zabbix
说到监控，几乎没人没听过Zabbix，Zabbix的成熟度自然非常高，而且配置UI相当强大， 但是Prometheus产生于容器时代，具有云原生和时序数据库的特点， 直接弯道超车，渐有取代Zabbix之势。
看下面网上整理的两者的区别：
Zabbix
Zabbix核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。所以从Zabbix 4.2版本后开始支持TimescaleDB时序数据库，不过目前成熟度还不高。
Prometheus
Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。
Prometheus Server负责定时在目标上抓取metrics（指标）数据并保存到本地存储里面。Prometheus采用了一种Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。Prometheus自研一套高性能的tsdb时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。
Prometheus的本地存储为官方自研高性能时序数据库。
Prometheus的远端存储可以对接OpenTSDB、InfluxDB、Elasticsearch、M3db、Kafka等，其中M3db是目前非常受欢迎的后端存储，适用于大量历史监控数据的存储和查询，。
Exporter接口
Prometheus通过exporter机制将监控metric数据收集到服务端，exporter是一个http（不支持https）服务端口，由Prometheus server定时拉取，如下示意：
对http返回格式的要求见官方文档。
Exporter格式
metric_name ["{" label_name "=" `"` label_value `"` { "," label_name "=" `"` label_value `"` } [ "," ] "}"] value [ timestamp ]
metric_name:指标的名称
label：指标维度的标签，可以由多个
value：指标具体的值
Exporter示例
# HELP http_requests_total The total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="post",code="200"} 1027 1395066363000
http_requests_total{method="post",code="400"} 3 1395066363000
# Escaping in label values:
msdos_file_access_time_seconds{path="C:\\DIR\\FILE.TXT",error="Cannot find file:\n\"FILE.TXT\""} 1.458255915e9
# Minimalistic line:
metric_without_timestamp_and_labels 12.47
# A weird metric from before the epoch:
something_weird{problem="division by zero"} +Inf -3982045
# A histogram, which has a pretty complex representation in the text format:
# HELP http_request_duration_seconds A histogram of the request duration.
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="0.2"} 100392
http_request_duration_seconds_bucket{le="0.5"} 129389
http_request_duration_seconds_bucket{le="1"} 133988
http_request_duration_seconds_bucket{le="+Inf"} 144320
http_request_duration_seconds_sum 53423
http_request_duration_seconds_count 144320
# Finally a summary, which has a complex representation, too:
# HELP rpc_duration_seconds A summary of the RPC duration in seconds.
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.01"} 3102
rpc_duration_seconds{quantile="0.05"} 3272
rpc_duration_seconds{quantile="0.5"} 4773
rpc_duration_seconds{quantile="0.9"} 9001
rpc_duration_seconds{quantile="0.99"} 76656
rpc_duration_seconds_sum 1.7560473e+07
rpc_duration_seconds_count 2693
value：指标具体的值
四种指标
Counter：只增不减的累加指标
Counter就是一个计数器，表示一种累积型指标，该指标只能单调递增或在重新启动时重置为零，例如，您可以使用计数器来表示所服务的请求数，已完成的任务或错误。
Gauge：可增可减的测量指标
Gauge是最简单的度量类型，只有一个简单的返回值，可增可减，也可以set为指定的值。所以Gauge通常用于反映当前状态，比如当前温度或当前内存使用情况；当然也可以用于“可增加可减少”的计数指标。
Histogram：自带buckets区间用于统计分布的直方图
Histogram主要用于在设定的分布范围内(Buckets)记录大小或者次数。
例如http请求响应时间：0-100ms、100-200ms、200-300ms、>300ms 的分布情况，Histogram会自动创建3个指标，分别为：
事件发送的总次数<basename>_count：比如当前一共发生了2次http请求
所有事件产生值的大小的总和<basename>_sum：比如发生的2次http请求总的响应时间为150ms
事件产生的值分布在bucket中的次数<basename>_bucket{le="上限"}：比如响应时间0-100ms的请求1次，100-200ms的请求1次，其他的0次
Summary：数据分布统计图
Summary和Histogram类似，都可以统计事件发生的次数或者大小，以及其分布情况。
Summary和Histogram都提供了对于事件的计数_count以及值的汇总_sum，因此使用_count,和_sum时间序列可以计算出相同的内容。
同时Summary和Histogram都可以计算和统计样本的分布情况，比如中位数，n分位数等等。不同在于Histogram可以通过histogram_quantile函数在服务器端计算分位数。 而Sumamry的分位数则是直接在客户端进行定义。因此对于分位数的计算。 Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。相对的对于客户端而言Histogram消耗的资源更少。
Exporter选型
Prometheus官方本身提供了很多专业的Exporter，同时各个厂家为Prometheus开发的Exporter也非常多，选择这些现成的Exporter自然是首选。可以打开官方网站看大概由150多种Exporter，包含如下领域：
数据库
操作系统
持续集成平台
消息中间件
分布式存储系统
Http服务器
日志系统
几乎涵盖了目前流行的大部分系统，足以见得Prometheus在监控界的地位。每一个Exporter启动侯都是一个http服务，可以已进程的形式启动，也可以以Docker容器的方式启动。
Exporter开发
Exporter SDK
对于开源的平台，我们一般能从官方列表中找到对应的Exporter，继续我们的拿来主义就行，稍加集成就可以顺利接入。对于闭源或者自研的系统，提供一个Prometheus Exporter形式监控接口则会提升软件本身的监控能力。官方提供了四种语言（Go/Java/Python/Rubby）的正式客户端库用来开发一个集成http server的Exporter库。非正式的也有一些其它语言的库。
Exporter库基本实现了上图的功能，提供了一个HttpServer，实现GET /metrics接口，这个接口关联到一个Handle访问CollectorRegistry获取所有的指标信息，序列化为Text文本格式返回。其中ColloecorRetistry需要提前注册需要获取的各种指标对象。
由于Exporter本身提供了一个REST服务器，所以不会特别轻量，会带来一些线程的消耗，如果在一个机器上启动过多Exporter实例则需要注意，想办法减少Exporter实例的数量。
自研的Exporter的优势是可以在代码中埋点，精确代码中的监控业务数据。同时写好一个Exporter还有一些原则，可以参考网页。比如要统计http请求的次数，某一种错误产生的次数，当前active连接的个数等等。
扩展Node Exporter
Node Exporter是Prometheus官方发布的用来监控主机资源信息的Exporter，这个Exporter本身提供了一个Textfile Collector对外接口，可以用来把一些可以脚本化的监控数据带上去，通过--collector.textfile.directory 参数指定本地文本收集路径:
/opt/exporter/node_exporter/node_exporter --collector.textfile.directory=/opt/exporter/node_exporter/key
自研Exporter
除了以上2种方式，也可以按照规范自己开发Exporter服务，实现一个返回文本指标格式的HTTP Server，
比如一个用Python Flask写的Exporter。
Prometheus Roadmap
l 服务器端支持指标元数据 目前指标的数据类型和其它元数据只在客户端使用，没有在服务器端持久化和使用。后续计划在服务器端使用这些元数据，第一步是在内存中聚合这些数据并且通过API对外提供。
l 适配OpenMetrics****格式指标
l 回填时间序列 回填需要加载大批量的过期数据，并且从其它监控系统传输旧数据
l 服务端支持SSL****和认证 目前Prometheus服务端，AlertManager和官方Exporter都没有使用SSL加密，并且没有认证机制，需要加入SSL和认证来保证传输安全。
l 支持生态系统 目前Prometheus支持了一些客户端库和exporter，还有好多其它语言需要加入支持。
