一、监控的意义和分类
微服务的推广 架构的演进 需要完善的监控 先于用户发现 并解决问题
监控的分类
k8s探针 真实服务的状态
二、promethues架构
retrieval 检索上报数据的地址 去discover target(IP:port:endpoint) TSDB 时间序列数据库 httpserver 对外提供服务
pushgateway 接受间接性的启动 上报数据
数据模型
指标类型
监控数据的采集方式
在kubernets中汇报指标
数据的存储(TSDB)
数据的存储机制
数据索引
数据压缩
存储规划
promql
开启告警
大规模集群监控 thanos
三、promrthues服务发现机制
promethues架构
主动方式 pull的方式抓取数据 去找endpoint拉取数据
promsql查询、展示指标
promethues典型配置
promethues 是有状态应用 如果放在容器中 需要挂载一个盘 用来存储数据, 防止重建数据丢失
全局配置
evaluation_interval 评估周期
- 评估规则 判断标准, 如果命中 就报警
告警配置, 配置 altermanager的地址和端口
altermanager提供一个endpoint promethues_server将告警 推送到altermanager告警中心
告警规则
抓取目标的配置
promethues_server 读取这些配置地址 去拉取数据
promethues的服务发现
静态环境
- promethues 配置IP的话 静态的配置 直接抓取就可以
动态环境 云原生场景
- 需要去定位pod
- pod迁移 驱逐问题
- pod的IP会变
服务注册中心
- 存储所有监控目标的信息 提供存在指标的节点信息
服务生产者 ---> 把自己注册到服务中心 服务消费者 --->请求服务中心 要地址
基于文件的服务发现 静态的服务发现
发现类型 配置为 file_sd_configs 通过文件的形式去做服务发现
基于promethues的服务发现
去什么地方取? 提供apiserver 去查询有哪些target
取哪些信息? 覆盖抓取label中的值
action
- keep 保留指标
- drop 删除指标
relabel机制
relabel
目的
- 过滤查询 数据打标签 辅助进行数据查询
- 标签标准化
relabel机制
relabel config
按照环境 按照业务、团队
保留场景
- 100个endpont的时候 需要选择特定的endpoint
替换抓取的任务端口
altermanaer告警
用户没有发现的前提下 发现问题 问题进一步恶化 将问题解决掉
微服务之间的依赖关系
告警困境
把握度 什么时间应该告警
节点故障自愈 自愈的告警 不需要告警了 发消息通知就行
告警规则
altermanter架构
同一个alter 不要重复告警 可以配置一个静默期
