2021/03/27 K8S集群日志与监控

最新推荐文章于 2024-07-05 17:56:07 发布

48N6E

最新推荐文章于 2024-07-05 17:56:07 发布

阅读量3.2k

点赞数

分类专栏： K8S进阶

本文链接：https://blog.csdn.net/qq_42227818/article/details/115268423

版权

K8S进阶专栏收录该内容

32 篇文章 20 订阅

订阅专栏

第1章 k8s日志收集

1.1 节点日志代理架构

在这里插入图片描述
官网对K8S整个日志架构相关的介绍

在这里插入图片描述
总体分为三种方式：
使用每个节点上运行的节点级日志记录代理
在应用程序的pod中，包含专门记录日志的sidecar容器
将日志直接从应用程序中推送到日志记录后端

在这里插入图片描述
日志驱动，定义一个大门daemon.json文件，去配置docker选项，log-driver

在这里插入图片描述
默认会存储到一个文件里，假如不设置，这也是默认设置

在这里插入图片描述

json-file是默认的一个日志驱动

在这里插入图片描述
如果日志驱动是json-file，程序的输入输出会打到这个json文件里

查看它的一个日志

这就是打印出来的日志

可以设置一个日志的轮转

但是这样的情况是只是收取一个标准输出，业务里面的日志可能是收集不到的
在这里插入图片描述

1.2 使用sidecar容器和日志代理

在这里插入图片描述

模拟写日志

sidecar容器也可以挂载日志的打印

在这里插入图片描述

在这里插入图片描述

这里有三个容器，主容器，加sidecar容器

查看主容器的日志是否已经打印到了宿主机的json-file

count-log-1的sidecar容器就能看到日志

每个pod去集成一个logging-agent，资源是比较消耗的，优势就是宿主机不用存日志
在这里插入图片描述

1.3 企业日志收集方案选型

也可以选择应用日志直接打印到后端

在这里插入图片描述

实现的大致思路

在这里插入图片描述
docker inspect可以拿到整个变量信息，就可以识别是否需要日志收集

或者通过K8Slabel信息

在这里插入图片描述
这些信息拿到只要找到容器的日志文件就行，就是为什么要挂载磁盘跟路径的原因

可以从graphdriver找到日志路径，agent找到这个路径就可以进行收集

agent只需要下发需要到哪里采集的配置到专门的日志收集工具即可

在这里插入图片描述
这是开源出的收集容器日志文件工具

在这里插入图片描述
思路跟下面是大致一样的，跟实际收集的fluentd和filebeat做配合，实际就是下发配置告诉收集工具到哪里去收集

第2章 EFK框架及工作流程

2.1 EFK架构及工作流程

每个节点上起了一个fluentd代理，微服务应用日志可以打到docker 的logs里，fluentd收集这些日志，存到es里
在这里插入图片描述

fluentd官方地址

在这里插入图片描述
收集，处理，转发

fluentd除了核心功能，其他都可以用插件的方式实现，扩展性很好

第3章 Fluentd精讲

3.1 Fluentd架构

两个图很明显的对比，之前杂乱无章，后面用了fluentd（过滤，缓存和路由）
在这里插入图片描述
属于k8s官方推荐的拓展的应用

可插拔的设计，engine里定义了一系列接口，可以支持不同的插件去实现

fluentd有基于内存和本地的存储机制，保证可靠性

3.2 Fluentd事件流生命周期及指令配置

fluentd的事件流生命周期。
INPUT数据从日志文件或http请求，filter 1过滤处理，buffer缓冲，再到输出到es等服务中
在这里插入图片描述
只需要启动的时候指定文件即可

通过source指令，选择需要输入的插件启用数据源

这一段定义fluentd处理的数据来源，source来源于文件一般用tail去处理

这是让fluentd去记录处理的行数，去做续传，防止机器重启，从头开始传

在这里插入图片描述
打tag，是去做路由的指标

这些都是支持的数据来源

在这里插入图片描述
tcp，监听端口来的日志

filter是一个进行事件处理流

在这里插入图片描述
filter里可以用record_transformer记录转化插件，把主机的hostname取出来放到host_param里去

在这里插入图片描述
label可以在source里指定一个label，这个source所触发的事件就会被发送给指定的label所包含的任务，而不会被后续的其他任务获取到

所有带有label的source的处理都要到这里来，也就是可以用label来区分数据源和路由
在这里插入图片描述
match就是匹配输出到哪里

在这里插入图片描述
type如果是file类型，会被fluentd存储到这里

在这里插入图片描述

output插件有很多

**time是fluentd处理事件的时间，
tag，是事件的来源，在fluentd.conf中的配置
record是真实的内容，json对象
**

在这里插入图片描述

3.3 事件Buffer缓冲模型

在这里插入图片描述
数据处理之后是先存到了buffer里，chunk是存储fluentd处理完的事件的一个存储块。有一个队列里放了chunk块，

chunk块达到满足大小的条件会发送到一个chunk的队列里，比如默认8M。或者以时间间隔，每10s一次

在这里插入图片描述
**chunk进入队列以后就发送到output端
**

假如没有这个队列，每处理一个请求，fluentd，都会和output端建立链接，是比较消耗资源的，一个tcp链接其实是可以传输很大的数据量的。chunk可以定义大小，queue可以定义长度，就是做一个数据的缓冲。假如长度800，每个chunk块8M，就能缓冲8*800M的大小。假如output端的kafka失联了，queue是发送不成功，但是数据是会保留在queue里，不会丢失的，做一个临时文件的保存

在这里插入图片描述

缓冲的类型，chunk可以缓冲到哪里，可以是文件或者是内存

每个chunk块大小，默认8M

在这里插入图片描述
*队列的长度，默认256，可缓冲的数据就是8M 256

进入队列的时间

假如output端失联，发送失败，重试的次数,17次都没有成功，这数据就会丢弃

重试发送chunk的时间间隔，第一次1s，第2次2s，第三次3s
在这里插入图片描述
比较理想的情况是，每次chunk产生的时候，都可以发送到对立，立即到输出端

在这里插入图片描述
如果队列长度达到了界限，f就会拒绝新的事件，fluentd就会报错

所以要根据实际的参数调优，队列可以设置大一些

3.4 实践使用fluentd实现业务日志的收集及字段解析

目标收集nginx访问日志，并解析成json格式
在这里插入图片描述
整个思路，监听日志文件，对日志文件进行解析

假设access.log路径

记录分析日志的行数

打一个tag，format不写，log_level日志级别

@type parser就是解析
filter只是做一个转换变成json
format是一段正则表达式

在这里插入图片描述
正则匹配这里

在这里插入图片描述

在这里插入图片描述
match就是把filter处理好的日志输出，stdout打印到标准输出里去

在这里插入图片描述

这里是可以测试fluentd测试的地址

在这里插入图片描述
网页拉到下面，fluentd会帮你日志分析成这样

在这里插入图片描述

可以启动一个测试的fluentd，全局的entrypoint是去启动容器里的首要进程

创建fluentd配置文件

已经去检测文件了

在另一个终端记录日志文件

在这里插入图片描述
fluentd的运行日志里就看到了记录

生成的记录总共有tag，time，record

可以使用这个网站进行正则校验

在这里插入图片描述

3.5 实践使用ruby实现日志字段的转换及逻辑处理

光是转换还不够，还要去做自定义处理，比如加一个字段
在这里插入图片描述
第一个filter去做格式转换

加了第二个fileter，recordtransformer，记录转换

record，在字段内部，加了host_name字段和my_key字段（可以放一些业务含义的）

在这里插入图片描述
大括号里才是运算逻辑，record是一个内置的字段，整个filter实现的一个记录

这是把字段的值取出来了
、
查看是否包含https关键字，true和false赋值给tls这个值

默认不允许使用ruby语法，可以强制使用ruby
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

按照新的配置文件启动

在这里插入图片描述

发送请求看看效果，hostname现在是容器的hostname

第4章 EFK基于K8S部署

4.1 部署ES服务

一般eS不会放在K8S里

在这里插入图片描述
本机先用K8S原始方式安装

在这里插入图片描述

部署在ES=true的主机上

在这里插入图片描述
本地路径esdata目录

在这里插入图片描述
系统参数

还修改了权限

在这里插入图片描述

先创建namespace

打一个label

创建es服务

起了一个service

在这里插入图片描述

还在启动中

在这里插入图片描述 es启动成功

在这里插入图片描述

4.2 部署kibana服务

在这里插入图片描述

在这里插入图片描述

创建一个kibana的yaml

可以查看节点的状态信息

在这里插入图片描述
索引数

4.3 Fluentd部署及k8s插件配置

在这里插入图片描述
需要采集日志就在对应的节点上部署就行

在这里插入图片描述

包含读这个文件夹下的所有配置文件

在这里插入图片描述

查看这个目录下的日志文件长什么样子，这个路径下有当前所有容器的日志
在这里插入图片描述

在这里插入图片描述

查看文件内容

跟/var/lib/docker下，文件路径是一样的
在这里插入图片描述
其实最终指向的就是/var/lib/docker下

在这里插入图片描述

在这里插入图片描述
其实文件名里有很多信息，podname，namespace，加上deployment名字

捕捉一些异常的日志，多了一些多行合并的功能

丰富K8S的元数据，拿到对应的元数据填充到label里

在这里插入图片描述
就是用这个插件

在这里插入图片描述

这里是实现拿到的K8S元数据，这个元数据都可以放到ES作为过滤条件

这里才是往ES写数据里的内容，ES作为output端

chunk设置，大小2m,队列8个，也就是16M的数据

在这里插入图片描述

需要读取K8S的元数据，所以要给fluentd配置rbac规则

在这里插入图片描述

先创建配置文件

在这里插入图片描述

在这里插入图片描述

fluentd的confimap

在这里插入图片描述

需要一个rbac规则
在这里插入图片描述

在这里插入图片描述
在slave1和slave2打上fluentd部署的标签

之前的fluentd配置只是一个source，两个过滤，一个match,上面是一个官方给的链接

官方地址里有部署的所有文件都在这里

在这里插入图片描述
官方给的其实是很全的，有systemd，Prometheus，可以直接用它的配置文件

第5章 EFK收集Pod日志功能验证

5.1 验证EFK收集pod的日志

验证之前部署的EFK收集日志
在这里插入图片描述

在这里插入图片描述

查看一下日志

在这里插入图片描述

先要配置一个查数据的索引
在这里插入图片描述

在这里插入图片描述

随便tail一个日志文件，这里是13个字段

在这里插入图片描述
但是这里显示48个字段

在这里插入图片描述

这里是K8S的一些属性

在这里插入图片描述

这里已经有很多日志了

pod叫counter

在这里插入图片描述

关键字去查

在这里插入图片描述

EFK收集了日志，业务开发人员就不需要登录集群了

第6章 Prometheus监控体系精讲

6.1 k8s集群监控体系演变史

Prometheus现在已经成为云原生监控的标准

在这里插入图片描述

K8S推出的监控标准api，指标有限

6.2 Prometheus架构

在这里插入图片描述
这是最核心的内容

在这里插入图片描述
这里是普罗米修斯自带的服务发现，可以自动发现想要监控的target资源，还有一个是手动修改配置告诉prometheus去监控哪些指标

在这里插入图片描述

拉取请求，把数据存储到server端，数据一种是拉取一种是服务发现，配置好告诉Prometheus哪些target需要拉取数据，进行存储，先存储到内存里，再存到磁盘里做持久化

Prometheus自己提供了一套查询语言promsql，可以通过webui grafana，第三方api去查询数据

在这里插入图片描述
alert告警功能，可以配置告警规则阀值。推送到alertmanager告警管理器，通知到各个终端上去

在这里插入图片描述
**如果有短暂的任务指标需要去采集，那就不是很适合去直接注册到prometheus里，一方面prometheus的网络端肯定不是所有人都可以链接上，这样就可以通过pushgateway的方式，这个gateway有短暂的存储功能，提供一个网关的地址，这个地址作为Prometheus的一个target，prometheus会去pullgateway里的数据
**

在这里插入图片描述
凡是可以给Prometheus提供数据的都可以称为一个exporter

告警还是Prometheus提供的，只不过告警信息推到了alertmanager里而已

在这里插入图片描述

在这里插入图片描述
Prometheus首先要知道要去获取哪些监控指标的数据，抓取之后作为一个存储监控的功能，同时提供存储告警的功能

6.3 Prometheus的安装

在这里插入图片描述
通过docker镜像安装

先用docker启动，查看有什么问题，是怎么启动的，然后才方便写yaml
在这里插入图片描述

这个就是启动命令

查看下默认指代的配置文件

在这里插入图片描述

建立一个名称空间

在这里插入图片描述
配置文件是通过configmap初始化的

在这里插入图片描述

在这里插入图片描述

需要挂载存储路径，容器的存储路径挂载

cnfigmap挂载到容器内部

会把configmap所有的文件挂载到这里

这里是用nobody用户起的

需要初始化的时候赋予权限

在这里插入图片描述
prometheus既然要读取K8S一些信息，并且自动发现，首先就是要rbac

在这里插入图片描述

noneresourceurls非资源类型的url，抓取指定的path。指标采集的接口

在这里插入图片描述

在这里插入图片描述
这里的serviceaccount就是Prometheus，创建一个prometheus的serviceaccount，绑定一些clusterrole权限

暴露一个ingress，Prometheus自带web界面可以操作指标查询

在这里插入图片描述

删除之前用docker启动的Prometheus

创建专门放监控的目录

在这里插入图片描述

在这里插入图片描述
这个参数支持热更新，可以reload

在这里插入图片描述

准备deployment文件
在这里插入图片描述

固定目录要固定到指定的机器上去
在这里插入图片描述

在这里插入图片描述

准备rbac

在这里插入图片描述
ingress文件

在这里插入图片描述
创建namespace

给node打label

deployment依赖configmap，所以先创建configmap

同样deployment依赖rbac，也需要先创建rabc

在这里插入图片描述
创建deployment

在这里插入图片描述
创建svc和ingress

查看ingress信息是否正确

在这里插入图片描述
修改host指向

在这里插入图片描述

6.4 理解时间序列数据库（TSDB）

这是一个监控列表

在这里插入图片描述
scrape_configs抓取配置，Prometheus自身提供了指标暴露的api

在这里插入图片描述

就可以看到数据了
‘使用ingress也可以访问

在这里插入图片描述

大括号类似一个label,也可以作为一个维度的过滤

代表当前指标的个数

在这里插入图片描述
每15s去抓取一次数据

每次获取的数据都会以时间序列的方式保存到内存中，定期更新到硬盘上

每个点代表一个样本，可以看到当前时间哪个key的值，一个样本的三要素是指标，时间戳，样本值。

在这里插入图片描述
名字就是反应这个指标的含义

6.5 添加监控目标

去graph可以查询指标，这些指标都是通过metrics收集来的

在这里插入图片描述
这个指标是Prometheus这边接收的http请求统计信息

上面的点连在一起就成了一张图

在这里插入图片描述

假如你返回的格式是下面的格式，prometheus就会认你，你的监控值就会被Prometheus存储起来，两个#号对应指标

在这里插入图片描述
可以试试coredms

在这里插入图片描述

访问指标

在这里插入图片描述
修改配置让coredns接入prometheus监控

在这里插入图片描述
测试一下访问

用clusterip，因为这个ip不会变，写入到了集群里，新起的pod都会注入这个地址

在这里插入图片描述

在这里插入图片描述
更新confimap文件

正在起新的pod

在这里插入图片描述

现在已经能看到coredns的指标了，这些指标是coredns提供到prometheus里的

在这里插入图片描述

prometheus开发了转换这种格式的工具

6.6 apiserver的指标监控

在这里插入图片描述
apiserver也暴露了一个metrics接口

在这里插入图片描述
这个认证其实是之前创建admin-token这样一个service-account里的权限，是给的admin权限
**在这里插入图片描述

进行访问apiserver的metrics

在这里插入图片描述

这个地址就是整个K8S提供外部访问的一个地址

在这里插入图片描述

这样也可以

在这里插入图片描述
这个是需要带认证的metrics，配置一个CA证书

在这里插入图片描述
k8s里的资源都会存储这样一个K8S默认生成的token信息，prometheus的pod使用了一个serviceaccount，serviceaccount默认挂载的token

容器里就有三个文件，CA证书

在这里插入图片描述
Prometheus的serviceaccount默认生成的这个token信息挂载目录

在这里插入图片描述
拿这个token信息和ca证书做认证

Prometheus的根证书和K8S的根证书应该一致

添加一个apiserver的job
在这里插入图片描述

现在就有apiserver的指标了

在这里插入图片描述
kube-scheduler和kube-controller-manager也提供了暴露metrics的api，端口应该是11251.11252

在这里插入图片描述

6.7 节点基础指标的监控

在这里插入图片描述
这是事实上一个K8S节点基本监控的基准

在这里插入图片描述
为什么会有node_exporter出现，基础指标是一类通用指标，和你的业务没有太大关系，别人就写了一类指标

在这里插入图片描述
这里有一个容忍读，意思是只要你的污点存在就容忍，也就是不管污点什么样子都能容忍

挂载的一些proc文件，因为宿主机信息都是存放在文件里的，需要读取信息

hostnetwork，host模式，可以通宿主机端口去访问
在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

daemonset每个节点去起了一个

在这里插入图片描述
每次都可以去当前监控的情况取出来

在这里插入图片描述
target列表多了，一条条加到配置文件里就比较麻烦了

6.8 Prometheus服务发现与Relabeling

在这里插入图片描述

先看一下生成的target是什么样子

这就是新加的

在这里插入图片描述
需要把默认的10250换成9100，10250是kubelet的api服务端口，说明node模式默认集成了kubelet

在抓取之前prometheus提供了relabel的能力

在这里插入图片描述
加载监控列表

在抓取样本之前其实是有一个relabel的操作

在这里插入图片描述
这里只显示了两个labels，instance和job

relabel之前有这么多，下划线这种在抓取后最终都被丢弃了

before relabeling其实是在relabel之前的一个标记

在采集数据之前可以对target进行一个重写

在这里插入图片描述
不带下划线的就这两个了，所以被留下来了

在这里插入图片描述
source_label就是指要去给哪个标签做relabel

在这里插入图片描述
下面的正则表达式会去匹配address的值，括号代表做了一个分组

这里$1代表访问上面匹配到的分组

在这里插入图片描述
去替换的时候还是去替换原来的__address__，action：replace作为一个代替

在这里插入图片描述

修改configmap

在这里插入图片描述

原有的指标就变成9100端口了

这样就用服务发现的能力，解决了问题，没有添加太多的Prometheus的配置，同时使用了自动发现

node_load1,是最近1分钟的负载指标 在这里插入图片描述
可用内存
通过node-exporter，开源查看很多关于主机监控的指标

IO里的读

在这里插入图片描述
写在磁盘上的

6.9 cadvisor指标的采集

业务容器的指标监控就是CAdvisor
在这里插入图片描述
如何将cadvisor的指标暴露到prometheus里去

如果还是像之前一样利用priometheus里的正则去匹配，那么就需要加一个路径metric_path
在这里插入图片描述

在这里插入图片描述
剩下还需要改一个path，因为目标是下面这样的

这里有一个指标可以读取到node_name

在这里插入图片描述
source_labels代表要去匹配relabel里

上面的值做一个全量匹配

在这里插入图片描述
这是替换后的样子

在这里插入图片描述

修改configmap

在这里插入图片描述

这里就是我们期望的样子

可以看到容器的相关指标，container

daemonset这种服务就适合在prometheus里做一个服务发现

6.10 通用Service服务的指标采集

假如有很多业务应用，每个业务应用去访问metrics这个api，那么配置文件就很难维护
在这里插入图片描述
之前的服务发现是node类型，现在改成endpoint类型

加到后面

在这里插入图片描述

现在就出现了7个endpoint，prometheus应该是在集群内部读了所有的endpoint列表

在这里插入图片描述
上面显示的53有点问题，

应该是下面的9153

K8S的默认服务 6443

这里加起来就是7个

在这里插入图片描述

也就是说使用endpoint，就会去读取所有命名空间下的列表，把它当成被采集的地址，缺点是不能过滤
在这里插入图片描述

需要一种方式来采集我们想要采集的服务。
支持一个目标重写和过滤

在这里插入图片描述
读这个label的值

在这里插入图片描述
会读取label里的值，如果是true才会加到target里

这里看起来像是K8S的申明

在这里插入图片描述
就可以看一下coredns服务对外的申明，是否有这个值

在这里插入图片描述

在这里插入图片描述
找到了这个申明

这样我们就看到了prometheus的转换规律

可以看这个label值是否是true，如果是就保留

这样也就是我们在申明要采集的服务的时候，只需要加annotation申明即可

在这里插入图片描述
Prometheus在采集后就会加上这一串的值

只要在service加上annotation，这个service获取的endpoint信息里就会被prometheus加上对应的标签

但是有的服务不一定是metrics
在这里插入图片描述
这是我们服务采集的一个真实的地址

在这里插入图片描述
这样就可以拿定义的path替换实际的path，这样就适配不同的业务应用的path不一样

还有种业务服务的metrics是独立端口，就比如下面采集到的dns，53端口，很明显不是提供监控服务的，只是暴露给dns server的端口
在这里插入图片描述
这个替换就比较麻烦了

先指定申明一个9153端口，当成prometheus去采集的一个端口

**Prometheus默认使用__address__去采集 **

在这里插入图片描述
其实address也可以没有端口，正则匹配出ip地址，加上我们申明的指定端口就行

下面就是一个正则规则

在这里插入图片描述
匹配了两个label

$1g和$2做了拼接

在这里插入图片描述
如果有多个label拼接，那么拼接的是用分号；拼接的，在正则里表现出来

这要这段值加了?:问号和冒号，就代表是非获取的，就不会成为$2，这样后面的(\d+)就成为了$2

在这里插入图片描述

第一个是指明是否要去抓取service服务，
第二个做一个service服务的metrics的path替换
第三个是做端口的替换

在这里插入图片描述
还可以把before labelding里把更多的字段取出来

在这里插入图片描述

这样拿到的数据就更多

第一步做过滤，只有你的service里标签带这个才过滤放行
在这里插入图片描述

在这里插入图片描述
在后面进行黏贴

在这里插入图片描述

这里可以拿到coredns的值

在这里插入图片描述
自己写的服务，加上这两行就可以进行自动发现监控

在这里插入图片描述
假如有很多业务需要采集，我们只需要在每个业务建立的时候加两个annotation，就可以被Prometheus里自动发现

这个值必须是true采取自动发现采集

在这里插入图片描述
定义metrics的路径和端口

在这里插入图片描述
同时还转换了几个新指标

在这里插入图片描述
这就是上面新家的指标标签

6.11 kube-state-metrics的监控

在这里插入图片描述
如果想看deployment状态，就需要用到kube-state-metrics指标

这里其实都是K8S里的资源类型

如果想要部署可以直接去runstandard目录

可以直接用里面的yaml文件部署

在这里插入图片描述

在这里插入图片描述

里面就是代码

这个文件里配置的默认空间是kube-system

把名称空间进行一个替换

如果是多个yaml的话，直接create 就ok了

在这里插入图片描述
查看跑起来的日志

在这里插入图片描述

作为采集的一员需要添加到Prometheus里去

并没用通过clusterip的方式，但是我们可以通过endpoint的方式注册的Prometheus里去

在这里插入图片描述
并没有annotation，如果加了annotation，是不是可以之前的服务发现自动注册到里面去

在这里插入图片描述

它的8080端口是可以提供抓取服务的

在这里插入图片描述

这样就实现了自助的服务发现

可以去把coredns先删除了，和后面的服务发现重复了
在这里插入图片描述

现在在接收请求

在这里插入图片描述
coredns就没有了

在这里插入图片描述
上面就是使用kube-state-metrics指标监控

现在就可以拿到整个K8S里running容器的指标

在这里插入图片描述

prometheus的基本安装和服务发现的使用就是上面这些

第7章 Grafana实现业务的可视化

7.1 grafana介绍及安装

prometheus通过exporter或者target里采集数据进行存储，有了数据就可以用promq language做查询，可以做展示
在这里插入图片描述

还是一样跑到app=prometheus这个label上

在这里插入图片描述

在安全上下文里，设置启动用户为root
在这里插入图片描述
这样就有权限写入root的目录

在这里插入图片描述

在这里插入图片描述

ingress已经创建好了

在这里插入图片描述
配置一下host

默认密码admin。admin

在这里插入图片描述

7.2 grafana配置及dashboard的导入

因为部署在K8S，所以grafana可以通过Prometheus的service的name去访问

在这里插入图片描述
添加数据来源

添加dashboard的三种方式
、

这里官方有做好的可以提供下载

在这里插入图片描述

直接输入id加载

在这里插入图片描述
，默认目录general，选择数据源

也有可能你导入的dashboard版本和采集到的exporter的版本的数据不匹配，就显示不了数据

在这里插入图片描述

上面是exporter的图表，可以尝试把promethues的图表拿来

数据显示不全，可能图表版本太老和现在的不适配了，就不建议使用了

在这里插入图片描述

7.3 kubeGraf插件的使用

exporter的面板是可以用的，但是Prometheus 的面板两年没更新了，导入发现没数据，和目前的K8S版本匹配不上
在这里插入图片描述
有一个插件可以丰富grafana的面板

在这里插入图片描述

core这些都是grafana已经装好的

在这里插入图片描述

它属于一个grafana的升级版本

可以用grafana命令行直接用

在这里插入图片描述

现在没有安装其他的东西

1.4.2有点兼容性的问题，可以指定1.4.1

默认装在/var/lib/grafana下

也可以直接安装zip文件，解压到目录

还需要一个插件，因为依赖一个饼图

安装好后，需要重启
在这里插入图片描述

启动日志看到已经注册了插件

在这里插入图片描述

还需要enable
在这里插入图片描述
先需要设置K8S集群

在这里插入图片描述
需要设置K8S的api地址，api信息

K8S的服务在default里就叫kubernetes

在这里插入图片描述
grafana在monitor空间里，那么grafana去访问就需要跨名称空间

在这里插入图片描述
跨名称空间访问，加一个.default就可以去访问了

不去校验证书合法性

kubectl是用的node证书做的认证

就是用的这里的证书

这里其实是做了base64编码

在这里插入图片描述

黏贴到这里

在这里插入图片描述
公钥证书

私钥部分也需要base64 -d

在这里插入图片描述

都复制到这里

这里是支持的dashboard

在这里插入图片描述
这是K8S节点相关的指标

在这里插入图片描述
这里是一个deployment状态

在这里插入图片描述
这就是通过插件方式导入更多内容

在这里插入图片描述

7.4 自定义监控面板

假如自己的业务需要自定义的监控面板和设置了自己的监控指标需要展示，导入之前的就比较难以满足要求，需要自定义
在这里插入图片描述
我们可以new一个数据图标，针对prometheus的指标去创建面板

可以试试node_load负载

如果想要实现上面的可以选择的

点击设置

在这里插入图片描述
设置名字

在这里插入图片描述
有一个variable变量

先加进去，创建一个node变量，可以再prometheus里引用

下拉框里的值需要定义query options

在这里插入图片描述
kube_node_info有我们node节点的信息

想要只取到名字

点击以后下面有一个预览

这里有正则，括号里就是我们要的展示的

+号或者*号都是贪婪匹配，一直往后面匹配了

在这里插入图片描述
换成问号就不贪婪匹配了，最少匹配

**是否为多选，
**

include all option 是否选择所有的选项

现在就已经显示选择节点了

加一个联动

在这里插入图片描述
这里是=等于。精确匹配，所以ALL不起作用

我们加一个=~，这样就可以了

在这里插入图片描述
保存一下，面板就好了

在这里插入图片描述
再加一个

下面有了prometheus的查询语言计算

在这里插入图片描述

可以参考别人怎么写的

在这里插入图片描述

7.5 Metrics指标类型与PromQL

每个样本代表当前时间的指标

在这里插入图片描述

查看node_exporter的指标

拿到数据是0.37，类型是guage类型

在这里插入图片描述
再看一次值就变低了

如果只想看master

支持正则

在这里插入图片描述
可以做一些运算

在这里插入图片描述
总内存-free的内存再除以总内存，就是内存使用率

在这里插入图片描述

counter类型主要用在cpu用的秒数，每种模式下，cpu的分片时间。
cpu=-代表核心数的ID

跟top 看的命令一样

id是比较空闲的意思，代表当前cpu利用是比较低的

在这里插入图片描述

这个时间记录会不断增加，因为是记录系统启动到结束分配给你的时间，除非重启机器，不然时间一直在加。如果要计算cpu使用率需要用到node_cpu_seconds_total cpu的分配的指标值来进行计算
在这里插入图片描述
系统运行以来，cpu资源分配的时间总数，单位秒

每一颗都有8种模式

在这里插入图片描述

如何把累计的数据转换成一个cpu利用率

在这里插入图片描述
4颗cpu，一分钟总共就是240s

现在空闲的是140s

那么cpu利用率就是这么算的

代表这一刻分配的总数

[1m]显示1分钟的

我们需要计算出idle里的增量
在这里插入图片描述
现在就变成了一个差值，过去一分钟内各个节点的一个增量的值

然后就要算出一个总量值和总时长
、
使用by加上分组

总量和剩余空闲的时间，用一个减法

其实就是这个

算成百分比利用率
在这里插入图片描述
先取出过去1分内每个cpu的idle时长,最大减去最小，得到增量

increase算出增量

下面有总量，上面的increase值除以下面的

上面的方法看起来比较繁琐，但是好理解，其实有rate和irate方法，帮你自动的完成了一些计算
在这里插入图片描述

在这里插入图片描述
irate直接拿出来数据了，它是拿最近的两个点，

也就是最近的两个点算差值和时间的差值，然后做一个除法，

在这里插入图片描述
这里的是每秒，也就是过去一分钟，每秒有0.9秒idle给k8s-master，也就是cpu利用率是百分之0.07

rate是取第一个和最后一个，求差值然后除以时间差，得出利用率，rate相比irate算的值比较平滑，因为算的是第一个和最后一个值的数据，所以用rate比较好
在这里插入图片描述

第8章 ConfigMap配置文件挂载的使用场景

8.1 单文件挂载到空目录

用configmap作为业务的配置文件挂载
在这里插入图片描述
创建configmap的时候通常有两种方式

configmap从文件里引用

制作配置文件

从文件里创建的configmap，key其实就是文件的名字，value就是文件的内容，这样就不用手动维护yaml文件了

在这里插入图片描述
configmap创建好后，需要准备一个应用去挂载

意思就是pod里的/etc/application里有一个配置文件application-1

key是文件名字，value是文件内容

上面是最简单的一种方式，如果configmap进行修改了，这个pod内部其实是可以感知到的
在这里插入图片描述

修改configmap

验证demo的pod里的配置文件，大约半分钟以后会发起一个同步的请求

比如prometheus可以通过一个软加载，可以reload
但是其他的可能没有软加载接口，就需要我们自己去重启了

在这里插入图片描述
在volume可以直接定义configmap名字去挂载，假如copnfigmap更新了，pod会感知到更新，prometheus和alertmanager都提供了软加载的接口，可以进行一个软重启

在这里插入图片描述

8.2 configmap多文件挂载

假设有多个配置文件想要挂载到同一个目录
在这里插入图片描述

需要再建立一个application-2的conf
在这里插入图片描述
把之前的先删除

现在写到一个configmap里

现在pod里就有两个文件了，因为是configmap挂载进去的

挂载的目录是application，这个目录本来就没有文件，但是假如挂载到pod已知的目录中。
在这里插入图片描述
这个目录是pod镜像自带的，想把application-1和2挂载到这个目录里

在这里插入图片描述

原来的内容就没有了，变成了application1和2，原来的文件被覆盖掉了，这不是我们所期望的

把configmap的内容挂载到目录里是不可用的，会覆盖原有的内容

8.3 挂载子路径

想要实现多个文件挂载不同路径
在这里插入图片描述
多了一个items数组，每一项都是key和path

在这里插入图片描述

是和这里对应起来的，key代表configmap
在这里插入图片描述
这里的path其实就是一个标识

这里可以直接指定挂载后叫什么文件

在这里插入图片描述

修改demo文件

这是我们希望的，原来的文件还在

文件都没有问题

在这里插入图片描述
想要实现不同目录挂载，还要求不覆盖掉里面的内容，直接去使用subpath的方式就可以

测试一下更新configmap，pod里是否会自动更新

添加两个新字段

使用subpath挂载到pod的内部的文件，不会自动感知到原有的configmap的变更
在这里插入图片描述

第9章 AlertManager告警精讲

9.1 Alertmanager配置详解

告警是Prometheus-server发出来的，由alertmanager做一个路由的处理，发给一个接收者，这个接收者可以配置很多种方式。
在这里插入图片描述

先安装altermanager

这是二进制启动的一个方式

配置文件格式

global是全局配置

在这里插入图片描述
alertmanager多长时间没有收到告警会被判断为resolved，意味着告警已经解决了

global里还可以配置邮件信息
smtp_from就是收到邮件的邮件来源

route代表所有告警信息的跟路由

按照什么信息去分组
在这里插入图片描述
这样alertmanager就可以根据alertname进行分组，也就是prometehues同时推送过来的10条告警数据，如果这10条告警数据alertname都是一致的，那么alertmanager会当成1条数据，做一个合并处理

假如在10点整，推送了10条alertname=nodeloadhigh的告警信息，那么一直到10点30秒之内，alertmanager都会去等待，看看Prometheus是否还会推送相同alertname的消息
在这里插入图片描述
30秒之后，45秒又发送了一批alertname相同的，这样就还等30秒。

一个报警信息发送成功了，多久时间没处理，也会一直发送这个消息，等待10分钟后，还会收到这个告警
在这里插入图片描述
定义了一个默认的接收者，都匹配不到会进到default里

**true会发送一个通知告知receiver恢复了
**

是一个无状态的

定义的configmap挂载到/etc/alertmanager下面

在这里插入图片描述
alertmanager也有一个管理页面

配置一下host

一般使用不多，除非做告警静默的时候会使用

9.2 Prometheus对接Alertmanager

在这里插入图片描述

是个数组，意味着可以对接多个alertmanager

在这里插入图片描述

配置文件是通过configmap的方式挂载到prometheus里的pod里

查看是否生效

在这里插入图片描述
目前已经生效，但是prometheus还没生效

这里叫enable-lifecycle，这个启动参数代表拥有软重启的功能

–后面的代表当作命令去执行

在这里插入图片描述

/bin/prometheus --help
开启这个以后，就开启了软加载

查看日志，进程里已经读取了最新的配置了

9.3 配置告警规则

想实现报警有三个流程，第一步安装prometheus，第二部配置prometheus和alertmanager对话，在Prometheus里创建告警规则
在这里插入图片描述

抓取时间和评估时间都改成30S了

在这里插入图片描述
Prometheus每隔30S做一次评估，这个配置文件定义了一些机器负载

现在等于要两个配置文件加载到一个configmap里，挂载到一个目录里

也就是在这个configmap里再加一项

在这里插入图片描述

这两个需要一致，因为这个key是作为文件名字的

在这里插入图片描述
这个group和alertmanager的group还不是一个概念，这里的一般都是做告警类型的汇总

在这里插入图片描述
机器的15分钟负载小于1，持续2分钟，才去触发，

node节点的一些指标都可以放在node_metrics里，下面的rule也是个数组，可以放很多，比如关于内存的

比如ALERT是Prometheus发送给alertmanager的告警，alertmanager之前配置的时候利用laertname作为分组的依据
在这里插入图片描述
alertmanager之前配置的时候利用laertname作为分组的依据

在这里插入图片描述
alertmanager会分成这样的一个个组的数据，这样就只剩下了两条告警信息

alertrmanager再把告警信息发送给receiver接收端

Prometheus的分组只是做一个逻辑上的划分，不影响alertmanager的分组

在这里插入图片描述
正常业务负载不会这么低，这样就有可能业务挂了，资源利用不高，可以加业务

groupname就是告警分组的名称

上面的alert这个名字就是被当作alertname，是划分告警的依据

正常来讲这里是prometheus的查询语言，一般都是布尔值，true说明满足条件了就触发报警，false就还没触发

在这里插入图片描述
评估持续两分钟都满足条件的才触发报警

这些信息一般alertmanager会做一个报警信息的理解

instance和value的值

在这里插入图片描述

修改configmap

在这里插入图片描述

先加rules
在这里插入图片描述
和整个prometheus的yaml同级

在这里插入图片描述

现在就已经有两个文件了

进行软加载

在这里插入图片描述
现在就有了alert的状态

目前还没有firing，firing了才会向alertmanager推送

inactive是不满足告警条件的,pending是还在观察周期以内

labels是Prometheus生成的信息

firing就是推送到alertmanager里去了

在这里插入图片描述
告警可以用ALERTS查询，firing代表已经推送的到alertmanager

在这里插入图片描述

alertmanager应该收到一些报警信息了

这里有一个报警错误

email登录没有权限

在这里插入图片描述

默认是不允许用代码作为第三方登录的

登录密码改成授权码

配置已经同步了

在这里插入图片描述
alertmanager也支持软加载

已经提示推送成功了

做了分组只收到一条告警信息，里面有三个，三个代表组内的告警条数

9.4 自定义webhook实现消息推送(上)

在这里插入图片描述
之前是通过邮件去接收信息的

receiver是一个default，但是配置的是email，使用邮箱的延迟性比较高

配置webhook

在这里插入图片描述 、webhook会收到来自alertmanager的请求

在这里插入图片描述

怎么让群里就一个人，把人拉进来，再踢出去，只留自己一个人

在这里插入图片描述

在这里插入图片描述
查看自己的出口ip段

可以对机器人进行测试

在这里插入图片描述

说明可以直接调api来进行消息推送

在这里插入图片描述

网上有很多这样的webhook

可以直接使用docker镜像，用go写的，看看配置yaml

在这里插入图片描述
这里有一个配置的示例

在这里插入图片描述
mention_all就是提醒所有人

在这里插入图片描述
mention固定的手机号

在这里插入图片描述

这是钉钉注册的手机号，并不是钉钉的用户名
在这里插入图片描述
**配置好了，会生成两个api的地址，api的path读取了配置文件里的key，等于可以一个webhook实现多个群聊的消息推送
**

在这里插入图片描述

9.5 自定义webhook实现消息推送(下)

配置文件有几个注意点，configmap挂载路径再容器内部，是在etc下面
在这里插入图片描述
但是webhook镜像里的配置文件是拷贝过来的，所以不能像prometheus一样挂载configmap，需要执行一个子路径挂载，subpath

可以先只保留一个发送对象，部署名称空间还是在mointor名称空间里

在这里插入图片描述
deployment和service

在这里插入图片描述

subpath挂载，还需要item，key只有一个，path也只有一个

在这里插入图片描述
subpath这两个地方是对应起来的

在这里插入图片描述
下面是service

在这里插入图片描述

创建一个deployment和service文件
在这里插入图片描述

**这里已经有了api的url
**

一个receiver可以有多个配置，还可以添加一个webhook的配置项
在这里插入图片描述

在这里插入图片描述

加了一个webhook

在这里插入图片描述

增加webhook地址

在这里插入图片描述

查看alertmanager有没有读到这个配置
在这里插入图片描述
进行软加载

在这里插入图片描述
现在就收到消息了

在这里插入图片描述
查看日志这些是node的告警

在这里插入图片描述

在这里插入图片描述
已经提示发一个消息给钉钉的

在这里插入图片描述
提示信息资源负载低于阀值

Prometheus报警的rules规则，summery和description

邮件的内容大致都是一样的

在这里插入图片描述
alertmanager一直在接收Prometheus的告警，然后进行聚合

发送了10分钟之后，假如没解决就还会发送

在这里插入图片描述
这里receiver还是默认的，其实还可以做路由

修改configmap以后，是动态30秒进行一个同步

9.6 实现基于标签的动态告警

在这里插入图片描述
定义一个接收者ops

global里的属性都可以在route里进覆盖

这是传过来的告警数据

s上面的这些key和value，可以在下面做匹配，就代表这些告警信息可以给这个receiver接收
在这里插入图片描述
可以在route链里进行匹配，匹配到的可以转发到设置好的receiver上去

原来只有这些内容

这里是key和value

在这里插入图片描述
之后又加了一条告警规则

又加了一个group

其实输入up可以看到所有prometheus的target

而且正常value的值都是1，为0代表有问题，宕机了

在这里插入图片描述
具体可以看到哪个job宕机了

这边都已经加了告警的级别了

在这里插入图片描述

这里匹配了相关的级别

一旦告警，会自动加上这个keyhevalue，我们就可以进行捕获
在这里插入图片描述
分别发到来两个接收者端

在这里插入图片描述
先添加prometheus的alert_rules

再添加三条告警规则

生效配置

等待30秒，重启prometheus

加一个机器人

在这里插入图片描述

再修改alertmanager的配置项
在这里插入图片描述

alertmanager其实是支持软重启的

开启alertmanager的软重启和配置文件路径，有可能以后需要

在这里插入图片描述
更新一下altermanager的配置文件

critical的报警消息都会发送到ops里

配置文件加载进来以后，就reload一下 altermanager

现在已经有2个firing，之前配置文件配置了3个告警在2个组（node_metrics,targets_status）下。
在这里插入图片描述

9.7 告警的静默和抑制

alertmanager可以通过group做分组，group分组以后，可以有效减少告警的发送，除了group，还支持抑制和静默，减少不必要的报警。
在这里插入图片描述

如果知道服务器已经宕机，上面的服务和中间件会一直触发告警，那就可以进行抑制规则

这里的意思就是，如果当node_down主机宕机而且告警级别是critical的时候，再有新的告警，如果级别也是critical，下面的node，接下面的看
在这里插入图片描述
上面的node就是类似里面的值

如果下面的label和上面nodedown产生的label是一样的，那么这个消息就被抑制。

如果上面概念模糊可以结合下面，现在两个告警都触发了，可以假设nodememory触发了，就去抑制nodeload的告警。
在这里插入图片描述
如果节点的内存使用高了而且级别是critical，就去抑制掉新来的告警，（抑制掉哪些告警）抑制掉新来告警级别是normal的而且新来的告警instance这一项和sourcematch里的instance一致

修改alertmanager-config

抑制规则是和global同级的一个配置
在这里插入图片描述

nodememoryusage触发了，就抑制掉nodeload告警

想要快速看到效果，可以修改重复发送到时间
在这里插入图片描述

配置文件同步了，就生效一下

在这里插入图片描述

master和slave1都被抑制掉了，因为满足了条件。

在这里插入图片描述

nodememoryusage发生了，去抑制告警级别是normal的，同时instalce的值要对等，也就像上面一样值看到 slave2的消息发送到钉钉了

到alertmanager可以看到，本来是三条，现在被抑制成1条了，nodeload

静默是可以在alertmanager的静默页面上直接操作的
在这里插入图片描述

从这个时间点去安静2小时

在这里插入图片描述

这样，2个小时以内就收不到它的告警了

**整个流程图，一条告警产生后，要去经过alertmanager的分组、抑制处理、静默处理。
**

在这里插入图片描述
**告警产生后，假如满足要求，就进入pending状态，满足for周期以后，进入firing，触发，发送到alertmanager，alertmanager进行一个alertgroup分组，分组之后经过inhibitor抑制，silence静默，router路由，Dedup去重，然后再去Send发送。
如果某一个环节中间被干掉了（抑制，静默，不匹，去重），那么终端都收不到消息。 **
在这里插入图片描述
主要思路，先装alertmanager：全局，路由，接收者

创建好后，prometheus去对接alertmanager，

然后去prometheus配置告警规则

自定义告警，对接webhook

钉钉消息的推送

可以给告警设置不同的级别设置，发送到不同的接收者里

在这里插入图片描述
路由树里去做一个匹配

在这里插入图片描述 然后再是静默和抑制

在这里插入图片描述
企业微信的webhook参考地址

alertmanager默认是支持企业微信的，但是只能发到企业微信的个人用户和组织，正规的组织是有一个id的，但是自己建的群聊，这种方式是不支持的。

9.8 Kubernetes Metrics API体系回顾

**根据自定义指标来实现业务的伸缩。之前是利用metrics server去调用cadvisor的接口，然后拿到容器的监控数据，提供了一个标准的api接口注册到metrics aggregator 也就是K8S标准的api里，然后可以用HPA去调用。
metrics server支持的指标很少，只有内存和cpu
**
在这里插入图片描述
除了标准指标，还可以看一下通用的指标，那就是prometheus里的内容

在这里插入图片描述
资源类指标的接口标准化实现，对应的实现就是merics-server

安装好metrics server以后会注册到K8s里api，HPA去调用就是调用整个api

可以看到metrics-server注册到这个api

通过聚合器metrics aggregator提供了一个标准的K8Sapi
在这里插入图片描述

apis代表非核心的api，核心的都是api开头的，聚合器加进去的非核心类指标都是放在apis

这样看到的node信息，metrics.k8s.io这个接口只能看到cpu和内存

在这里插入图片描述
根据它查node监控还是很方便的

在这里插入图片描述
**pod数据其实也可以看到，这样它其实是给HPA做了一个数据支撑
**

有时候可能cpu和内存指标不够，但是业务通用指标也想作为扩充的依据

metrics的数据是来自cadvisor的，它只是做一个数据整合暴露api给HPA使用
在这里插入图片描述
Prometheus也是原生只是拉数据，存数据的，把数据格式化提供api暴露出去是一个prometheus adapter识别器。它去调用prometheus，拿到指标之后也是用metrics aggregator K8S聚合器，把数据通过custom.metrics.k8s.io这样一个api暴露出去
在这里插入图片描述

这两个功能差不多，需要安装一个prometheus adapter

jq可以做一个json格式化

9.9 Adapter适配器部署及配置

在这里插入图片描述

在这里插入图片描述
建议提是用helm安装

在这里还是先选择用K8S的yaml安装

先把项目拉下来

在这里插入图片描述
但是分支是在master分支

切换到最新的release分支

在这里插入图片描述
项目deploy目录下有说明

申请证书文件和创建命名空间

准备证书

只要注册到K8S的聚合器里的服务，都需要支持HTTPs才能注册进去

生成了key和crt

K8S的secret不仅能保存私钥还能存储证书文件
在这里插入图片描述

一个crt和key

在这里插入图片描述
官方建议是安装manifests下所有的，但是不一定每一个都需要用到

在这里插入图片描述

service文件，注册到metrics里的服务需要启用https

apiservices文件

还需要建立一个rbac文件，需要去抓K8S的资源

在这里插入图片描述
apiserver里的deployment文件里面已经写好了serviceaccountname

在这里插入图片描述

做了一个集群的绑定
在这里插入图片描述

现在需要创建一个adapter，需要创建一个配置文件，它需要知道去采集哪些指标
在这里插入图片描述
把默认的名称空间替换掉，因为之前使用的monitor

这里写的地址很明显访问不到prometheus

在这里插入图片描述
改成能够访问的

直接创建整个目录下的

在这里插入图片描述
这边已经启动成功

在这里插入图片描述

现在就已经注册进去了，说明已经实现了K8S体系里标准的custom监控

在这里插入图片描述
实现者就是刚才创建的服务

在这里插入图片描述
能成功访问就说明安装的组件成功

下面就需要准备自定义指标给HPA使用了

9.10 自动伸缩业务应用部署及target注册

现在需要一个用例模拟业务，同样需要一些指标
在这里插入图片描述

这个镜像实现自己注册的一些Prometheus指标，其实是实现vts（虚拟流量监控管理）的nginx

在这里插入图片描述

在这里插入图片描述

暴露了这个url

这些指标可以当成target让Prometheus取抓取
之前使用了Prometheus的自动发现，所以我们可以用annotation，加两个声明去自动发现，自动注册成prometheus的target，如果没有指定path，prometheus会去读/metrics这个路径
在这里插入图片描述

在这里插入图片描述

现在就自动发现了

在这里插入图片描述
现在要根据这个部署的业务指标去扩容和缩容
这个指标是总的访问次数

9.11 Adapter配置自定义指标

比如可以根据访问2分钟超过10次就实现HPA的自动扩充
在这里插入图片描述
第一需要配置自定义指标

这里metrics是空的，所以adapter没有采集任何指标

在这里插入图片描述
Prometheus抓取到数据后就可以配置HPA规则

在这里插入图片描述
HPA请求的一个流程图，HPA去请求custom/metrics.k8s.io这个api，中间是有适配器的，adapter去采集prometheus，然后到最终pod的指标

在这里插入图片描述
之前cpu的采集是通过node_cpu_seconds_total这个指标的

rate方法是统计过去一段时间的每秒钟的请求次数

获取过去2分钟以内每秒的请求次数

在这里插入图片描述
如果有多个pod需要做一次汇聚

在这里插入图片描述
意味着这个pod在过去一分钟内每秒请求次数是0.133

这两项是一样的，所以单纯+是不对的，需要过滤

这个值才是真实的

告诉识别器，哪些自定义指标可以去使用

graph这里查询到的指标都可以用作指标告警的项
在这里插入图片描述

指定指标中的标签和K8S中资源的关系

在做endpoint的relabel的时候，把before_relabel里的内容做了一个替换，起了一个namspace叫kubernetes_namespace，kubernetes_name

其实就是deploy名字+podname，所以现在取出来的自动发现指标都有这几个值
在这里插入图片描述
这里就是告诉adapter这个namespace就是对应K8S的namespace，pod_name就对应K8S里的pod

HPA调用adapter接口的时候，HPA知道它需要拿K8S里的什么资源，adapter其实不知道自己的label代表哪一项

这里的正则匹配的是原生指标的名字，
在这里插入图片描述
这个指标目的是去查询过去2分钟每秒的一个请求数

转换之后就成了这个名字

这是告诉adapter去取哪些指标的

上面的值会自动带入到简写里

by通常是HPA去使用

只要是针对pod，那么groupby都会转成前面的名字
在这里插入图片描述
**第一步建立一个空的，
第二部。再到adapter，可以从哪些指标去获取（转成自定义指标。），
**

第三步，加上对应关系，让前面的K8Snamespace和pd有一个转换的依据。因为并不是每一个prometheus查询奥的结果中都是叫做kubernetes_namespace和kubernetes_pod_name
在这里插入图片描述
第4步，提供一个有业务含义的name，不能使用之前默认的 total了

然后，告诉adpater怎么去取值

在这里插入图片描述

没有软重启，只有删掉pod重建了

验证一下，现在调用这个api就有指标了

在这里插入图片描述 ‘
resources里有一个类型是namespace和pod

为什么会有两个

官方文档的解释，这个适配器会暴露指标。

每一个转换过的，都会去生成指标

把groupby里的内容用请求的内容进行填充

可以去访问这样的一个地址去获取真正的值
在这里插入图片描述

这是取到的值

133m其实是一个豪，除以1000就是0.133

在这里插入图片描述

9.12 配置HPA实现基于自定义指标的业务伸缩u

先去配置一个HPA
在这里插入图片描述
一般是去查询pod的值，阀值是10
作用的target是deployment的custom-metrics=demo，示例的业务应用

创建一个HPA

metricsname一定是和下面的匹配的

现在这个133m也就是0.1333是小于10的，不会去扩容 在这里插入图片描述
做一个压测

这样就获取到了149了

现在是每秒访问一次了

一定要加上协议和端口，ab命令不会自动填充

过去一分钟每秒49次

现在就开始扩容了

可以看一下adapter日志

在这里插入图片描述
adapter通过这个地址去拿数据

在这里插入图片描述

一般会用到prometheus=operator，它是去做集成和K8S做了几个monitor之类的，通过monitor对象去管理K8S的告警信息和规则，但是它和K8S耦合太紧密，K8S挂了，也就代表Prometheus监控报警也挂了

9.13 解决Adapter查询数据和直接查询Prometheus数据不一致

在这里插入图片描述
上面查到的数据和下面查的不一样
其实只想要total，但是它把上面的几个都加在一起了

在这里插入图片描述
因为configmap里其实是没有生效的

也就是这样，没有把过滤条件加进去

labelmatcher只会加上namespace和pod不会去加上host和code这样指定的内容，这也是为什么没有生效的原因

在这里插入图片描述
这么写会自动拼接上去

在这里插入图片描述

现在查询就是正确的了

48N6E

关注

0
点赞
踩
6

收藏

觉得还不错? 一键收藏
0
评论
2021/03/27 K8S集群日志与监控

第1章 k8s日志收集1.1 节点日志代理架构官网对K8S整个日志架构相关的介绍总体分为三种方式：使用每个节点上运行的节点级日志记录代理在应用程序的pod中，包含专门记录日志的sidecar容器将日志直接从应用程序中推送到日志记录后端日志驱动，定义一个大门daemon.json文件，去配置docker选项，log-driver默认会存储到一个文件里，假如不设置，这也是默认设置json-file是默认的一个日志驱动如果日志驱动是json-file，程序的输入输出会打到这个
复制链接

扫一扫

专栏目录