获取客户 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 查看时间戳。 ...