获取客户 Prometheus 监控数据
业务背景 在排查问题时,想通过Grafana看板查看用户的监控,只能靠拍照,效率低,质量一般,设计一个方案能够方便的将问题出现前24小时的监控数据拿到,在本地导入,就能够在本地Grafana方便的查看。Prometheus 本身只提供了API查询的功能并没有导出数据功能,自带的Promtool也只提供验证规则文件和配置文件,调试等。 参考文章 Analyzing Prometheus data with external tools Prometheus backfilling 方案一:使用API导出转换成CSV 使用API查询,将查询到的数据转换成CSV,刚好Grafana有插件能够将CSV作为数据源,经过实验后并不是特别顺利,能够读取到CSV,但没有成功绘制出图像。 总结 经过实验后并不是特别顺利,能够读取到CSV但没有成功绘制出图像,看板中部分查询语句中包含看板变量,CSV数据源无法实现看板变量。 方案二:拷贝Prometheus数据文件 Prometheus 按照两个小时为一个时间窗口,将两小时内产生的数据存储在一个块(Block)中。每个块都是一个单独的目录,里面含该时间窗口内的所有样本数据(chunks),元数据文件(meta.json)以及索引文件(index)。其中索引文件会将指标名称和标签索引到样板数据的时间序列中。此期间如果通过 API 删除时间序列,删除记录会保存在单独的逻辑文件 tombstone 当中。 Prometheus 为了防止丢失暂存在内存中的还未被写入磁盘的监控数据,引入了WAL机制。WAL被分割成默认大小为128M的文件段(segment),之前版本默认大小是256M,文件段以数字命名,长度为8位的整形。WAL的写入单位是页(page),每页的大小为32KB,所以每个段大小必须是页的大小的整数倍。如果WAL一次性写入的页数超过一个段的空闲页数,就会创建一个新的文件段来保存这些页,从而确保一次性写入的页不会跨段存储。这些数据暂时没有持久化,TSDB通过WAL将数据保存到磁盘上(保存的数据没有压缩,占用内存较大),当出现宕机,启动多协程读取WAL,恢复数据。 [mingming.chen@m162p65 data]$ tree . ├── 01E2MA5GDWMP69GVBVY1W5AF1X │ ├── chunks # 保存压缩后的时序数据,每个chunks大小为512M,超过会生成新的chunks │ │ └── 000001 │ ├── index # chunks中的偏移位置 │ ├── meta.json # 记录block块元信息,比如 样本的起始时间、chunks数量和数据量大小等 │ └── tombstones # 通过API方式对数据进行软删除,将删除记录存储在此处(API的删除方式,并不是立即将数据从chunks文件中移除) ├── 01E2MH175FV0JFB7EGCRZCX8NF │ ├── chunks │ │ └── 000001 │ ├── index │ ├── meta.json │ └── tombstones ├── 01E2MQWYDFQAXXPB3M1HK6T20A │ ├── chunks │ │ └── 000001 │ ├── index │ ├── meta.json │ └── tombstones ├── lock ├── queries.active └── wal #防止数据丢失(数据收集上来暂时是存放在内存中,wal记录了这些信息) ├── 00000366 #每个数据段最大为128M,存储默认存储两个小时的数据量。 ├── 00000367 ├── 00000368 ├── 00000369 └── checkpoint.000365 └── 00000000 无论是block数据还是wal数据,都是可以直接打包,转移到本地的Prometheus,需要注意的是版本问题和本地Prometheus不能有数据,如果本地监控数据目录不为空,那么导入时会出现问题(因为时间问题),只需要近期数据,太远的数据没有价值,可以通过block文件里面的meta.json查看时间戳 例如,在meta.json中,会看到这样的内容: ...