【无标题】

2024-06-16 01:42:03
开发
6

一、Prometheus 核心组件

1、prometheus-server端

① scrape 采集器

② prometheus-TSDB 时序数据库

③ service discoery：自动发现

1）静态服务发现

2）基于DNS的SRV服务发现

3）基于K8S 服务发现

4）基于consul 服务发现

5）基于文件服务发现

④ UI ：表达式浏览器

⑤ PrmoQL：这个主要是产生告警通知的语言

2、Prometheus 指标暴露器

① exporters ：常规任务的指标暴露器，将数据收集，并转换位prometheus-scrape（prometheus采集器）可以收集的格式（HTTP）

② pushgateway：短周期任务/不方便固定周期获取数据的数据采集

③ instrumtations : 服务内建的指标暴露器

3、alertmanager：告警模块，

prometheus 生成的告警信息会通知给alert，alert 根据rules 规则和自定义的告警模块、告警路由来对接钉钉、邮件、告警平台/告警中心等渠道

二、Prometheus 指标暴露器特性

1、prometheus 数据采集模式

① prometheus 默认采取pull 的模型采集数据

② prometheus 的pushgateway 使用push的方式采集数据

PS: 使用push的原因在于，生产中在进行采集数据的时候，往往未必能固定周期获取数据，甚至我们需要抓取的是在某一特殊场景，比如并发时产生的数据，这类的数据只适合在产生时传递给pushgateway网关，然后再push 到prometheus ，而不适合有规律的，周期的直接pull

三、Prometheus 的数据模型

1、 counter :计数器

计单调递增

2、 gauge:仪表盘

有起伏特征的

3、 histogram：直方图

在一段时间范围内对数据采样的相关结果，并记入配置的bucket中，他可以存储更多的数据，包括样本值分布在每个bucket的数量，从而prometheus就可以使用内置函数进行计算: 计算样本平均值:以值得综合除以值的数量计算样本分位值:分位数有助于了解符合特定标准的数据个数，例如评估响应时间超过1秒的请求比例，若超过20%则进行告警等

4、 summary:摘要

histogram的扩展类型，它是直接由监控端自行聚合计算出分位数，同时将计算结果响应给prometheus server的样本采集请求，因而，其分位数计算是由监控端完成

四、Prometheus基础元素

1、什么时指标，什么是标签、什么是样本值

① 基本含义

指标大概的含义指的是具体的一个监控项，比如CPU使用率、内存使用率，为了表示具体的、唯一的一个资源或者一组资源，使用比如instance（实例）等于某个节点IP，CPU等于某个CPU标签"core=1"，这是标签和标签值，最后通过过滤得到的CPU使用率的值，这就是样本

②、示例

比如 node1节点CPU负载的需求中

写法就是cpu_usage{core='1',ip='192.168.226.128'} 14.04

cpu_usage就是指标

core=1 ip=”192.168.226.128“ 这是标签和标签值

14.04 就是得出的样本值

五、Prometheus 主要监控什么（SRE 五个黄金指标）

1、主机资源

正常的CPU、内存、I/O、磁盘使用率、饱和度、空闲率、I/O速率、包括主机的文件句柄数

2、服务资源

常规服务状态、以及一些服务的特性，比如redis中的key的数量、I/O压力、包括rdb aof日志、buffer/cache占用、socket

3、业务资源

主要是业务逻辑，比如入口流量，业务数据产生的波动（这个看你的业务来说）API 接口处的流量、状态等等

可以使用agent plugin、包括pushgateway的方式来收集

六、Prometheus 怎么收集、收集哪些K8S指标

1、容器基础的资源

使用kubelet内置的cadvisor metrics 接口来收集容器CPU、内存利用率等，发现类型的话，直接使用k8s_sd node级别直接访问node_ip

2、K8S资源指标

采集源主要是kube-stats-metrics（ksm），可以通过监控kube-stats-metrics来监控k8s，还包括Pod抓昂头和pod 等待就绪状态，还有namespaces情况

3、查看组件状态，还是通过服务组件的cadvisor-metrics 接口查看api-server、scheduler、etcd、coredns等等一些服务的请求延迟

PS：原理是根据kubelet 、api-server等信息的管理、收集、监控汇总的特点来进行采集的

七、Prometheus 怎么监控K8S（二）

1、Prometheus Operator监控k8s集群

Pod监控

之前在安装kubelet的时候有讲过，cadvisor 是内嵌在 kubelet 二进制中的，统计所在节点各容器的资源(CPU、内存、磁盘、网卡)使用情况的服务。 kubelet的节点使用cAdvisor提供的metrics接口获取该节点所有Pod和容器相关的性能指标数据。也就是kubelet会暴露两个接口地址： https://NodeIP:10250/metrics和https://NodeIP:10250/metrics/cadvisor分别返回 kubelet 和 cadvisor 的 metrics。需要注意的是，用浏览器直接访问是不行的，其中还设计到一些授权的问题，具体可以移步到之前安装kubelet的文章。

Node监控

Prometheus Operator以DaemonSet的形式在k8s集群的每个node节点上都部署一个node-exporter来采集各个node的资源利用率信息。

资源对象监控

Prometheus Operator部署了一个kube-state-metrics来采集k8s中各种资源对象的状态信息，通过relabel重打标记来自定义指标项

2、使用Grafana可视化展示Prometheus监控数据

没错，其实上面已经展示过了，因为Prometheus Operator部署完成之后的grafana中自带了模板

###以下部分示例的是JAVA业务的JVM

 job_name: jvm                          #自定义监控JAVA JVM 
  scrape_interval: 5s
  kubernetes_sd_configs:
  - role: endpoints
  relabel_configs:                      #重新打标
  - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_jvm] #标签源1
    action: keep
    regex: true                     #使用正则
  - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port]  #标签源2
    action: replace
    target_label: __address__           #重新达标1
    regex: ([^:]+)(?::\d+)?;(\d+)       #正则匹配
    replacement: $1:$2                  #标签组合
  - source_labels: [__meta_kubernetes_service_name]     #标签源3
    action: replace
    regex: (.+)
    target_label: application
    replacement: $1
  - action: labelmap                                    #定义新标签
    regex: __meta_kubernetes_service_label_(.+)         #正则匹配新标签
 ##自定义监控JVM ：先选择prometheus的kubernetes_sd_config的yml文件（K8S的target服务发现模式） 关联的endpoint ，然后选择relabel的标签源（多个），使用正则匹配所需要输出新标签，最后利用action定义新标签名（重组）

##PS:::::因为有些java应用业务逻辑出错了之后，业务是不健康的，但是JAVA程序是可以正常跑的，所以有的时候，我们公司的promethues是没法观测到这部分的监控指标，所以我们会配合探针（就绪）的机制，来监控此类的业务健康状态

3、prometheus 监控API


config:
     testset: 'APP API monitoring'  #描述性信息，代码中未使用
     timeout: 15 #调用API的超时时间
     scrape_interval: 15 #检测API的时间间隔，单位为秒
     base_url: 'https://app.×××.com/app' #API接口的URL，我的项目是微服务，这个app是微服务的url前缀
token:
     base_url: 'https://app.××××.com/app' #获取token的URL地址
     url: '/login/pwdLogin' #获取token的接口地址
     method: "POST" #获取接口的HTTP方法
     body: '' #获取接口时在post请求的payload内容
     params: {"mobile": "17320491234","pwd": "your_password"} #这个是在请求的URL中的参数列表，HTTP请求的参数可以放在URL里面，也可以放在payload里面，我的应用时放在URL里面的
     headers: {} # POST请求的header 
     token_key_in_request: 'authKey' # 在post请求中后端认证时在header里面读取的值名字，后面截图说明
     token_key_in_response: 'token' #在用户第一次登录后返回数据里面token的值的名字，
verify:
    base_url: 'https://app.****.com/app' #验证token的URL,因为token一般都有较长时间的有效期，不能监控一次就取一次token
    url: '/user/userAddress/list' #验证token的接口地址
    method: "GET" #验证token的HTTP方法
    token_key_in_request: 'authKey' # header里面token值的名字
    headers: {'Content-Type': 'application/json'} #HTTP请求的header
cases: #所有需要监控的API接口地址
- UserAddress:  #接口名字
    url: '/user/userAddress/list' #接口地址，相对于config段里base_url
    method: "GET" #请求方式
    headers: {'Content-Type': 'application/json'} # HTTP headers
- UserBalance:
    url: '/user/getBalance'
    method: "GET"
    headers: {'Content-Type': 'application/json'}
- UserRecord:
    url: '/user/userRecord/getTypeList'
    method: "GET"
    headers: {'Content-Type': 'application/json'}
- UserBankCard:
    url: '/user/bankCard/payList'
    method: "GET"
    headers: {'Content-Type': 'application/json'}

###PS：：自定义API的接口名字、URL 位置、method方法、还有头部信息，然后使用我们prometheus的CRD来配置告警规则。

八、prometheus 告警配置，你们怎么配置的（altermanager）

1、Alertmanager 的主要职责

① 接受Prometheus-server端的告警通知，然后根据告警路由选择告警对象，同时设置告警信息的属性，比如，是否使用静默，选择合适的告警路由的分组等等

2、Alertmanager工作流程

① alertmanager 将告警推送至sendmessages，然后加载告警信息，将信息存储在数据库内（同时存储告警信息的属性）

② 然后根据alertmanager的告警路由与合法性进行分组，再推送至不同的告警receiver（告警“接收人”）的API接口处。

原文地址:https://blog.csdn.net/MCB134/article/details/139710096 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：https://www.suanlizi.com/kf/1802033842211655680.html 如若内容造成侵权/违法违规/事实不符，请联系《酸梨子》网邮箱：1419361763@qq.com进行投诉反馈，一经查实，立即删除！

阅读全部