Prometheus+Grafana 监控 k8s 资源实战操作
Tags: Grafanak8sPrometheus监控
一、概述
Prometheus是一个开源的系统监控和报警系统,现在已经加入到CNCF基金会,成为继k8s之后第二个在CNCF托管的项目,在kubernetes容器管理系统中,通常会搭配prometheus进行监控,同时也支持多种exporter采集数据,还支持pushgateway进行数据上报,Prometheus性能足够支撑上万台规模的集群。
二、监控架构
- 通过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地址:
https://alertmanager.k8s.local/
►账号:admin,密码通过下面命令获取
0D0NfEWWFx9qsBiKR8PuFVxf6PPa9o8YGhZZaNXY
1 | kubectl get secret --namespace grafana grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo |
►# 配置这个内网地址(推荐)
http://prometheus-server.prometheus:80
►# 或者配置对外地址
►配置对外地址时,如果域名是通过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 常用容器监控指标:
- · 查询容器内存使用量(单位:字节)
1 | container_memory_usage_bytes{image!=""} |
- · 查询容器网络接收量(速率)(单位:字节/秒)
1 | sum(rate(container_network_receive_bytes_total{image!=""}[1m])) without (interface) |
- · 容器网络传输量 字节/秒
1 | sum(rate(container_network_transmit_bytes_total{image!=""}[1m])) without (interface) |
- · 容器文件系统读取速率 字节/秒
1 | sum(rate(container_fs_reads_bytes_total{image!=""}[1m])) without (device) |
- · 容器文件系统写入速率 字节/秒
1 | sum(rate(container_fs_writes_bytes_total{image!=""}[1m])) without (device) |
- · 网络流量监控
1 2 3 4 5 | ##容器网络接收的字节数(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相关监控
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | ### 容器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
►官方模块下载地址:
https://grafana.com/grafana/dashboards/
►上面截图第一个就是3119模板,当然也可以使用上面截图的其它模板,可以根据需要自己选择。将json下来导入到grafana中。
►导入模板
►2) 监控k8s集群中的node
使用文档:https://prometheus.io/docs/guides/node-exporter/
GitHub:https://github.com/prometheus/node_exporter
exporter列表:https://prometheus.io/docs/instrumenting/exporters/
所有node节点部署node_exporter
kubectl get pods -n prometheus -owide|grep node-exporter
►查看prometheus是否收集到kubernetes-nodes
►导入grafana模板,集群资源监控:13105,13824,8919
官方模块下载地址:https://grafana.com/grafana/dashboards/
►3)监控k8s资源对象
kube-state-metrics是一个简单的服务,它监听Kubernetes API服务器并生成有关对象状态的指标。它不关注单个Kubernetes组件的运行状况,而是关注内部各种对象的运行状况,例如部署,节点和容器。
GitHub地址:https://github.com/kubernetes/kube-state-metrics
导入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
►官方文档:
https://grafana.com/docs/grafana/latest/alerting/
除了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 | 尝试评估告警规则时发生的错误。 |
八、告警通道
►使用告警通道来定义当警报触发时如何通知您的联系人。一个告警通道可以有一个或多个告警通道类型,例如电子邮件、webhook、钉钉、企业微信 等。触发警报时,会向为某个告警通道列出的所有告警通道类型发送通知。或者,使用消息模板自定义告警通道类型的通知消息。您可以配置 Grafana 管理的联系点以及外部 Alertmanager 数据源的联系点。这里不讲,关于对接外部的Alertmanager,请查看官方文档。
►1)邮件告警通道(默认)
1、配置stmp服务(grafana.ini)
1 2 3 4 5 6 7 8 9 10 11 12 13 | [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 = |
►2、grafana web配置
►测试
►3、测试验证
· 第一步:创建Folder
· 第二步:告警规则配置,在需要配置告警的图表上按e就进入编辑页面,在编辑页面配置告警规则
·第三步:等待邮件告警
►2)Webhook 告警通道
Webhook告警通道其实也是最常用的,一般就是对接内部的告警平台,通过公司内部的告警平台分发到其它告警通道发告警,例如:IM,电话,zabbix等等,其实Webhook就是告警转发器,一般需要自己写程序去实现,webhook的实现就由小伙伴自己根据业务场景去实现了,除了这两种,告警通道还有很多,一般用的多的可能就是邮件、webhook、钉钉、企业微信了。
参考
https://mp.weixin.qq.com/s/5grpWE8Pk_bsseGwbBtDGw
https://www.toutiao.com/article/7144581679339209252/?channel=&source=news&wid=1675220534088