一、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接口处。