一、环境准备
| k8s集群角色 | IP | 主机名 | 配置 |
| 控制节点 | 192.168.199.131 | master | centos7.9 4核6G |
| 工作节点 | 192.168.199.128 | monitor | centos7.9 4核4G |
目标：
部署 prometheus、grafana、alertmanager，并且配置 prometheus 的动态、静态服务发现，实现对容器、物理节点、service、pod 等资源指标监控，并在 Grafana 的 web 界面展示prometheus 的监控指标，
然后通过配置自定义告警规则，通过 alertmanager 实现 qq、钉钉、微信报警。Promql 语法、prometheus 数据类型。
github:https://github.com/prometheus/prometheus
官网： https://prometheus.io
二、Prometheus概述
2.1 Prometheus介绍？
Prometheus 是一个开源的系统监控和报警系统，现在已经加入到 CNCF 基金会，成为继 k8s 之后第二 个在 CNCF 托管的项目，在 kubernetes 容器管理系统中，通常会搭配 prometheus 进行监控，同时也支持 多种 exporter 采集数据，还支持 pushgateway 进行数据上报，Prometheus 性能足够支撑上万台规模的集 群。
2.2 Prometheus特点
(1) 多维度数据模型
每一个时间序列数据都由 metric 度量指标名称和它的标签 labels 键值对集合唯一确定：
这个 metric 度量指标名称指定监控目标系统的测量特征（如：http_requests_total- 接收 http 请 求的总计数）。labels 开启了 Prometheus 的多维数据模型：对于相同的度量名称，通过不同标签列表的 结合, 会形成特定的度量维度实例。(例如：所有包含度量名称为/api/tracks 的 http 请求，打上 method=POST 的标签，则形成了具体的 http 请求)。这个查询语言在这些度量和标签列表的基础上进行过 滤和聚合。改变任何度量上的任何标签值，则会形成新的时间序列图。
(2)灵活的查询语言（PromQL）
可以对采集的 metrics 指标进行加法，乘法，连接等操作；
(3)可以直接在本地部署，不依赖其他分布式存储；
(4)通过基于 HTTP 的 pull 方式采集时序数据；
(5)可以通过中间网关 pushgateway 的方式把时间序列数据推送到 prometheus server 端；
(6)可通过服务发现或者静态配置来发现目标服务对象（targets）。
(7)有多种可视化图像界面，如 Grafana 等。
(8)高效的存储，每个采样数据占 3.5 bytes 左右，300 万的时间序列，30s 间隔，保留 60 天，消耗 磁盘大概 200G。
(9)做高可用，可以对数据做异地备份，联邦集群，部署多套 prometheus，pushgateway 上报数据
2.2.1 样本
在时间序列中的每一个点称为一个样本（sample），样本由以下三部分组成：
1、指标（metric）：指标名称和描述当前样本特征的 labelsets；
2、时间戳（timestamp）：一个精确到毫秒的时间戳；
3、样本值（value）： 一个 folat64 的浮点型数据表示当前样本的值。
表示方式：
通过如下表达方式表示指定指标名称和指定标签集合的时间序列：
<metric name>{<label name>=<label value>, ...}
例如，指标名称为 api_http_requests_total，标签为 method="POST" 和 handler="/messages" 的时间序列可以表示为：
api_http_requests_total{method="POST", handler="/messages"}
3.Prometheus组件介绍
(1) Prometheus Server: 用于收集和存储时间序列数据。
(2) Client Library: 客户端库，检测应用程序代码，当 Prometheus 抓取实例的 HTTP 端点时，客户 端库会将所有跟踪的 metrics 指标的当前状态发送到 prometheus server 端。
(3) Exporters: prometheus 支持多种 exporter，通过 exporter 可以采集 metrics 数据，然后发送到 prometheus server 端，所有向 promtheus server 提供监控数据的程序都可以被称为 exporter
(4) Alertmanager: 从 Prometheus server 端接收到 alerts 后，会进行去重，分组，并路由到相应 的接收方，发出报警，常见的接收方式有：电子邮件，微信，钉钉, slack 等。
(5) Grafana：监控仪表盘，可视化监控数据
(6) pushgateway: 各个目标主机可上报数据到 pushgateway，然后 prometheus server 统一从 pushgateway 拉取数据
从上图可发现，Prometheus 整个生态圈组成主要包括 prometheus server，Exporter， pushgateway，alertmanager，grafana，Web ui 界面，Prometheus server 由三个部分组成， Retrieval，Storage，PromQL
1.Retrieval 负责在活跃的 target 主机上抓取监控指标数据
2.Storage 存储主要是把采集到的数据存储到磁盘中
3.PromQL 是 Prometheus 提供的查询语言模块。
4.Prometheus工作流程
(1) Prometheus server 可定期从活跃的（up）目标主机上（target）拉取监控指标数据，目标主机的监控数据可通过配置静态 job 或者服务发现的方式被 prometheus server 采集到，这种方式默认的 pull 方式拉取指标；也可通过 pushgateway 把采集的数据上报到 prometheus server 中；还可通过一些组件 自带的 exporter 采集相应组件的数据；
(2) Prometheus server 把采集到的监控指标数据保存到本地磁盘或者数据库；
(3) Prometheus 采集的监控指标数据按时间序列存储，通过配置报警规则，把触发的报警发送到 alertmanager
(4) Alertmanager 通过配置报警接收方，发送报警到邮件，微信或者钉钉等
(5) Prometheus 自带的 web ui 界面提供 PromQL 查询语言，可查询监控数据
(6) .Grafana 可接入 prometheus 数据源，把监控数据以图形化形式展示出
5.Prometheus 和 zabbix 对比分析
6.Prometheus的集中部署模式
6.1 基本高可用模式
基本的 HA 模式只能确保 Promthues 服务的可用性问题，但是不解决 Prometheus Server 之间的数据 一致性问题以及持久化问题(数据丢失后无法恢复)，也无法进行动态的扩展。因此这种部署方式适合监控规模不大，Promthues Server 也不会频繁发生迁移的情况，并且只需要保存短周期监控数据的场景。
6.2 基本高可用+远程存储
在解决了 Promthues 服务可用性的基础上，同时确保了数据的持久化，当 Promthues Server 发生宕机或者数据丢失的情况下，可以快速的恢复。 同时 Promthues Server 可能很好的进行迁移。因此，该方案适用于用户监控规模不大，但是希望能够将监控数据持久化，同时能够确保 Promthues Server 的可迁移性的场景。
6.3 基本HA+远程存储+联邦集群方案
Promthues 的性能瓶颈主要在于大量的采集任务，因此用户需要利用 Prometheus 联邦集群的特性， 将不同类型的采集任务划分到不同的 Promthues 子服务中，从而实现功能分区。
例如一个 Promthues Server 负责采集基础设施相关的监控指标，另外一个 Prometheus Server 负责采集应用监控指标。再有上层 Prometheus Server 实现对数据的汇聚。
7.Prometheus 的四种数据类型
7.1 Counter
Counter 是计数器类型：
1、Counter 用于累计值，例如记录请求次数、任务完成数、错误发生次数。
2、一直增加，不会减少。
3、重启进程后，会被重置。
例如：
http_response_total{method="GET",endpoint="/api/tracks"} 100
http_response_total{method="GET",endpoint="/api/tracks"} 160
Counter 类型数据可以让用户方便的了解事件产生的速率的变化，在 PromQL 内置的相关操作函数可以提供相应的分析，比如以 HTTP 应用请求量来进行说明:
1、通过 rate()函数获取 HTTP 请求量的增长率:rate(http_requests_total[5m])
2、查询当前系统中，访问量前 10 的 HTTP 地址:topk(10, http_requests_total)
7.2 Gauge
Gauge 是测量器类型：
1、Gauge 是常规数值，例如温度变化、内存使用变化。
2、可变大，可变小。
3、重启进程后，会被重置
例如：
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
对于 Gauge 类型的监控指标，通过 PromQL 内置函数 delta() 可以获取样本在一段时间内的变化情况，例如，计算 CPU 温度在两小时内的差异：
dalta(cpu_temp_celsius{host="zeus"}[2h])
还可以通过 PromQL 内置函数 predict_linear() 基于简单线性回归的方式，对样本数据的变化趋势做出预测。
例如，基于 2 小时的样本数据，来预测主机可用磁盘空间在 4 个小时之后的剩余情况：
predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0
7.3 histogram
histogram 是柱状图，在 Prometheus 系统的查询语言中，有三种作用：
1、在一段时间范围内对数据进行采样（通常是请求持续时间或响应大小等），并将其计入可配置的 存储桶（bucket）中. 后续可通过指定区间筛选样本，也可以统计样本总数，最后一般将数据展示为直 方图。
2、对每个采样点值累计和(sum)
3、对采样点的次数累计和(count)
度量指标名称: [basename]_上面三类的作用度量指标名称
1、[basename]_bucket{le="上边界"}, 这个值为小于等于上边界的所有采样点数量
2、[basename]_sum
3、[basename]_count
小结：如果定义一个度量类型为 Histogram，则 Prometheus 会自动生成三个对应的指标
7.3.1 为什需要用 histogram 柱状图？
在大多数情况下人们都倾向于使用某些量化指标的平均值，例如 CPU 的平均使用率、页面的平均响 应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例：如果大多数 API 请求都维持 在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间 落到中位数的情况，而这种现象被称为长尾问题。
为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计 延迟在 0~10ms 之间的请求数有多少，而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在，通过 Histogram 和 Summary 类型的监控指标，我们可以快速了解监控样本的分布情况。
Histogram 类型的样本会提供三种指标（假设指标名称为 ）：
样本的值分布在 bucket 中的数量，命名为 _bucket{le="<上边界>"}。解释的更通俗易 懂一点，这个值表示指标值小于等于上边界的所有样本数量。
(1)、在总共 2 次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为 0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.005",} 0.0
(2)、在总共 2 次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为 0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200 ",le="0.01",} 0.0
(3)、在总共 2 次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为 0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200 ",le="0.025",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.05",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.075",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.1",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.25",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.5",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="0.75",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="1.0",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="2.5",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="5.0",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="7.5",} 2.0
(4)、在总共 2 次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="10.0",} 2.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code= "200",le="+Inf",} 2.0
所有样本值的大小总和，命名为 _sum。
(5)、实际含义： 发生的 2 次 http 请求总的响应时间为 13.107670803000001 秒
io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="20 0",} 13.107670803000001
样本总数，命名为 _count。值和 _bucket{le="+Inf"} 相同。
(6)、实际含义： 当前一共发生了 2 次 http 请求
io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code=" 200",} 2.0
注意：
bucket 可以理解为是对数据指标值域的一个划分，划分的依据应该基于数据值的分布。注意后面的 采样点是包含前面的采样点的，假设 xxx_bucket{...,le="0.01"} 的值为 10，而xxx_bucket{...,le="0.05"} 的值为 30，那么意味着这 30 个采样点中，有 10 个是小于 0.01s 的，其 余 20 个采样点的响应时间是介于 0.01s 和 0.05s 之间的。
可以通过 histogram_quantile() 函数来计算 Histogram 类型样本的分位数。分位数可能不太好理 解，你可以理解为分割数据的点。我举个例子，假设样本的 9 分位数（quantile=0.9）的值为 x，即表 示小于 x 的采样值的数量占总体采样值的 90%。Histogram 还可以用来计算应用性能指标值（Apdex score）。
7.4 summary
与 Histogram 类型类似，用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小 等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。它也有三种 作用：
1、对于每个采样点进行统计，并形成分位图。（如：正态分布一样，统计低于 60 分不及格的同 学比例，统计低于 80 分的同学比例，统计低于 95 分的同学比例）
2、统计班上所有同学的总成绩(sum)
3、统计班上同学的考试总人数(count)
带有度量指标的[basename]的 summary 在抓取时间序列数据有如命名。
1、观察时间的φ-quantiles (0 ≤ φ ≤ 1), 显示为[basename]{分位数="[φ]"}
2、[basename]_sum， 是指所有观察值的总和
3、[basename]_count, 是指已观察到的事件计数值
样本值的分位数分布情况，命名为 {quantile="<φ>"}。
1、含义：这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983s
io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantil e="0.5",} 3.052404983
2、含义：这 12 次 http 请求中有 90% 的请求响应时间是 8.003261666s
io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantil e="0.9",} 8.003261666
所有样本值的大小总和，命名为 _sum。
1、含义：这 12 次 http 请求的总响应时间为 51.029495508s
io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508
样本总数，命名为 _count。
1、含义：当前一共发生了 12 次 http 请求
io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0
现在可以总结一下 Histogram 与 Summary 的异同： 1.它们都包含了 <basename>_sum 和 <basename>_count 指标 2.Histogram 需要通过 <basename>_bucket 来计算分位数，而 Summary 则直接存储了分位数的值。 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 从上面的样本中可以得知当前 Promtheus Server 进行 wal_fsync 操作的总次数为 216 次，耗时2.888716127000002s。其中中位数（quantile=0.5）的耗时为 0.012352463，9 分位数（quantile=0.9）
的耗时为 0.014458005s。
8.Prometheus能监控什么？
• Databases
• Hardware related
• Messaging systems
• Storage
• HTTP
• APIs
• Logging
• Other monitoring systems
• Miscellaneous
• Software exposing Prometheus metrics
# 1.databases数据库
• Aerospike exporter
• ClickHouse exporter
• Consul exporter (official)
• Couchbase exporter
• CouchDB exporter
• ElasticSearch exporter
• EventStore exporter
• Memcached exporter (official)
• MongoDB exporter
• MSSQL server exporter
• MySQL server exporter (official)
• OpenTSDB Exporter
• Oracle DB Exporter
• PgBouncer exporter
• PostgreSQL exporter
• ProxySQL exporter
• RavenDB exporter
• Redis exporter
• RethinkDB exporter
• SQL exporter
• Tarantool metric library
• Twemproxy
# 2.Hardware Related 硬件设备相关
• apcupsd exporter
• Collins exporter
• IBM Z HMC exporter
• IoT Edison exporter
• IPMI exporter
• knxd exporter
• Netgear Cable Modem Exporter
• Node/system metrics exporter (official)
• NVIDIA GPU exporter
• ProSAFE exporter
• Ubiquiti UniFi exporter
# 3.Messaging systems-消息服务
• Beanstalkd exporter
• Gearman exporter
• Kafka exporter
• NATS exporter
• NSQ exporter
• Mirth Connect exporter
• MQTT blackbox exporter
• RabbitMQ exporter
• RabbitMQ Management Plugin exporter
# 4.Storage-存储
• Ceph exporter
• Ceph RADOSGW exporter
• Gluster exporter
• Hadoop HDFS FSImage exporter
• Lustre exporter
• ScaleIO exporter
# 5.http-网站服务
• Apache exporter
• HAProxy exporter (official)
• Nginx metric library
• Nginx VTS exporter
• Passenger exporter
• Squid exporter
• Tinyproxy exporter
• Varnish exporter
• WebDriver exporter
# 6.API
• AWS ECS exporter
• AWS Health exporter
• AWS SQS exporter
• Cloudflare exporter
• DigitalOcean exporter
• Docker Cloud exporter
• Docker Hub exporter
• GitHub exporter
• InstaClustr exporter
• Mozilla Observatory exporter
• OpenWeatherMap exporter
• Pagespeed exporter
• Rancher exporter
• Speedtest exporter
# 7.Logging 日志
• Fluentd exporter
• Google's mtail log data extractor
• Grok exporter
# 8.Other monitoring systems
• Akamai Cloudmonitor exporter
• Alibaba Cloudmonitor exporter
• AWS CloudWatch exporter (official)
• Cloud Foundry Firehose exporter
• Collectd exporter (official)
• Google Stackdriver exporter
• Graphite exporter (official)
• Heka dashboard exporter
• Heka exporter
• InfluxDB exporter (official)
• JavaMelody exporter
• JMX exporter (official)
• Munin exporter
• Nagios / Naemon exporter
• New Relic exporter
• NRPE exporter
• Osquery exporter
• OTC CloudEye exporter
• Pingdom exporter
• scollector exporter
• Sensu exporter
• SNMP exporter (official)
• StatsD exporter (official)
# 9.Miscellaneous-其他
• ACT Fibernet Exporter
• Bamboo exporter
• BIG-IP exporter
• BIND exporter
• Bitbucket exporter
• Blackbox exporter (official)
• BOSH exporter
• cAdvisor 收集容器日志
• Cachet exporter
• ccache exporter
• Confluence exporter
• Dovecot exporter
• eBPF exporter
• Ethereum Client exporter
• Jenkins exporter
• JIRA exporter
• Kannel exporter
• Kemp LoadBalancer exporter
• Kibana Exporter
• Meteor JS web framework exporter
• Minecraft exporter module
• PHP-FPM exporter
• PowerDNS exporter
• Presto exporter
• Process exporter
• rTorrent exporter
• SABnzbd exporter
• Script exporter
• Shield exporter
• SMTP/Maildir MDA blackbox prober
• SoftEther exporter
• Transmission exporter
• Unbound exporter
• Xen exporter
# 10.Software exposing Prometheus metrics-Prometheus 软件/度量指标
• App Connect Enterprise
• Ballerina
• Ceph
• Collectd
• Concourse
• CRG Roller Derby Scoreboard (direct)
• Docker Daemon
• Doorman (direct)
• Etcd (direct)
• Flink
• FreeBSD Kernel
• Grafana
• JavaMelody
• Kubernetes (direct)
• Linkerd
9.Prometheus对kubernetes的监控
对于 Kubernetes 而言，我们可以把当中所有的资源分为几类：
• 基础设施层（Node）：集群节点，为整个集群和应用提供运行时资源(物理机、云主机、虚拟机等)
• 容器基础设施（Container）：为应用提供运行时环境
• 用户应用（Pod）：Pod 中会包含一组容器，它们一起工作，并且对外提供一个（或者一 组）功能
• 内部服务负载均衡（Service）：在集群内，通过 Service 在集群暴露应用功能，集群内 应用和应用之间访问时提供内部的负载均衡
• 外部访问入口（Ingress）：通过 Ingress 提供集群外的访问入口，从而可以使外部客户 端能够访问到部署在 Kubernetes 集群内的服务
因此，如果要构建一个完整的监控体系，我们应该考虑，以下 5 个方面：
• 集群节点状态监控：从集群中各节点的 kubelet 服务获取节点的基本运行状态；
• 集群节点资源用量监控：通过 Daemonset 的形式在集群中各个节点部署 Node Exporter 采集节点的资源使用情况；
• 节点中运行的容器监控：通过各个节点中 kubelet 内置的 cAdvisor 中获取个节点中所有 容器的运行状态和资源使用情况；
• 如果在集群中部署的应用程序本身内置了对 Prometheus 的监控支持，那么我们还应该找 到相应的 Pod 实例，并从该 Pod 实例中获取其内部运行状态的监控指标。
• 对 k8s 本身的组件做监控：apiserver、scheduler、controller-manager、kubelet、 kube-proxy
10.node-exporter 组件安装和配置(收集物理节点信息)
规划：k8s集群：一个master和一个node节点
master IP：192.168.199.131 主机名：master
node节点IP：192.168.199.128 主机名：monitor
# node-exporter介绍
node-exporter 可以采集机器（物理机、虚拟机、云主机等）的监控指标数据，能够采集到的指标包 括 CPU, 内存，磁盘，网络，文件数等信息。
10.1 安装node-exporter
# 1.创建名称空间 [root@master ~]# kubectl create ns monitor-sa namespace/monitor-sa created # 2.下载node-exporter镜像压缩包到k8s各个节点并解压 docker load -i node-exporter.tar.gz Loaded image: prom/node-exporter:v0.16.0 github：https://github.com/prometheus/node_exporter/releases dockerhub:https://hub.docker.com/r/quboleinc/node_exporter/tags [root@master prometheus]# kubectl apply -f node-export.yaml daemonset.apps/node-exporter created [root@master prometheus]# kubectl get pods -n monitor-sa -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES node-exporter-bg78z 1/1 Running 0 101s 192.168.199.131 master <none> <none> node-exporter-c6hlb 1/1 Running 0 101s 192.168.199.128 monitor <none> <none>
apiVersion: apps/v1 kind: DaemonSet #可以保证k8s集群每隔节点都运行一样的pod metadata: name: node-exporter namespace: monitor-sa labels: name: node-exporter spec: selector: matchLabels: name: node-exporter template: metadata: labels: name: node-exporter spec: hostPID: true hostIPC: true hostNetwork: true # hostNetwork、hostIPC、hostPID 都为 True 时，表示这个 Pod 里的所有容器，会直接使用宿主机的网络，直接与宿主机进行 IPC（进程间通信）通信，可以看到宿主机里正在运行的所有进程。 加入了 hostNetwork:true 会直接将我们的宿主机的 9100 端口映射出来，从而不需要创建 service 在我们的宿主机上就会有一个 9100 的端口 containers: - name: node-exporter image: prom/node-exporter:v0.16.0 imagePullPolicy: IfNotPresent ports: - containerPort: 9100 resources: requests: cpu: 0.15 #这个容器运行至少需要 0.15 核 cpu securityContext: privileged: true #开启特权模式 args: - --path.procfs #配置挂载宿主机（node 节点）的路径 - /host/proc - --path.sysfs - /host/sys - --collector.filesystem.ignored-mount-points - '"^/(sys|proc|dev|host|etc)($|/)"' #通过正则表达式忽略某些文件系统挂载点的信息收集 volumeMounts: - name: dev mountPath: /host/dev - name: proc mountPath: /host/proc - name: sys mountPath: /host/sys - name: rootfs mountPath: /rootfs #将主机/dev、/proc、/sys 这些目录挂在到容器中，这是因为我们采集的很多节点数据都是通过这些文件来获取系统信息的。 tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoSchedule" volumes: - name: proc hostPath: path: /proc - name: dev hostPath: path: /dev - name: sys hostPath: path: /sys - name: rootfs hostPath: path: /
通过node-exporter采集数据
curl http://主机:9100/metrics
#node-export 默认的监听端口是 9100，可以看到当前主机获取到的所有监控数据
# 主机 cpu 的使用情况 [root@master prometheus]# curl http://192.168.199.131:9100/metrics | grep node_cpu_seconds % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 67877 100 67877 0 0 9522k 0 --:--:-- --:--:-- --:--:-- 10.7M # HELP node_cpu_seconds_total Seconds the cpus spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total{cpu="0",mode="idle"} 17998.73 node_cpu_seconds_total{cpu="0",mode="iowait"} 5.74 node_cpu_seconds_total{cpu="0",mode="irq"} 0 node_cpu_seconds_total{cpu="0",mode="nice"} 0.01 node_cpu_seconds_total{cpu="0",mode="softirq"} 31.18 node_cpu_seconds_total{cpu="0",mode="steal"} 0 node_cpu_seconds_total{cpu="0",mode="system"} 312.73 node_cpu_seconds_total{cpu="0",mode="user"} 138.94 node_cpu_seconds_total{cpu="1",mode="idle"} 18039.41 node_cpu_seconds_total{cpu="1",mode="iowait"} 4.58 node_cpu_seconds_total{cpu="1",mode="irq"} 0 node_cpu_seconds_total{cpu="1",mode="nice"} 0.01 node_cpu_seconds_total{cpu="1",mode="softirq"} 25.46 node_cpu_seconds_total{cpu="1",mode="steal"} 0 node_cpu_seconds_total{cpu="1",mode="system"} 311.16 node_cpu_seconds_total{cpu="1",mode="user"} 130.6 node_cpu_seconds_total{cpu="2",mode="idle"} 18032.72 node_cpu_seconds_total{cpu="2",mode="iowait"} 5.99 node_cpu_seconds_total{cpu="2",mode="irq"} 0 node_cpu_seconds_total{cpu="2",mode="nice"} 0 node_cpu_seconds_total{cpu="2",mode="softirq"} 27.06 node_cpu_seconds_total{cpu="2",mode="steal"} 0 node_cpu_seconds_total{cpu="2",mode="system"} 309 node_cpu_seconds_total{cpu="2",mode="user"} 133.23 node_cpu_seconds_total{cpu="3",mode="idle"} 18030.87 node_cpu_seconds_total{cpu="3",mode="iowait"} 6.66 node_cpu_seconds_total{cpu="3",mode="irq"} 0 node_cpu_seconds_total{cpu="3",mode="nice"} 0 node_cpu_seconds_total{cpu="3",mode="softirq"} 24.58 node_cpu_seconds_total{cpu="3",mode="steal"} 0 node_cpu_seconds_total{cpu="3",mode="system"} 307.78 node_cpu_seconds_total{cpu="3",mode="user"} 140.79
#HELP：解释当前指标的含义，上面表示在每种模式下 node 节点的 cpu 花费的时间，以 s 为单位
#TYPE：说明当前指标的数据类型，上面是 counter 类型
node_cpu_seconds_total{cpu="0",mode="idle"} # cpu0 上 idle 进程占用 CPU 的总时间，CPU 占用时间是一个只增不减的度量指标，从类型中也可以看 出 node_cpu 的数据类型是 counter（计数器）
counter 计数器：只是采集递增的指标
平均负载：
# 如果要看节点的信息，IP替换为节点就行
[root@master prometheus]# curl http://192.168.199.131:9100/metrics | grep node_load
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 67833 100 67833 0 0 8453k 0 --:--:-- --:--:-- --:--:-- 9463k
# HELP node_load1 1m load average.
# TYPE node_load1 gauge
node_load1 0.07
# HELP node_load15 15m load average.
# TYPE node_load15 gauge
node_load15 0.25
# HELP node_load5 5m load average.
# TYPE node_load5 gauge
node_load5 0.22
node_load1 该指标反映了当前主机在最近一分钟以内的负载情况，系统的负载情况会随系统资源的 使用而变化，因此 node_load1 反映的是当前状态，数据可能增加也可能减少，从注释中可以看出当前指 标类型为 gauge（标准尺寸）
gauge 标准尺寸：统计的指标可增加可减少
11. Prometheus server 安装和配置
11.1 创建sa账号，对sa做rbac授权
# 创建一个sa账号monitor [root@master prometheus]# kubectl create serviceaccount monitor -n monitor-sa serviceaccount/monitor created [root@master prometheus]# kubectl get sa -n monitor-sa NAME SECRETS AGE default 1 76m monitor 1 49s # 把 sa 账号 monitor 通过 clusterrolebing 绑定到 clusterrole 上 [root@master prometheus]# kubectl create clusterrolebinding monitor-clusterrolebinding -n monitor-sa --clusterrole=cluster-admin --serviceaccount=monitor-sa:monitor
clusterrolebinding.rbac.authorization.k8s.io/monitor-clusterrolebinding created
11.2 创建prometheus数据存储目录
# 在monitor节点创建数据目录 [root@monitor ~]# mkdir /data [root@monitor ~]# chmod 777 /data
11.3 安装Prometheus server 服务
11.3.1 创建configmap存储卷，用来存放prometheus配置信息
# 服务发现基于node或者endpoint
[root@master prometheus]# cat prometheus-cfg.yaml --- kind: ConfigMap apiVersion: v1 metadata: labels: app: prometheus name: prometheus-config namespace: monitor-sa data: prometheus.yml: | global: scrape_interval: 15s # 采集目标主机监控据的时间间隔 scrape_timeout: 10s # 数据采集超时时间，默认 10s evaluation_interval: 1m # 触发告警检测的时间，默认是 1m scrape_configs: # 配置数据源，称为 target，每个 target 用 job_name 命名。又分为静态配置和服务发现 - job_name: 'kubernetes-node' kubernetes_sd_configs: #使用的是 k8s 的服务发现 - role: node # 使用 node 角色，它使用默认的 kubelet 提供的 http 端口来发现集群中每个 node 节点。 relabel_configs: #重新标记 - source_labels: [__address__] #配置的原始标签，匹配地址 regex: '(.*):10250' #匹配带有 10250 端口的 url replacement: '${1}:9100' #把匹配到的 ip:10250 的 ip 保留 target_label: __address__ #新生成的 url 是${1}获取到的 ip:9100 action: replace - action: labelmap #匹配到下面正则表达式的标签会被保留,如果不做 regex 正则的话，默认只是会显示 instance 标签 regex: __meta_kubernetes_node_label_(.+) - job_name: 'kubernetes-node-cadvisor' # 抓取 cAdvisor 数据，是获取 kubelet 上/metrics/cadvisor 接口数据来获取容器的资源使用情况 kubernetes_sd_configs: - role: node scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - action: labelmap # 把匹配到的标签保留 regex: __meta_kubernetes_node_label_(.+) #保留匹配到的具有__meta_kubernetes_node_label 的标签 - target_label: __address__ #获取到的地址：__adress__=192.168.199.131:10250 replacement: kubernetes.default.svc:443 #把获取到的地址替换成新的地址 kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] #把原始标签中__meta_kubernetes_node_name 值匹配到target_label regex: (.+) target_label: __metrics_path__ #获取__metrics_path__对应的值 replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
# #把 metrics 替换成新的值 api/v1/nodes/master/proxy/metrics/cadvisor
# ${1}是__meta_kubernetes_node_name 获取到的值
# 新的 url 就是 https://kubernetes.default.svc:443/api/v1/nodes/master/proxy/metrics/cadvisor
- job_name: 'kubernetes-apiserver' kubernetes_sd_configs: - role: endpoints #使用 k8s 中的 endpoint 服务发现，采集 apiserver 6443 端口获取到的数据 scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs:
#endpoint 这个对象的名称空间kubectl get ep，endpoint对象服务名，endpoint的端口名称 - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep #采集满足条件的实例，其他实例不采集 regex: default;kubernetes;https #正则匹配到的默认空间下的 service 名字是 kubernetes，协议是 https 的 endpoint 类型保留下来 - job_name: 'kubernetes-service-endpoints' kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] action: keep regex: true
# 重新打标仅抓取到的具有 "prometheus.io/scrape: true" 的 annotation 的端点，意思是说如果某个 service 具有 prometheus.io/scrape = true annotation 声明则抓取，annotation本身也是键值结构，
所以这里的源标签设置为键，而 regex 设置值 true，当值匹配到 regex 设定的内容时则执行 keep 动作也就是保留，其余则丢弃。
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme] action: replace target_label: __scheme__ regex: (https?)
#重新设置 scheme，匹配源标签__meta_kubernetes_service_annotation_prometheus_io_scheme 也就是 prometheus.io/scheme annotation，如果源标签的值匹配到 regex，则把值替换为__scheme__对应的值。
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+)
# 应用中自定义暴露的指标，也许你暴露的 API 接口不是/metrics 这个路径，那么你可以在这个 POD 对应的 service 中做一个"prometheus.io/path = /mymetrics" 声明，上面的意思就是把你声明的这 个路径赋值
给__metrics_path__，其实就是让 prometheus 来获取自定义应用暴露的 metrices 的具体路 径，不过这里写的要和 service 中做好约定，如果 service 中这样写 prometheus.io/app-metricspath: '/metrics'
那么你这里就要 __meta_kubernetes_service_annotation_prometheus_io_app_metrics_path 这样写。
- source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port] action: replace target_label: __address__ regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2
# 暴露自定义的应用的端口，就是把地址和你在 service 中定义的 "prometheus.io/port = " 声明做一个拼接，然后赋值给__address__，这样 prometheus 就能获取自定义应用的端口，然后通过这个端口再结合
__metrics_path__来获取指标，如果__metrics_path__值不是默认的/metrics 那 么就要使用上面的标签替换来获取真正暴露的具体路径。
- action: labelmap #保留下面匹配到的标签 regex: __meta_kubernetes_service_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace #替换__meta_kubernetes_namespace 变成 kubernetes_namespace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_service_name] action: replace target_label: kubernetes_name
[root@master prometheus]# kubectl apply -f prometheus-cfg.yaml
configmap/prometheus-config created
[root@master prometheus]# kubectl get configmap -n monitor-sa NAME DATA AGE kube-root-ca.crt 1 154m prometheus-config 1 4m14s [root@master prometheus]# kubectl describe configmap prometheus-config -n monitor-sa Name: prometheus-config Namespace: monitor-sa Labels: app=prometheus Annotations: <none> Data ==== prometheus.yml:定义了全局配置、scrape_configs ---- .... ...
--- kind: ConfigMap apiVersion: v1 metadata: labels: app: prometheus name: prometheus-config namespace: monitor-sa data: prometheus.yml: | global: scrape_interval: 15s scrape_timeout: 10s evaluation_interval: 1m scrape_configs: - job_name: 'kubernetes-node' kubernetes_sd_configs: - role: node relabel_configs: - source_labels: [__address__] regex: '(.*):10250' replacement: '${1}:9100' target_label: __address__ action: replace - action: labelmap regex: __meta_kubernetes_node_label_(.+) - job_name: 'kubernetes-node-cadvisor' kubernetes_sd_configs: - role: node scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - action: labelmap regex: __meta_kubernetes_node_label_(.+) - target_label: __address__ replacement: kubernetes.default.svc:443 - source_labels: [__meta_kubernetes_node_name] regex: (.+) target_label: __metrics_path__ replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor - job_name: 'kubernetes-apiserver' kubernetes_sd_configs: - role: endpoints scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token relabel_configs: - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name] action: keep regex: default;kubernetes;https - job_name: 'kubernetes-service-endpoints' kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] action: keep regex: true - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme] action: replace target_label: __scheme__ regex: (https?) - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port] action: replace target_label: __address__ regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 - action: labelmap regex: __meta_kubernetes_service_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: kubernetes_namespace - source_labels: [__meta_kubernetes_service_name] action: replace target_label: kubernetes_name
11.3.2 安装Prometheus
# 下载promethus镜像并上传到工作节点monitor进行加载 [root@monitor ~]# docker load -i prometheus-2-2-1.tar.gz Loaded image: prom/prometheus:v2.2.1 [root@master prometheus]# kubectl apply -f prometheus-deploy.yaml deployment.apps/prometheus-server created [root@master prometheus]# kubectl get pods -n monitor-sa -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES node-exporter-bg78z 1/1 Running 0 123m 192.168.199.131 master <none> <none> node-exporter-c6hlb 1/1 Running 0 123m 192.168.199.128 monitor <none> <none> prometheus-server-64f6fd555f-sgw67 1/1 Running 0 29s 10.244.75.193 monitor <none> <none> # prometheus-server的IP是不能访问的，需要创建服务 [root@master prometheus]# kubectl apply -f prometheus-svc.yaml service/prometheus created [root@master prometheus]# kubectl get svc -n monitor-sa NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE prometheus NodePort 10.106.76.183 <none> 9090:30051/TCP 55s
访问：service在宿主机上映射的端口是30051，访问k8s集群master节点：192.168.199.131:30051就可以访问到prometheus的web ui界面了
注意：在下面的 prometheus-deploy.yaml 文件有个 nodeName 字段，这个就是用来指定创建的这个 prometheus 的 pod 调度到哪个节点上，我们这里让 nodeName=monitor也即是让 pod 调度到monitor节点上，因为在monitor
节点创建了数据目录/data,所以：你在 k8s 集群的哪个节点创建/data，就让 pod 调度到哪个节点，nodeName 根据你们自己环境主机去修改即可。
[root@master prometheus]# cat prometheus-deploy.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: prometheus-server namespace: monitor-sa labels: app: prometheus spec: replicas: 1 selector: matchLabels: app: prometheus component: server #matchExpressions: #- {key: app, operator: In, values: [prometheus]} #- {key: component, operator: In, values: [server]} template: metadata: labels: app: prometheus component: server annotations: prometheus.io/scrape: 'false' spec: nodeName: monitor serviceAccountName: monitor containers: - name: prometheus image: prom/prometheus:v2.2.1 imagePullPolicy: IfNotPresent command: - prometheus - --config.file=/etc/prometheus/prometheus.yml - --storage.tsdb.path=/prometheus # 旧数据存储目录 - --storage.tsdb.retention=720h # 默认保留15天后删除 - --web.enable-lifecycle # 开机热加载 ports: - containerPort: 9090 protocol: TCP volumeMounts: - mountPath: /etc/prometheus/prometheus.yml name: prometheus-config subPath: prometheus.yml - mountPath: /prometheus/ name: prometheus-storage-volume volumes: - name: prometheus-config configMap: name: prometheus-config items: - key: prometheus.yml path: prometheus.yml mode: 0644 - name: prometheus-storage-volume hostPath: path: /data type: Directory
[root@master prometheus]# cat prometheus-svc.yaml apiVersion: v1 kind: Service metadata: name: prometheus namespace: monitor-sa labels: app: prometheus spec: type: NodePort ports: - port: 9090 targetPort: 9090 protocol: TCP selector: app: prometheus component: server
浏览器访问http://192.168.199.131:30051
可以对照prometheus-cfg.yaml来看以下图片解释
10.3.3 Prometheus热加载
#为了每次修改配置文件可以热加载 prometheus，也就是不停止 prometheus，就可以使配置生效， 想要使配置生效可用如下热加载命令：
[root@master prometheus]# kubectl get pods -n monitor-sa -o wide -l app=prometheus
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
prometheus-server-64f6fd555f-sgw67 1/1 Running 0 26m 10.244.75.193 monitor <none> <none>
# 修改prometheus-cfg.yaml进行测试 global: scrape_interval: 20s scrape_timeout: 15s [root@master prometheus]# kubectl apply -f prometheus-cfg.yaml configmap/prometheus-config configured [root@master prometheus]# kubectl get configmap -n monitor-sa NAME DATA AGE kube-root-ca.crt 1 3h17m prometheus-config 1 47m [root@master prometheus]# kubectl describe configmap prometheus-config -n monitor-sa Name: prometheus-config Namespace: monitor-sa Labels: app=prometheus Annotations: <none> Data ==== prometheus.yml: ---- global: scrape_interval: 20s scrape_timeout: 15s
目前修改的配置还没有生效，想要使配置生效需用如下命令热加载
[root@master prometheus]# curl -X POST http://10.244.75.193:9090/-/reload
[root@master /]# kubectl logs -f prometheus-server-64f6fd555f-sgw67 -n monitor-sa
level=info ts=2022-08-08T09:36:28.004988349Z caller=main.go:588 msg="Loading configuration file" filename=/etc/prometheus/prometheus.yml
level=info ts=2022-08-08T09:36:28.006529001Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
level=info ts=2022-08-08T09:36:28.007115043Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
level=info ts=2022-08-08T09:36:28.007544007Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
level=info ts=2022-08-08T09:36:28.008121103Z caller=kubernetes.go:191 component="discovery manager scrape" discovery=k8s msg="Using pod service account via in-cluster config"
# 热加载后可以进入到prometheus-server-64f6fd555f-sgw67中查看 /etc/prometheus/prometheus-cfg.yaml中修改的地方发现还没有变化
#热加载速度比较慢，可以暴力重启 prometheus，如修改上面的 prometheus-cfg.yaml 文件之后，可执行如下强制删除：
kubectl delete -f prometheus-cfg.yaml
kubectl delete -f prometheus-deploy.yaml
然后再通过 apply 更新：
kubectl apply -f prometheus-cfg.yaml
kubectl apply -f prometheus-deploy.yaml
注意：
线上最好热加载，暴力删除可能造成执行时间内监控数据的丢失，等待半小时或1小时，或者replicas有2个，删除一个加载一个
直接删除
[root@master prometheus]# kubectl delete pods prometheus-server-64f6fd555f-sgw67 -n monitor-sa
pod "prometheus-server-64f6fd555f-sgw67" deleted
[root@master prometheus]# kubectl get pods -n monitor-sa
NAME READY STATUS RESTARTS AGE
prometheus-server-64f6fd555f-t7bv7 1/1 Running 0 19s