一、介绍
本文介绍Prometheus 监控及在k8s集群中使用node-exporter、prometheus、grafana对集群进行监控。实现原理类似ELK、EFK组合。node-exporter组件负责收集节点上的metrics监控数据，并将数据推送给prometheus, prometheus负责存储这些数据，grafana将这些数据通过网页以图形的形式展现给用户。
1. 在开始之前有必要了解下Prometheus是什么?
Prometheus （中文名：普罗米修斯）是由 SoundCloud 开发的开源监控报警系统和时间序列数据库(TSDB).自2012年起,许多公司及组织已经采用 Prometheus,并且该项目有着非常活跃的开发者和用户社区.现在已经成为一个独立的开源项目。Prometheus 在2016加入 CNCF ( Cloud Native Computing Foundation 云原生计算基金会 ), 作为在 kubernetes 之后的第二个由基金会主持的项目。 Prometheus 的实现参考了Google内部的监控实现，与源自Google的Kubernetes结合起来非常合适。另外相比influxdb的方案，性能更加突出，而且还内置了报警功能。它针对大规模的集群环境设计了拉取式的数据采集方式，只需要在应用里面实现一个metrics接口，然后把这个接口告诉Prometheus就可以完成数据采集了，下图为prometheus的架构图。
promethues是一套开源的系统监控报警框架。Prometheus 所有采集的监控数据均以指标（metric）的形式保存在内置的时间序列数据库当中（TSDB）：属于同一指标名称，同一标签集合的、有时间戳标记的数据流。除了存储的时间序列，Prometheus 还可以根据查询请求产生临时的、衍生的时间序列作为返回结果。包含了以下组件
prometheus server: 主要负责数据采集和存储，提供promQL查询语言支持。prometheus是一个时序数据库，将采集到的监控数据按照时间序列的方式存储到本地磁盘。
Push Gateway: 支持临时性job主动推送指标的中间网关。
PromDash： 使用rails开发的dashboard，用于可视化指标数据。
-
Exporters: 负责监控机器运行状态，提供被监控组件信息的 HTTP 接口被叫做 exporter。
直接采集： exporter内置了prometheus支持，直接向prometheus暴露数据端点。
间接采集：原不支持prometheus。通过prometheus提供的clien library编写的目标监控采集程序。
Altermanager: 从 Prometheus server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对收的接受方式，发出报警。常见的接收方式有：电子邮件，企业微信，钉钉 , webhook
WebUI: Prometheus内置一个简单的Web控制台，可以查询指标，查看配置信息或者Service Discovery等，实际工作中，查看指标或者创建仪表盘通常使用Grafana，Prometheus作为Grafana的数据源；9090提供图形化界面功能。
promethues 的各个组件基本都是用 golang 编写,对编译和部署十分友好.并且没有特殊依赖.基本都是独立工作。
二、基本工作原理
- Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。
- Prometheus server 在本地存储收集到的 metrics，并运行已定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。
- Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。
- 在图形界面中，可视化采集数据。
三、Prometheus 的优势和不足
1. prometheus 的优势
强大的多维度数据模型：
时间序列数据通过 metric 名和键值对来区分。
所有的 metrics 都可以设置任意的多维标签。
数据模型更随意，不需要刻意设置为以点分隔的字符串。
可以对数据模型进行聚合，切割和切片操作。
支持双精度浮点类型，标签可以设为全 unicode。灵活而强大的查询语句（PromQL）：
在同一个查询语句，可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。易于管理：
Prometheus server 是一个单独的二进制文件，可直接在本地工作，不依赖于分布式存储。高效：
平均每个采样点仅占 3.5 bytes，且一个 Prometheus server 可以处理数百万的 metrics。
使用 pull 模式采集时间序列数据，这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
可以通过服务发现或者静态配置去获取监控的 targets。
有多种可视化图形界面。
易于伸缩。
2. prometheus 的不足 有待于改进
不支持集群化 (这个是当前最迫切的需求)
被监控集群过大后 本身性能有一定瓶颈(如果有集群 就可以解决这个问题)
偶尔发生数据丢失(这个问题 在2.0之前 会偶尔发生几次， 2.0之后貌似已经彻底解决 )
中文支持不好 中文资料也很少(这个问题 也是老生常谈了 往往新的 很牛的国外工具都不太支持中文)
注：
由于数据采集可能会有丢失，所以 Prometheus 不适用对采集数据要 100% 准确的情形。但如果用于记录时间序列数据，Prometheus 具有很大的查询优势，此外，Prometheus 适用于微服务的体系架构。
四、prometheus 的基本概念
1. 数据模型
prometheus中存储的数据为时间序列，是由Metric的名字和一系列的标签（键值对）唯一标识的，不同的标签代表不同的时间序列。
样本：实际时间序列，每个序列包括一个float64的值和一个毫秒级的时间戳。（指标+时间戳+样本值）
metric名字： 具有语义，表示功能：例如：http_requeststotal, 表示 http 请求的总数。其中，metric 名字由 ASCII 字符，数字，下划线，以及冒号组成，且必须满足正则表达式[a-zA-Z:][a-zA-Z0-9_:]*。
标签：使一个时间序列有不同未读的识别。例如 http_requeststotal{method="Get"} 表示所有 http 请求中的 Get 请求。当 method="post" 时，则为新的一个 metric。标签中的键由 ASCII 字符，数字，以及下划线组成，且必须满足正则表达式[a-zA-Z:][a-zA-Z0-9_:]*。
格式：<metric name>{<label name>=<label value>, …}
例如：http_requests_total{method="POST",endpoint="/api/tracks"}。
2. Metric类型
Prometheus 客户端库主要提供四种主要的 metric 类型：
2.1 Counter（累加性metirc）
一种累加的 metric，典型的应用如：
请求的个数
结束的任务数
出现的错误数
。。。例如：
查询 promhttp_metric_handler_requests_total{code="200",instance="localhost:9090",job="prometheus"}
返回 8，10 秒后再次查询，则返回 14。
2.2 Gauge（可增减性metric）
一种常规的 metric，典型的应用如：
温度
运行的 go routines 的个数
可以任意加减。例如：
go_goroutines{instance="localhost:9090",job="prometheus"}
返回值 147，10 秒后返回 124。注：
routines: go的日常工作？
2.3 Histogram（树状图）
注：
histogram 英[ˈhɪstəɡræm] 美[ˈhɪstəɡræm] 直方图；矩形图可以理解为柱状图，典型的应用如：
请求持续时间
响应大小
可以对观察结果采样，分组及统计。例如：
查询 go_gc_duration_seconds_sum{instance="localhost:9090",job="prometheus"}时
返回结果如下：Histogram metric 返回结果图image.png
2.4 Summary（汇总）
类似于 Histogram，典型的应用如：
请求持续时间
响应大小
提供观测值的 count 和 sum 功能。
提供百分位的功能，即可以按百分比划分跟踪结果。instance 和 jobs
instance:
一个单独 scrape(抓取) 的目标， 一般对应于一个进程。jobs:
一组同种类型的 instances（主要用于保证可扩展性和可靠性），例如：
注：
scrape 英[skreɪp] 美[skreɪp] 刮掉; 削去; 擦坏; 擦伤; 刮坏; 蹭破; (使) 发出刺耳的刮擦声当 scrape 目标时，Prometheus 会自动给这个 scrape 的时间序列附加一些标签以便更好的分别
例如： instance，job。下面以实际的 metric 为例，对上述概念进行说明：
Metrics 示例image.png如图所示，这三个 metric 的名字都一样，他们仅凭 handler 不同而被标识为不同的 metrics。
这类 metrics 只会向上累加，是属于 Counter 类型的 metric，且 metrics 中都含有 instance 和 job 这两个标签。
有疑问加站长微信联系（非本文作者）
