运维监控之Prometheus入门简介篇

一、什么是Prometheus

Prometheus（普罗米修斯）是一套开源的监控&报警&时间序列数据库的组合，它将所有信息都存储为时间序列数据；因此实现一种Profiling监控方式，实时分析系统运行的状态、执行时间、调用次数等，以找到系统的热点，为性能优化提供依据。

Prometheus基本原理是通过HTTP协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程。这样做非常适合虚拟化环境比如VM或者Docker 。

Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一。输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux 系统信息 (包括磁盘、内存、CPU、网络等等)，具体支持的源看：

https://github.com/prometheus。

二、Prometheus的特点

• 多维度数据模型。
• 灵活的查询语言。
• 不依赖分布式存储，单个服务器节点是自主的。
• 通过基于HTTP的pull方式采集时序数据。
• 可以通过中间网关进行时序列数据推送。
• 通过服务发现或者静态配置来发现目标服务对象。
• 支持多种多样的图表和界面展示，比如Grafana等。

三、Prometheus的数据模型

Prometheus从根本上所有的存储都是按时间序列去实现的，相同的metrics(指标名称) 和label(一个或多个标签) 组成一条时间序列，不同的label表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。

metrics name&label指标名称和标签。每条时间序列是由唯一的”指标名称”和一组”标签（key=value）”的形式组成。

指标名称：一般是给监测对像起一名字，例如http_requests_total这样，它有一些命名规则，可以包字母数字之类的的。通常是以应用名称开头监测对像数值类型单位这样。例如：push_total、user_login_mysql_duration_seconds、app_memory_usage_bytes。

标签：就是对一条时间序列不同维度的识别了，例如一个http请求用的是POST还是GET，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了：http_requests_total{method=”POST”,endpoint=”/api/tracks”}。

记住，针对http_request_stotal这个metrics name无论是增加标签还是删除标签都会形成一条新的时间序列。查询语句就可以跟据上面标签的组合来查询聚合结果了。如果以传统数据库的理解来看这条语句，则可以考虑http_requests_total是表名，标签是字段，而timestamp是主键，还有一个float64字段是值了。（Prometheus里面所有值都是按float64存储）。

四、Prometheus四种数据类型

Counter:只增不减的计数器

Counter用于累计值，计数器可以用于记录只会增加不会减少的指标类型，例如记录请求次数、任务完成数、错误发生次数。一直增加，不会减少。重启进程后，会被重置。对于Counter类型的指标，只包含一个inc()方法，用于计数器+1。一般而言，Counter类型的metrics指标在命名中我们使用total结束，如httprequests_total。

例子：

http_response_total{method=”GET”,endpoint=”/api/tracks”} 100，10秒后抓取http_response_total{method=”GET”,endpoint=”/api/tracks”} 100。

Gauge: 可增可减的仪表盘

对于这类可增可减的指标，可以用于反应应用的当前状态。例如在监控主机时，主机当前空闲的内存大小，可用内存大小。或者容器当前的cpu使用率,内存使用率。重启进程后，会被重置。对于Gauge指标的对象则包含两个主要的方法inc()以及dec(),用户添加或者减少计数。

例子：

memory_usage_bytes{host=”master-01″} 100 < 抓取值、memory_usage_bytes{host=”master-01″} 30、memory_usage_bytes{host=”master-01″} 50、memory_usage_bytes{host=”master-01″} 80 < 抓取值。

Histogram：自带buckets区间用于统计分布统计图

主要用于在指定分布范围内(Buckets)记录大小或者事件发生的次数。Histogram（直方图）可以理解为柱状图的意思，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供count和sum全部值的功能。

例子：

{小于10=5次，小于20=1次，小于30=2次}，count=7次，sum=7次的求和值。

Summary: 客户端定义的数据分布统计图

Summary：Summary和Histogram十分相似，常用于跟踪事件发生的规模，都可以统计事件发生的次数或者大小，以及其分布情况。例如：请求耗时、响应大小。Summary和Histogram都提供了对于事件的计数count以及值的汇总sum。因此使用count,和sum时间序列可以计算出相同的内容，例如http每秒的平均响应时间：rate(base_name_sum[5m]) / rate(base_name_count[5m])。同时Summary和Histogram都可以计算和统计样本的分布情况，比如中位数，9分位数等等。其中 0.0<= 分位数Quantiles <= 1.0。不同在于Histogram可以通过histogram_quantile函数在服务器端计算分位数。而Sumamry的分位数则是直接在客户端进行定义。因此对于分位数的计算。Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。相对的对于客户端而言Histogram消耗的资源更少。

五、Prometheus适用的场景

Prometheus在记录纯数字时间序列方面表现非常好。它既适用于面向服务器等硬件指标的监控，也适用于高动态的面向服务架构的监控。对于现在流行的微服务，Prometheus的多维度数据收集和数据筛选查询语言也是非常的强大。Prometheus是为服务的可靠性而设计的，当服务出现故障时，它可以使你快速定位和诊断问题。它的搭建过程对硬件和服务没有很强的依赖关系。

六、Prometheus不适用的场景

Prometheus它的价值在于可靠性，甚至在很恶劣的环境下，你都可以随时访问它和查看系统服务各种指标的统计信息。如果你对统计数据需要100%的精确，它并不适用，例如：它不适用于实时计费系统。