一、问题描述

测试环境与生产环境中，Influxdb每日本地备份的数据文件磁盘占用大小差距过大。

这是生产环境当前的数据备份：

而这是测试环境当前的数据备份：

二者都是刚用不久，并且生产环境数据量远远多余测试环境，但生产环境上日备份的数据仅需要100k左右，而测试环境日备份的数据竟然需要400M左右。

在谷歌进行搜索，由于2.0版本最近才发布，用户量比较少，所以基本上找不到相关的问题，故自行对其排查了一番。

二、问题排查

首先从源头开始查起，看究竟是备份的哪些数据占用了磁盘，于是手动进行一次数据备份，可以观测到一些关键信息：

需要注意的时，这些id极为重要，V1版本的influxdb是以桶名作为数据存储文件夹，而在V2版本则是以随机ID作为数据存储文件夹，这样的好处是可以将不同组织相同名称的桶存放在同一目录下，不需要考虑桶名碰撞的问题。

继续进行跟踪，可以看到备份打包完成的gz文件：

竟然有些文件占用了几十M大小，然而测试环境并没有多少数据，所以很明显，磁盘就是被它占用的，把文件进行解压：

而id：52fd932980e389af 对应的bucket就是 _monitoring。

进入influxdb控制台查看：

生产上的机器并没有这些数据，果然，就是它一直在记录本机和本服务的一些信息，并且在数据进行备份时也会把数据打进去。

对我而言，我并不需要备份这些服务的信息。

influxdb V2 连日志文件都没有，什么东西都只能在控制台找了。

然后在控制台发现了这么一个东西，发现它似乎监控了_monitoring这个bucket，也不知道是什么情况下无意打开的。

将它删除后，再清理一下_monitoring以前的数据，就ok了。

其实官网上有对scraper这个组件的描述：Scrape data using InfluxDB scrapers | InfluxDB OSS 2.0 Documentation

只有用到过它，才能真正了解它。