Disk Full 처리 , 서버에서 로그만 찾겠다는 마인드는 버려라!!

disk가 97%가 차서 연락이 왔다.
그래서 로그들을 확인하고 지워줬는데..음? 변화가 없네 뭐지..-_-;

sudo fdisk -l /dev/sda4
Disk /dev/sda4: 468.1 GB, 468081180672 bytes, 914221056 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

 df -h
/ <--- 이부분에 지금 421G가 쌓여져있다는 걸 확인.
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         16G     0   16G   0% /dev
tmpfs            16G     0   16G   0% /dev/shm
tmpfs            16G   60M   16G   1% /run
tmpfs            16G     0   16G   0% /sys/fs/cgroup
/dev/sda4       436G  421G   16G  97% /
/dev/sda2      1014M  123M  892M  13% /boot
/dev/sda1       200M   12M  189M   6% /boot/efi
tmpfs           3.1G     0  3.1G   0% /run/user/1000
tmpfs           3.1G     0  3.1G   0% /run/user/500

 

그래서 로그 관련 부분을 지워줬는데....퍼센트는 그대로네..음..??

sudo du -h --max-depth=1 | sort -h

6.2M	./etc/nginx
7.4M	./opt/MegaRAID
8.1M	./etc/udev
12M	./boot/efi
19M	./etc/selinux
21M	./opt/SE
23M	./usr/include
39M	./etc
55M	./usr/sbin
57M	./run/log
60M	./run
68M	./usr/src
78M	./usr/libexec
101M	./boot
123M	./usr/bin
136M	./var/cache
137M	./home
137M	./home/deploy
171M	./var/lib
181M	./opt/tool_huawei
209M	./opt
317M	./usr/lib64
343M	./daum/program
344M	./daum
375M	./usr/local
507M	./usr/share
668M	./var/log
850M	./usr/lib
973M	./var
2.4G	./usr
18G	./data3
18G	./data3/es_data
20G	./data2
20G	./data2/es_data
20G	./data4
20G	./data4/es_data
22G	./data1
22G	./data1/es_data
83G	.

그렇다...서버에서 백날 지워줘봐야..반응은 없다!!
이유는 바로 elasticsearch이기 때문이다..

이녀석은 검색엔진으로써 인덱싱을 하고 있다.
우리가 지워준건 단지 물리적인 데이터일 뿐이였다.
실질적으로 내부적으로 인덱싱된 데이터를 지워주지 않아서 반응이 없었던 것이다.

인덱스 뭐가 있노?
알아내는 방법은 2가지가 될 수있다.
1. 인터넷창 2. 서버(curl)
우선 인터넷 창! 크롬이나 IE, Safari에서  elasticsearch REST Api를 통해 인덱스가 뭐가 있는지 알아보자!
http://url:9200/_cat/indices
아래처럼 우리가 물리적으로 지워준...5월, 6월 등등의 데이터가 있다는것을 알수가 있다.

두번째로 서버에서 curl 명령어로 알아보자.
curl -XGET 'url:9200/_cat/indices?v'

이제 마지막으로 지워보자! 인덱싱 되어있는 데이터를!
1. 위에서 인덱스를 파악.
2. 도메인/인덱스 형태 즉, bfdc.어쩌구가 인덱스이고
3. 하나씩 지우려면 * 요거 대신에 풀네임을 작성한다.
그런데 작업 = 대량이 많을꺼라 예상되니 아래의 예제는 *로 하겠다.
curl -XDELETE 'url:9200/bfdc.error-2021.05.*'

확인은!

삭제 후 다시 GET으로 삭제 되었는지 확인 해본다.
 curl -XGET 'url:9200/_cat/indices?v'
또는
df -ah 명령어를 통해 퍼센트가 줄어들었는지 확인한다.

와우 조금 지웠는데 97%에서 92%가 되었다! 굿~~~~

 

매우 간단한 운영처리인데 너무 서버안에서 로그만 생각했던것 같다.
좀 더 유연하게 넓게 생각할 필요가 있는것 같다.

추신 : elasticsearch에서는 정기적으로 삭제 해주는 것도 제공하니 더이상 신경을 안쓰고 효율적으로 관리하기 위해 처리 해주면 좋다.
예전에 Curator를 사용했었는데 다른 방법이 있는지는 찾아봐야할것 같다.
참고: 2015.12.16 - [OpenSource/ElasticSearch] - Curator를 사용해보자(인덱스 관리)

혹은 리눅스에서 사용한다면 crontab + shellscript를 이용하면 쉽게 삭제할 수 있다.
2021.12.12 - [OpenSource/ElasticSearch] - 리눅스에서 es 데이터 지우기

끝!