【云原生】Prometheus+Grafana 监控 k8s 资源实战操作

一、概述

Prometheus是一个开源的体系监控和报警体系，现在已经加入到CNCF基金会，成为继k8s之后第二个在CNCF保管的项目，在kubernetes容器办理体系中，通常会搭配prometheus进行监控，一起也支撑多种exporter搜集数据，还支撑pushgateway进行数据上报，Prometheus功用满意支撑上万台规划的集群。

Prometheus+Grafana环境布置能够参考我这篇文章：【云原生】Prometheus+Grafana on K8s 环境布置

二、监控架构

在这儿刺进图片描绘

经过cadvisor搜集容器、Pod相关的功用目标数据，并经过露出的/metrics接口用prometheus抓取。
经过node-exporter搜集主机的功用目标数据，并经过露出的/metrics接口用prometheus抓取。
经过kube-state-metrics搜集k8s资源目标的状况目标数据，并经过露出的/metrics接口用prometheus抓取。
运用侧自己搜集容器中进程主动露出的目标数据（露出目标的功用由运用自己完成，并添加渠道侧约好的annotation，渠道侧担任依据annotation完成经过Prometheus的抓取）。
经过etcd、kubelet、kube-apiserver、kube-controller-manager、kube-scheduler自身露出的/metrics获取节点上与k8s集群相关的一些特征目标数据。

三、给Grafana装备Prometheus数据源

有许多与 Grafana Alerting 兼容的数据源。每个数据源都由一个插件支撑。您能够运用下面列出的内置数据源之一，运用外部数据源插件，或创立自己的数据源插件。以下便是与 Grafana Alerting 兼容并支撑的数据源：

AWS CloudWatch
Azure Monitor
Elasticsearch
Google Cloud Monitoring
Graphite
InfluxDB
Loki
Microsoft SQL Server MSSQL
MySQL
Open TSDB
PostgreSQL
Prometheus
Jaeger
Zipkin
Tempo
Testdata

Grafana web地址：alertmanager.k8s.local/
账号：admin，密码经过下面命令获取0D0NfEWWFx9qsBiKR8PuFVxf6PPa9o8YGhZZaNXY

kubectl get secret --namespace grafana grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo

在这儿刺进图片描绘

# 装备这个内网地址（推荐）
http://prometheus-server.prometheus:80
# 或许装备对外地址
https://prometheus.k8s.local

装备对外地址时，假如域名是经过hosts装备的，得需求在values.yaml文件装备这个hostAliases，IP对应宿主机的IP。就会将这个装备加载到pod里的/etc/hosts文件中。

...
hostAliases:
  - ip: "192.168.182.110"
    hostnames:
      - "prometheus.k8s.local"
...

滚动更新

helm upgrade grafana -n grafana ./grafana

在这儿刺进图片描绘

四、cAdvisor 介绍

cAdvisor是Google开源的容器资源监控和功用剖析工具，它是专门为容器而生，在Kubernetes中，咱们不需求单独去装置，cAdvisor作为kubelet内置的一部分程序能够直接运用，也便是咱们能够直接运用cadvisor搜集数据，能够搜集到和容器运行相关的一切目标，数据路径为/api/v1/nodes/[节点称号]/proxy/metrics/cadvisor。

在这儿刺进图片描绘

kubelet的节点运用cAdvisor供给的metrics接口获取该节点一切容器相关的功用目标数据。
cAdvisor 是一个开源容器资源运用搜集器。它专为容器而构建，支撑本地 Docker 容器。cAdisor 会自动发现给定节点中的一切容器，并搜集CPU、内存、文件体系和网络运用情况计算信息，不过它仅会搜集根本资源利用率。
仅当容器具有 X％CPU 利用率时，cAdvisor 才干告诉咱们运用程序的实践功用。cAdvisor 自身并不供给任何长期存储或剖析功用。

cadvisor中获取到的典型监控目标如下：

目标称号	类型	意义
container_cpu_load_average_10s	gauge	过去10秒容器CPU的平均负载
container_cpu_usage_seconds_total	counter	容器在每个CPU内核上的累积占用时刻 (单位：秒)
container_cpu_system_seconds_total	counter	System CPU累积占用时刻（单位：秒）
container_cpu_user_seconds_total	counter	User CPU累积占用时刻（单位：秒）
container_fs_usage_bytes	gauge	容器中文件体系的运用量(单位：字节)
container_fs_limit_bytes	gauge	容器能够运用的文件体系总量(单位：字节)
container_fs_reads_bytes_total	counter	容器累积读取数据的总量(单位：字节)
container_fs_writes_bytes_total	counter	容器累积写入数据的总量(单位：字节)
container_memory_max_usage_bytes	gauge	容器的最大内存运用量（单位：字节）
container_memory_usage_bytes	gauge	容器当时的内存运用量（单位：字节）
container_spec_memory_limit_bytes	gauge	容器的内存运用量限制
machine_memory_bytes	gauge	当时主机的内存总量
container_network_receive_bytes_total	counter	容器网络累积接纳数据总量（单位：字节）
container_network_transmit_bytes_total	counter	容器网络累积传输数据总量（单位：字节）

cadvisor 常用容器监控目标：

查询容器内存运用量（单位：字节）

container_memory_usage_bytes{image!=""}

查询容器网络接纳量（速率）（单位：字节/秒）

sum(rate(container_network_receive_bytes_total{image!=""}[1m])) without (interface)

容器网络传输量字节/秒

sum(rate(container_network_transmit_bytes_total{image!=""}[1m])) without (interface)

容器文件体系读取速率字节/秒

sum(rate(container_fs_reads_bytes_total{image!=""}[1m])) without (device)

容器文件体系写入速率字节/秒

sum(rate(container_fs_writes_bytes_total{image!=""}[1m])) without (device)

网络流量监控

##容器网络接纳的字节数（1分钟内），依据称号查询 name=~".+"
sum(rate(container_network_receive_bytes_total{name=~".+"}[1m])) by (name)
##容器网络传输的字节数（1分钟内），依据称号查询 name=~".+"
sum(rate(container_network_transmit_bytes_total{name=~".+"}[1m])) by (name)

容器 CPU相关监控

### 容器CPU运用率
sum(irate(container_cpu_usage_seconds_total{image!=""}[1m])) without (cpu)
###所用容器system cpu的累计运用时刻（1min钟内）
sum(rate(container_cpu_system_seconds_total[1m]))
###每个容器system cpu的运用时刻（1min钟内）
sum(irate(container_cpu_system_seconds_total{image!=""}[1m])) without (cpu)
#每个容器的cpu运用率
sum(rate(container_cpu_usage_seconds_total{name=~".+"}[1m])) by (name) * 100
#总容器的cpu运用率
sum(sum(rate(container_cpu_usage_seconds_total{name=~".+"}[1m])) by (name) * 100)

五、监控装备

1）监控k8s集群中的pod

kubelet的节点运用cAdvisor供给的metrics接口获取该节点一切容器相关的功用目标数据。cAdvisor默许集成在k8s中，无需再装置了。

导入grafana模板，集群资源监控：3119

官方模块下载地址：grafana.com/grafana/das…

在这儿刺进图片描绘
上面截图第一个便是3119模板，当然也能够运用上面截图的其它模板，能够依据需求自己选择。将json下来导入到grafana中。

导入模板

2）监控k8s集群中的node

运用文档：prometheus.io/docs/guides…

GitHub：github.com/prometheus/…

exporter列表：prometheus.io/docs/instru…

一切node节点布置node_exporter

kubectl get pods -n prometheus -owide|grep node-exporter

在这儿刺进图片描绘
检查prometheus是否搜集到kubernetes-nodes

在这儿刺进图片描绘
导入grafana模板，集群资源监控：13105，13824，8919
官方模块下载地址：grafana.com/grafana/das…

在这儿刺进图片描绘

3）监控k8s资源目标

kube-state-metrics是一个简单的服务，它监听Kubernetes API服务器并生成有关目标状况的目标。它不重视单个Kubernetes组件的运行状况，而是重视内部各种目标的运行状况，例如布置，节点和容器。

GitHub地址：github.com/kubernetes/…
导入grafana模板，集群资源监控：16520

在这儿刺进图片描绘
假如上面的模板不满意需求，也能够自界说。

六、自界说Dashboard

当然，在有些时候咱们需求对咱们的运用进行目标监控，这个时候需求咱们自界说dashboard。这就需求咱们对Grafana有更深化的了解，比方什么时候metrics，Grafana的查询语法等等。笔者测验用最简单的方式和咱们进行介绍。

1）Folder文件夹

dashboard有必要归于某个文件夹，能够理解成分类，当dashboard多了之后方便办理，默许的folder是 general，咱们能够依据实践情况进行分文件夹，比方 MySQL，K8s等候。

在这儿刺进图片描绘

2）dashboard的组成

一个dashboard由General、Annotations、Variables、Links、Versions、Permissions、JSON Model、Pannels等组成。

在这儿刺进图片描绘

General 根本信息，装备称号，数据源等根本信息
Annotations 查询条件，上方查询条件
Variables 变量，能够用于查询
Links 友情链接
Versions 每一次修改后的历史版别
Permissions 权限
JSON Model，dashboard的最终代码用json来表达，咱们上面导入id后其实加载的便是json代码
Panel，图标组件，图表组件支撑大部分常见的图表

在这儿刺进图片描绘

七、Grafana Alerting

官方文档：grafana.com/docs/grafan…

除了Prometheus的AlertManager能够发送报警，Grafana Alerting一起也支撑。Grafana Alerting能够无缝界说告警在数据中的方位，可视化的界说阈值，并能够经过钉钉、email等渠道获取告警告诉。最重要的是可直观的界说告警规矩，不断的评价并发送告诉。grafana只有在4.0以上版别才有，一起在Grafana 5.3及以上版别支撑发送提醒，能够指定怎么常常提醒运用运用的秒、分、或许小时。所以在企业里用AlertManager 告警反而少了。

下图概述了 Grafana 警报的作业原理图：
在这儿刺进图片描绘

Alert rule ——设置确认警报实例是否会触发的评价规范。警报规矩由一个或多个查询和表达式、条件、评价频率以及满意条件的继续时刻（可选）组成。
Labels ——将警报规矩及其实例与告诉战略和静默相匹配。它们还可用于按严重性对警报进行分组。
Notification policy ——设置警报的发送地点、时刻和方式。每个告诉战略指定一组标签匹配器来指示它们担任哪些警报。告诉战略具有分配给它的由一个或多个告诉者组成的联系点。
Contact points ——界说触发警报时怎么告诉您的联系人。咱们支撑多种 ChatOps 工具，以确保您的团队收到警报。

在这儿刺进图片描绘

1）告警规矩（Alert rules）

告警规矩是一组评价规范，用于确认告警实例是否会触发。该规矩由一个或多个查询和表达式、一个条件、评价频率以及满意条件的继续时刻（可选）组成。
在查询和表达式选择要评价的数据集时，条件会设置告警有必要到达或超过才干创立警报的阈值。
间隔指定评价警报规矩的频率。继续时刻在装备时表明有必要满意条件的时刻。告警规矩还能够界说没有数据时的告警行为。

2）告警规矩的注释和标签（Annotations and labels for alerting rules）

注释和标签是与源自警报规矩、数据源呼应以及警报规矩评价结果的警报相关联的键值对。它们能够直接用于警报告诉，也能够在模板和模板函数中运用，以动态创立告诉联系人。

注释（Annotations ）——注释是供给有关警报的附加元信息的键值对。您能够运用以下注释：description、summary、runbook_url、alertId、dashboardUid、和panelId。例如，描绘、摘要和 Runbook URL。这些显示在 UI 中的规矩和警报详细信息中，并可用于联络点音讯模板。
标签（labels ）——标签是包括有关信息的键值对，用于唯一标识警报。在整个警报评价和告诉过程中生成并添加警报的标签集。

3）告警规矩的状况和运行状况

共有三个要害组件：告警规矩状况、告警规矩运行状况和告警实例状况。虽然相关，但每个组件都传达了奇妙的不同信息。
在这儿刺进图片描绘

1、告警规矩状况（Alert rule state）

告警规矩能够处于以下状况之一：

状况	描绘
Normal	评价引擎回来的时刻序列都不是处于Pending 或许 Firing状况。
Pending	评价引擎回来的至少一个时刻序列是Pending。
Firing	评价引擎回来的至少一个时刻序列是Firing。

2、告警规矩运行状况（Alert rule health）

告警规矩能够具有以下运行状况之一：

状况	描绘
Ok	评价告警规矩时没有过错。
Error	评价告警规矩时没有过错。
NoData	在规矩评价期间回来的至少一个时刻序列中短少数据。

3、告警实例状况（Alert instance state）

告警实例能够处于以下任一状况：

状况	描绘
Normal	既未触发也未挂起的告警状况，一切正常。
Pending	已激活的告警状况少于装备的阈值继续时刻。
Alerting	已激活超过装备的阈值继续时刻的告警的状况。
NoData	在装备的时刻窗口内未收到任何数据。
Error	测验评价告警规矩时产生的过错。

八、告警通道（Contact points/Notification channels）

运用告警通道来界说当警报触发时怎么告诉您的联系人。一个告警通道能够有一个或多个告警通道类型，例如电子邮件、webhook、钉钉、企业微信 等。触发警报时，会向为某个告警通道列出的一切告警通道类型发送告诉。或许，运用音讯模板自界说告警通道类型的告诉音讯。您能够装备 Grafana 办理的联系点以及外部 Alertmanager 数据源的联系点。这儿不讲，关于对接外部的Alertmanager，请检查官方文档。

1）邮件告警通道（默许）

1、装备stmp服务（grafana.ini）

[smtp]
enabled = true
host = localhost:25
user =
# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
password =
cert_file =
key_file =
skip_verify = false
from_address = admin@grafana.localhost
from_name = Grafana
ehlo_identity =
startTLS_policy =

grafana on k8s 中装备values.yaml

smtp:
  enabled: true
  host: "smtp.qq.com:465"
  user: "xxx@qq.com"
  # If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
  password: "xxx"
  skip_verify: true
  from_address: "xxx@qq.com"
  from_name: Grafana
  cert_file: ""
  key_file: ""
  ehlo_identity: ""
  startTLS_policy: ""

upgrade更新

helm upgrade grafana ./grafana -n grafana

2、grafana web装备

在这儿刺进图片描绘
测试

3、测试验证

第一步：创立Folder
在这儿刺进图片描绘
第二步：告警规矩装备，在需求装备告警的图表上按e就进入修改页面，在修改页面装备告警规矩

第三步：等候邮件告警

2）Webhook 告警通道

Webhook告警通道其实也是最常用的，一般便是对接内部的告警渠道，经过公司内部的告警渠道分发到其它告警通道发告警，例如：IM，电话，zabbix等等，其实Webhook便是告警转发器，一般需求自己写程序去完成，webhook的完成就由小伙伴自己依据业务场景去完成了，除了这两种，告警通道还有很多，一般用的多的或许便是邮件、webhook、钉钉、企业微信了。当然有什么疑问也欢迎给我留言哦。

Prometheus+Grafana 监控 k8s 资源实战操作就先到这儿了，小伙伴有任何疑问欢迎给我留言，有空必回，后续会继续更新关于【云原生和大数据】相关的文章，请小伙伴耐性等候~

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

【云原生】Prometheus+Grafana 监控 k8s 资源实战操作

一、概述

二、监控架构

三、给Grafana装备Prometheus数据源

四、cAdvisor 介绍

五、监控装备

1）监控k8s集群中的pod

2）监控k8s集群中的node

3）监控k8s资源目标

六、自界说Dashboard

1）Folder文件夹

2）dashboard的组成

七、Grafana Alerting

1）告警规矩（Alert rules）

2）告警规矩的注释和标签（Annotations and labels for alerting rules）

3）告警规矩的状况和运行状况

1、告警规矩状况（Alert rule state）

2、告警规矩运行状况（Alert rule health）

3、告警实例状况（Alert instance state）

八、告警通道（Contact points/Notification channels）

1）邮件告警通道（默许）

1、装备stmp服务（grafana.ini）

2、grafana web装备

3、测试验证

2）Webhook 告警通道

近期文章

近期评论

【云原生】Prometheus+Grafana 监控 k8s 资源实战操作

一、概述

二、监控架构

三、给Grafana装备Prometheus数据源

四、cAdvisor 介绍

五、监控装备

1）监控k8s集群中的pod

2） 监控k8s集群中的node

3）监控k8s资源目标

六、自界说Dashboard

1）Folder文件夹

2）dashboard的组成

七、Grafana Alerting

1）告警规矩（Alert rules）

2）告警规矩的注释和标签（Annotations and labels for alerting rules）

3）告警规矩的状况和运行状况

1、告警规矩状况（Alert rule state）

2、告警规矩运行状况（Alert rule health）

3、告警实例状况（Alert instance state）

八、告警通道（Contact points/Notification channels）

1）邮件告警通道（默许）

1、装备stmp服务（grafana.ini）

2、grafana web装备

3、测试验证

2）Webhook 告警通道

近期文章

近期评论

2）监控k8s集群中的node