2021/03/27 K8S集群日志与监控
第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这样指定的内容，这也是为什么没有生效的原因
这么写会自动拼接上去
现在查询就是正确的了
2021/03/27 K8S集群日志与监控相关推荐
- K8S集群部署kube-Prometheus监控Ceph（版本octopus）集群、并实现告警。
K8S集群部署kube-Prometheus监控Ceph(版本octopus)集群.并实现告警. 一.背景描述 公司K8S集群后端存储采用的是cephfs,测试环境经常性出现存储故障,虽然最后都解决了 ...
- Promethus搭建 K8S 集群节点资源监控系统
对于集群的监控一般我们需要考虑以下几个方面: Kubernetes 节点的监控:比如节点的 cpu.load.disk.memory 等指标 内部系统组件的状态:比如 kube-scheduler.k ...
- k8s笔记22--使用fluent-bit采集集群日志
k8s笔记22--使用fluent-bit采集集群日志 1 介绍 2 部署 & 测试 2.1 获取安装 fluent-bit 2.2 直接采集日志到 es 集群 2.3 直接采集日志到 kaf ...
- 12c集群日志位置_Kubernetes(k8s)那些套路之日志收集
准备 关于容器日志 Docker的日志分为两类,一类是 Docker引擎日志:另一类是容器日志.引擎日志一般都交给了系统日志,不同的操作系统会放在不同的位置.本文主要介绍容器日志,容器日志可以理解是运 ...
- 从零搭建阿里云托管版k8s集群-容器日志采集（八）
相信很多人都知道可以自己搭建elk来方便的收集日志,查询日志.虽然搭建elk并不是十分复杂,可对于一般的开发人员来说,尤其是对linux操作不是很熟练的人,是一项相当有难度的工程.所幸现在阿里云已经为 ...
- 实战：部署一套完整的企业级高可用K8s集群(成功测试)-2021.10.20
更新时间 2022年10月14日18:17:39 实验环境 实验环境: 1.win10,vmwrokstation虚机: 2.k8s集群:3台centos7.6 1810虚机,2个master节点,1 ...
- 3、使用二进制方式搭建K8S集群
文章目录 一.安装要求 二.准备环境 三.系统初始化配置 四.部署 Etcd 集群 4.1 准备 cfssl 证书生成工具 4.2 生成 Etcd 证书 4.3 从 Github 下载二进制文件 4. ...
- 总结 Underlay 和 Overlay 网络,在k8s集群实现underlay网络,网络组件flannel vxlan/ calico IPIP模式的网络通信流程,基于二进制实现高可用的K8S集群
1.总结Underlay和Overlay网络的的区别及优缺点 Overlay网络: Overlay 叫叠加网络也叫覆盖网络,指的是在物理网络的 基础之上叠加实现新的虚拟网络,即可使网络的中的容器可 ...
- k8s集群二进制部署 1.17.3
K8s简介 Kubernetes(简称k8s)是Google在2014年6月开源的一个容器集群管理系统,使用Go语言开发,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容 ...
最新文章
- 在Eclipse中使用Maven 2.x指南
- Android的服务（Service）（三）Service客户端的绑定与跨进程
- python3 随机数函数
- C语言 十六进制整数字符串转十进制整数
- 每日一笑 | 坐牢吗？学编程那种~
- 横跨2017-2018，云效Work Like Alibaba系列直播第五期盛大开启
- 云+X案例展 | 传播类：九州云 SD-WAN 携手上海电信，助力政企客户网络重构 换新颜
- Oracle物理的体系结构
- linux软件安装完成信号,Linux信号机制解析
- Jave_erhui
- 【特效】UE4 Niagara 制作爆炸特效
- kinect体感绿幕抠像,AR虚拟互动拍照,体感抠像拍照
- 2019微信公开课张小龙演讲全文
- 半闲居士视觉SLAM十四讲笔记（3）三维空间刚体运动 - part 3 旋转向量、欧拉角、四元数
- UVA 10815 安迪的第一个字典
- RTX3070Ti和RTX2080Ti哪个强 RTX3070Ti和RTX2080Ti参数对比哪个好
- 大数据分析：数字化企业转型的关键
- Comparable与Comparator的再学习与思考
- 自己做网站要买服务器,自己做网站要买服务器
- MySQL时间戳和时间的获取/相互转换/格式化