福大大架构师每日一题

告警回调能用来做什么报警回调执行命令过程回调重启服务实战。

alertmanager代码解析gossip集群通信pipline流水线处理。

gossip流言算法信息同步过程演示Gossip 的特点（优势）Gossip 的特点（的缺陷）

alertmanager 单点问题alertmanager 引入gossip协议来同步节点间的信息配置alertmanager 高可用并测试。

prometheus告警trigger单点问题trigger模型简化 海量的job交给有限的work执行动态分片方案改造之前的prome-shard代码。

源码解读prometheus把record记录当做和alert一样处理进行instant_query查询当前点，如果是alert则走报警的流程通过本地缓存和这次查询对比更新alert的状态pending代表触发了但是还没到配置的for时间firing代表触发了inactive代表恢复或者策略已删除最终调用alertmanager的 api发送过去。

使用OpenResty的数据源 不会影响未配置预聚合的图因为只是nginx代理了一下，如果redis中没有要替换的expr就会以原查询ql查询。

编写lua脚本做promql的检查替换nginx拦截prometheus查询请求使用lua处理。

confd，它提供了一种新的集成思路confd的存在有点类似于快递员，买了东西不需要自己到店去取货了confd这个快递员回把货取过来，然后送到家里，并且通知你货已经送到了confd简介修改confd源码增加静态分片功能配置prometheus record的confd。

将重查询记录增量更新到consul中同时将record记录更新到本地更新到redis中。

pre_query项目配置文件设置ansible-copy拷贝日志文件解析日志文件并判断重查询。

需求分析架构设计。

prometheus把record记录当做和alert一样处理进行instant_query查询当前点，如果是alert则走报警的流程如果是record，那么将查询到的结果写入tsdb，新的metric_name使用配置中设置的record名字，同时保留原有结果的label预聚合原理总结源码解读。

downsample降采样可以降低查询数据量prometheus原生不支持downsample实时查询/聚合 VS 预查询/聚合的优缺点实时查询/聚合条件随意组合，性能差预查询/聚合 性能好，聚合条件需要提前定义prometheus的预查询/聚合配置举例。

来个 最直观的对比name=~“.a.”}就是因为查询所有指标的12小时数据，前端浏览器卡死了，后台机器load1直接飙涨到18通俗的说就是返回的series或者查询到的series数量过多查询表现出来返回时间较长，对应调用服务端资源较多的查询数量多少算多 10w~100w一般我们定义在1小时内的range_query 响应时间超过3秒则认为较重了因为tsdb都有压缩算法对datapoint压缩，比如dod 和xor那么当查询时数据必然涉及到解压放大的问题。

如之前举例的文件服务发现],},],通过查询的时候按照 stree_gpa等标签 聚合，就可以得到每个业务组的cpu和内存数据纵向聚合VS横向聚合用最近1天的内存平均使用率等出业务资源利用率报表为了降低成本合理配置资源。

解析参数设置超时并设置opentracing根据queryEngine初始化query并解析promqlexec函数先设置 ExecTotalTimeexec函数进入队列排队 设置并计算 ExecQueueTimeexec函数 设置 EvalTotalTime 并执行execEvalStmt函数execEvalStmt函数 准备存储上的querier+select series 设置并计算QueryPreparationTime。

代码位置 web\api\v1\api.go5大数据查询接口instant_query查询一个点range_query查询一段时间数据series查询 全量标签数据labels查询 标签key集合label values查询。

获取配置文件 config获取运行信息 runtimeinfo编译的信息 buildinfotsdb统计信息 tsdbwalreplay的信息target统计信息获取metrics的元信息。

生命周期控制相关reload 热更新配置pprof相关prometheus pprof 查看火焰图存储操作相关。

数据的长期存储没有解决高可用性和扩展性没解决Operator 是特定于 Kubernetes 的应用程序 (pod)，可自动配置、管理和优化其他 Kubernetes 部署。它们作为自定义控制器实现。Kubernetes 操作员封装了部署和扩展应用程序的专有技术，并直接执行与 API 通信的算法决策。Prometheus，它定义了所需的 Prometheus 部署。Operator 始终确保与资源定义匹配的部署正在运行。ServiceMonitor，它以声明方式指定应如何监视服务组。

monitoring-alertmanager-main-rules.yaml alertmanager 运行相关monitoring-kube-prometheus-rules.yaml prometheus target相关monitoring-kube-state-metrics-rules.yaml ksm指标monitoring-kubernetes-monitoring-rules.yaml 服务组件指标。

db使用 sqlit，volume类型为emptydir 无法持久化，pod扩缩就重新创建通过configMap设置的prometheus DataSource通过 prometheus-k8s svc对应的 域名访问下面对应两个prometheus容器，有HA各个dashboard通过 configMap挂载，grafana动态加载，不能修改内置了22张大盘图，包含预聚合指标，很全面。

prometheus 采集分析。

kube-prometheus 版本✔✗✗✗✗✔✗✗✗✔✔✗✗✗✔✔HEAD✗✗✔✔安装部署，其实是很方便的，我们的网络环境如何利用阿里云构建国外的镜像svc改为nodeport检查页面grafana非常炫酷的大盘图。

根据配置的查询地址 创建查询prometheus数据的clients，给后面的报警和预聚合使用新建本地tsdb，为了写入用户配置的预聚合指标结果根据配置的alertmanager 信息进行初始化操作并启动发送任务使用查询数据的clients初始化ruleManager，并调用prometheus 的ruleManager Run执行任务如果用户配置了对象存储，就开启shipper将预聚合的指标定期传上去。

定时扫描对象存储的block，干2件事压实通过plan拿到所有要压实的block通过对象存储下载block底层调用prometheus的level-compact压实将新的block上传到对象存储降采样通过对象存储下载block底层调用降采样函数降采样将新的block上传到对象存储。

根据配置的后端存储grpc地址初始化 proxyStore用proxyStore初始化apiapi完全实现了prometheus的v1查询接口根据http查询，调用proxyStore 的grpc方法，底层就3种方法SeriesLabelNames查询各个store ，store又对应对象存储，最终的查询由对象存储完成同时如果不带matcher查询标签信息，又可以使用store本地的 index-reader缓存。

启动时同步对象存储的各个block元信息到本地，并且将索引数据也同步过来启动定时同步的任务封装prometheus查询的grpc服务，对外提供服务，底层调用配置的对象存储查询。

err!= nil {} else {return nil})sidercar 都干了什么执行prometheus的探活继承所有prometheus v1的查询方法，封装成http-client用上面的http-client 注册grpc-server，外部可以调grpc方法通过sidecar查询prometheus数据初始化对象存储的bkt用bkt创建shipper对象，扫描prometheus data目录下的block，进行上传到对象存储。

项目地址文档地址Sidecar：连接到 Prometheus，读取其数据进行查询和/或将其上传到云存储。Store Gateway：在云存储桶内提供指标Compactor：对存储在云存储桶中的数据进行压缩、下采样和 清理过期数据Receiver： 从 Prometheus 的WAL接收远程写入数据，将其公开和/或将其上传到云存储Ruler/Rule: 针对Thanos 中的数据 进行告警或预聚合工作，进行展示和/或上传。

m3db资源开销无需ssd读写峰对cpu和内存的开销聚合选择不要直接在m3coordinator 中开启聚合利用m3aggregator 做downsamplem3db 读写一致性m3db运维操作。

默认池低水位为什么不是0:因为 从水位判断到tryFill中间的并发请求使得最后tryFill开始时低水位可能低于0.3火焰图中的tryFill消耗了40G内存不是一次性的，类比右侧thriftrpc27，属于累加内存消耗值一次性的内存消耗肯定没有这么多：每次加油时内存消耗低于初始化所以可以得到结论，oom是因为在当时byte_pool频繁的get消耗，然后tryFill频繁的加油导致内存分配所以根本原因还是查询导致的m3dbnode oom时内存火焰图追查源码调用。

单机版m3db安装安装和prometheus 通过remote_read整合配置文件解读。

M3最初是在优步开发的，目的是提供对优步业务运营，微服务和基础架构的可视性由于M3具有轻松进行水平扩展的能力，因此它为所有监视用例提供了一个集中式存储解决方案。m3db自己的定位m3db自己的架构m3db自己的组件。

prometheus的proto编码 和压缩带retry的写入管理器写入的post函数判断是否是可恢复的错误决定是否重试。

remote_read代码需求查询一个标签的值列表查询一段时间的数据remote_read代码需求查询一个标签的值列表查询一段时间的数据通用的查询series方法查询一个标签的值列表查询一段时间的数据。

项目要求通过remote read读取prometheus中的数据通过remote write向prometheus中写入数据准备工作新建项目 prome_remote_read_write设计prometheus 数据源的结构初始化。

现象 remote_read查询series比直接查询要慢很多remote_read源码解析remote_read代码中有遍历往 heap中push的动作，是为了去重deduplicates内层调用又会遍历Sample导致速度比较慢无论是何种查询，都应该避免过多series，应该多使用聚合。

prometheus 低成本存储multi_remote_read方案说明数据重复怎么办配置prometheus remote_read prometheus。