获取客户 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中，会看到这样的内容： ...