认识Prometheus

tlqwanttolearnit

已于 2022-04-05 23:33:31 修改

阅读量1.3k

点赞数 1

分类专栏： # Promethues 自动化运维文章标签： kubernetes

于 2022-03-31 14:08:38 首次发布

本文链接：https://blog.csdn.net/tlqwanttolearnit/article/details/123870646

版权

自动化运维同时被 2 个专栏收录

10 篇文章 4 订阅

订阅专栏

Promethues

1 篇文章 0 订阅

订阅专栏

认识Prometheus

前言

Prometheus（普罗米修斯）是一套开源的监控&报警&时间序列数据库的组合，其基本原理是通过HTTP协议周期性抓取被监控组件的状态，好处是任意组件只要提供HTTP接口就可以接入监控系统，这样做非常适合虚拟化环境比如VM或者Docker。Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一，如今使用Docker、Kubernetes的场景非常多，因此对Prometheus产生了一定的兴趣。

Prometheus提供了一整套监控体系，包括数据的采集、数据存储、报警,、甚至是绘图(不太好用，官方推荐使用 Grafana)

Prometheus简介

主要特点：

一个多维数据模型（时间序列由指标名称定义和设置键/值尺寸）。
通过PromQL实现多维度数据模型的灵活查询。
不依赖分布式存储，单个服务器节点。
时间集合通过HTTP上的PULL模型进行。
灵活的自定义探针（如Exporter等），编写简单方便
通过中间网关支持推送时间。
通过服务发现或静态配置发现目标。

整体架构：

在这里插入图片描述

Prometheus Server: 用于收集和存储时间序列数据。
Client Library: 客户端库，检测应用程序代码，当Prometheus抓取实例的HTTP端点时，客户端库会将所有跟踪的metrics指标的当前状态发送到prometheus server端。
Exporters: prometheus支持多种exporter，通过exporter可以采集metrics数据，然后发送到prometheus server端，所有向promtheus server提供监控数据的程序都可以被称为exporter
Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去重，分组，并路由到相应的接收方，发出报警，常见的接收方式有：电子邮件，微信，钉钉, slack等。
Grafana：监控仪表盘，可视化监控数据
pushgateway: 各个目标主机可上报数据到pushgateway，然后prometheus server统一从pushgateway拉取数据。

Prometheus主要由Prometheus Server、Pushgateway、Job/Exporter、Service Discovery、Alertmanager、Dashboard这6个核心模块构成。Prometheus Server 直接从监控目标中或者间接通过推送网关来拉取监控指标，它在本地存储所有抓取到的样本数据，并对此数据执行一系列规则，以汇总和记录现有数据的新时间序列或生成告警。可以通过 Grafana 或者其他工具来实现监控数据的可视化。

Prometheus和Zabbix简单对比分析

Prometheus和Zabbix作为常用的监控方法，下图是个简单的特点对比分析，在云原生时代的加持下，Prometheus的发展将会更加迅速。

在这里插入图片描述

Prometheus的四种数据类型

metric添加实战链接： https://prometheus.io/docs/concepts/metric_types/

Counter

Counter是计数器类型：

Counter 用于累计值，例如记录请求次数、任务完成数、错误发生次数。
一直增加，不会减少。
重启进程后，会被重置。

# Counter类型示例
http_response_total{method="GET",endpoint="/api/tracks"}  100
http_response_total{method="GET",endpoint="/api/tracks"}  160

Gauge

Gauge是测量器类型：

Gauge是常规数值，例如温度变化、内存使用变化。
可变大，可变小。
重启进程后，会被重置

# Gauge类型示例
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

在大多数情况下人们都倾向于使用某些量化指标的平均值，例如 CPU 的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例：如果大多数 API 请求都维持在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。
为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计延迟在 0~10ms 之间的请求数有多少，而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在，通过 Histogram 和 Summary 类型的监控指标，我们可以快速了解监控样本的分布情况。

Histogram 类型的样本会提供三种指标: bucket sum count。例如：{小于10=5次，小于20=1次，小于30=2次}，count=8次，sum=8次的求和值

# bucket
# http 请求响应时间 <=0.01 秒 的请求次数为0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0

# http 请求响应时间 <=10 秒 的请求次数为 2
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0

# sum
# 请求总的响应时间为 13.107670803000001 秒
io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001

# count 
# 当前一共发生了 2 次 http 请求
io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0

Summary

与 Histogram 类型类似，用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。它也有三种作用：

对于每个采样点进行统计，并形成分位图
统计sum
统计count

例如：count=7次，sum=7次，quantile取值0.95，表示取采样值里面的95%数据

# 从上面的样本中可以得知当前Promtheus Server进行wal_fsync操作的总次数为216次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为0.012352463，9分位数（quantile=0.9）的耗时为0.014458005s
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216

summary和histogram的选择

Summary 结构有频繁的全局锁操作，对高并发程序性能存在一定影响。histogram仅仅是给每个桶做一个原子变量的计数就可以了，而summary要每次执行算法计算出最新的X分位value是多少，算法需要并发保护。会占用客户端的cpu和内存。
不能对Summary产生的quantile值进行aggregation运算（例如sum, avg等）。例如有两个实例同时运行，都对外提供服务，分别统计各自的响应时间。最后分别计算出的0.5-quantile的值为60和80，这时如果简单的求平均(60+80)/2，认为是总体的0.5-quantile值，那么就错了。
summary的百分位是提前在客户端里指定的，在服务端观测指标数据时不能获取未指定的分为数。而histogram则可以通过promql随便指定，虽然计算的不如summary准确，但带来了灵活性。
histogram不能得到精确的分为数，设置的bucket不合理的话，误差会非常大。会消耗服务端的计算资源。
所以对比得到的总结是：

如果需要聚合（aggregate），选择histograms。
如果比较清楚要观测的指标的范围和分布情况，选择histograms。如果需要精确的分为数选择summary。