由于InfluxDB的磁盘已满，所以删除了旧数据
你好，我是InfluxDB初学者的石龟。
在Prometheus中，有一个名为RemoteStorage的功能，可以将收集到的指标保存到外部。
为此，我搭建了一个InfluxDB，但是由于挂载的磁盘已经满了，所以我先删除了一些不必要的旧数据，以应急措施。
关于
在这次工作中，我参考了以下文章。
InfluxDB的内部结构初步介绍 第一部分 | Yakst
前提 tí)
私はInfluxDBの素人です（重要
多分いい方法があったのかもしれません
あくまでもとりあえずの対応です
PrometheusとInfluxDBともにKubernetes上に展開しています
InfluxDBは専有ホストと言う形で展開しています
目标 (mù
- ディスクの空き容量を増やす
背景
在用于 Prometheus 远程存储的 InfluxDB 节点上，收到了关于磁盘空闲容量不足的警报。
因为不是关键任务，所以我打算等到下周来处理，但是进展似乎很快，磁盘在周末之前就会变满。
所以，暂时不去处理细节，先确保磁盘容量。
本来的情况是，我们可以使用保留期限策略自动删除数据等操作，但似乎我们忘记了这一点，结果应用了默认策略。默认情况下，会创建一个名为”autogen”的策略，该策略意味着数据将永久保存。最终，我们会应用正确的策略，但在此之前，首先进行现状恢复，删除旧数据。
试一试
确认状态
首先，我们先执行Pod来查看磁盘的容量。
root@influxdb-green-cdfb77948-d2tk9:/# df -h | grep influx
/dev/vdb 98G 83G 11G 89% /var/lib/influxdb
似乎已经消耗了接近90%。
最初想到的是通过整合早于特定日期的数据进行删除。
由于InfluxDB是时序数据库，因此每个序列都有一个必备的时间戳。
InfluxDB数据库保存数据点(point)。数据点由四个元素组成，即度量(measurement)，标签集(tagset)，字段集(fieldset)，和时间戳(timestamp)。
所以，我认为只需要提交一个相似的查询就可以简单地进行删除。但是，由于数据库内存在大量的测量数据，所以需要针对每一个数据逐个提交查询。虽然希望能够对数据库内的所有测量数据提交查询，但是由于我是个完全的门外汉，所以并不清楚这样做是否可行。
因此，我开始思考是否时间序列数据库中的每个目录也按照时间序列进行保存……于是我决定进行调查。结果，正是我所想的。
具体而言，数据库会在磁盘上按照以下的物理配置创建数据。
” 数据库目录 /db
” 保留策略目录 /db/rp
” 分片组（按时间），（逻辑）
” 分片目录 (db/rp/Id#)
” TSM0001.tsm（数据文件）
” TSM0002.tsm（数据文件）
” …
我将根据这个进行目录移动。
看起来/var/lib/influxdb/data/prometheus/autogen是相关目录。
/var/lib/influxdb是Pod中挂载的目录。
data/是存储数据的目录。
prometheus/是数据库名称。
autogen是保留策略名称的感觉。
在其下方，有以下这样的目录。
root@influxdb-green-cdfb77948-d2tk9:/var/lib/influxdb/data/prometheus/autogen# ls -la
total 20
drwx------ 5 root root 4096 Sep 9 00:00 .
drwx------ 5 root root 4096 Sep 14 11:17 ..
drwxr-xr-x 3 root root 4096 Sep 2 13:07 1
drwxr-xr-x 3 root root 4096 Sep 14 12:18 17
drwxr-xr-x 3 root root 4096 Sep 9 04:40 9
根据各个目录的时间戳，看起来文件名按照年纪较小的顺序是旧数据。
我们也来看看每个目录的容量。
root@influxdb-green-cdfb77948-d2tk9:/var/lib/influxdb/data/prometheus/autogen# du -h -d 1
22G ./17
24G ./9
23G ./1
68G .
暂且先删除1号目录，似乎在下周开始之前没有问题。
然而，直接删除目录是否会有问题呢？
虽然可能会导致元数据和完整性不一致的情况，但看了文章后似乎没有问题。
因为从存储中删除指针是非常昂贵的，所以InfluxDB将列指向的格式重新构建为按时间划分的块。当保存期限过期时，不需要进行大规模的更新操作来处理已持久化的数据，只需从文件系统上删除按时间划分的文件即可。
换句话说，根据RetentionPolicy进行的删除处理与在文件系统上删除文件是相同的。
因此，让我们尝试删除目标目录。
让我们试着删除
因为据说删除目录没有问题，所以我们马上来试试。
我们将删除这个目录。
root@influxdb-green-cdfb77948-d2tk9:/var/lib/influxdb/data/prometheus/autogen# rm -rf 1
我会检查一下磁盘的容量是否减少了。
root@influxdb-green-cdfb77948-d2tk9:/# df -h | grep influx
/dev/vdb 98G 83G 11G 89% /var/lib/influxdb
哎呀…？
看起来容量似乎没有变化。
这是关于Linux文件系统的问题，即使删除了进程正在使用的目录或文件，或者在ls等命令中看起来已经消失了，实际上它们并没有真正消失。
那么要想让它们消失，只需简单地重新启动进程即可。
换句话说，删除Pod即可。
这次我们建立了多个InfluxDB，并且分别从Prometheus连接到它们，所以只要逐个关闭一侧就没有问题。
root@influxdb-green-cdfb77948-d2tk9:/var/lib/influxdb/data/prometheus/autogen# exit
exit
command terminated with exit code 130
> kubectl delete pod influxdb-green-cdfb77948-d2tk9
pod "influxdb-green-cdfb77948-d2tk9" deleted
因为Pod已经被重新创建，所以我们将再次执行并确认一下。
k exec -it influxdb-green-cdfb77948-w24c4 bash [00:37:49]
root@influxdb-green-cdfb77948-w24c4:/# df -h | grep influx
/dev/vdb 98G 60G 34G 64% /var/lib/influxdb
无事容量减少了！接下来，我会确认是否可以继续正常执行查询。
root@influxdb-green-cdfb77948-w24c4:/# influx
Connected to http://localhost:8086 version 1.7.7
InfluxDB shell version: 1.7.7
> use prometheus
Using database prometheus
> show measurements
name: measurements
name
----
ALERTS
ALERTS_FOR_STATE
APIServiceOpenAPIAggregationControllerQueue1_adds
APIServiceOpenAPIAggregationControllerQueue1_depth
APIServiceOpenAPIAggregationControllerQueue1_longest_running_processor_microseconds
APIServiceOpenAPIAggregationControllerQueue1_queue_latency
APIServiceOpenAPIAggregationControllerQueue1_queue_latency_count
APIServiceOpenAPIAggregationControllerQueue1_queue_latency_sum
APIServiceOpenAPIAggregationControllerQueue1_retries
APIServiceOpenAPIAggregationControllerQueue1_unfinished_work_seconds
APIServiceOpenAPIAggregationControllerQueue1_work_duration
APIServiceOpenAPIAggregationControllerQueue1_work_duration_count
APIServiceOpenAPIAggregationControllerQueue1_work_duration_sum
APIServiceRegistrationController_adds
APIServiceRegistrationController_depth
测量的清单可以顺利获取，看起来没问题。我试着随便执行一个查询。
select * from up limit 2
name: up
time __name__ app app_kubernetes_io_instance app_kubernetes_io_name category chart cluster container_name endpoint heritage hostname instance istio istio_mixer_type job mentionID namespace node node_ip object_storage_cluster object_storage_env pod pod_name pod_phase pod_ready pod_template_hash prometheus prometheus_replica release service target value
---- -------- --- -------------------------- ---------------------- -------- ----- ------- -------------- -------- -------- -------- -------- ----- ---------------- --- --------- --------- ---- ------- ---------------------- ------------------ --- -------- --------- --------- ----------------- ---------- ------------------ ------- ------- ------ -----
1568450954073000000 up influxdb-green 10.233.123.211:8086 influxdb-green monitoring influxdb-green-cdfb77948-rptbs monitoring/k8s prometheus-k8s-0 influxdb-green 1
1568450960170000000 up prometheus-k8s web 10.233.77.129:9090 prometheus-k8s monitoring prometheus-k8s-0 monitoring/k8s prometheus-k8s-0 prometheus-k8s 1
>
非常之长，但查询能够顺利执行且返回了结果。
结束
接下来会强制执行非常严格的保留策略。
