[CentOS] Linux 장애점검 명령어

폭풍이 지나간것 처럼 문제를 해결하고 나서 “뭔가 문제가 터졌을때 빨리 확인해볼수 있는 체크리스트가 있어야 한다.”라는 생각을 자주 했다. 그래서 간단하게 확인해볼 거리들을 Linux 터미널에서 시도해볼수 있는 커맨드와 함께 정리해 보았다. 수많은 서버 관리 도구가 나왔지만 어떠한 환경에서도 확실하게 동작하는건 Linux 터미널 도구였다 = 결국 직접 문제가 생긴 환경에 들어가봐야 한다.

 

1) CPU 상태 확인

서버 퍼포먼스 문제가 있다면 top 명령어로 CPU 사용량을 확인한다. 당신이 만든 어플리케이션이 지나치게 많은 CPU를 (50% 이상) 먹고있지 않은지 확인한다.

$ top

 

2) 메모리 상태 확인

당연하겠지만 메모리가 부족하면 안된다. 아래 명령어로 얼마나 메모리가 남았나 확인한다. 최소한 500메가 이상은 남아줘야 커널패닉이 나지 않는다.

$ free -m

 

3) 프로세스(쓰레드 상태) 확인

프로세스가 너무 많이 생겼거나 아예 프로세스가 죽어버린 경우가 있다. 본인이 띄운 프로세스가 살아 있는지 확인한다.

$ ps -ef | grep <process name>

 

4) 서비스/데몬 확인

데몬(daemon)은 백그라운드에서 돌아가는 프로세스를 말한다. 윈도우즈의 서비스를 생각하면 된다. 본인의 서버 프로그램이 데몬으로 돌아간다면 프로세스가 잘 돌아가고 있는지 확인한다.

$ service <daemon name> status

 

5) 네트워크 상태 확인

당연하지만 현재 서버의 네트워크 설정 및 상태를 보고 싶다면 아래 명령어를 쓴다.

$ ifconfig

하지만 이게 다가 아니다. 네트워크 쪽은 특별히 몇가지 케이스로 다뤄본다.

내 서버에서 접속이 가능합니까?

TCP 80, 443등의 특수 포트가 열려 있는지 확인하고자 한다면

$ nc <hostname> <port>
$ nc localhost 80
$ nc localhost 443

UDP인 경우엔 u 옵션으로 빠르게 확인해볼수 있다.

$ nc -u <hostname> <port>

<hostname>을 외부 서버로 해두면 이 서버에서 해당 host로 접속이 가능한지 확인해볼수 있다. 예를들어, 방화벽으로 막혀 있는가 등을 확인해 볼수 있다. 좀더 자세한 output을 위해선 -v 옵션을, 연결테스트 하는데 3초만 기다리고 싶다면 -w3 옵션을 주자.

누가 내 포트를 먹었는가?

개발하다보면 다른 프로세스와 port가 겹치는 에러를 접하게 된다. 이때 어떤 프로세스가 내가 port를 독차지하고 있는지 확인해볼수 있다. 예를들어 TCP 80 포트를 잡아먹고 있는 프로세스를 찾는다면

$ lsof -i TCP:80

또는 현재 특정 프로세스가 어떤 포트를 차지하는지 알고 싶다면 (여기선 httpd 데몬)

$ lsof -c httpd

nc와 lsof 명령어는 쓸모가 매우 많으니 잘 알아두자

서버가 응답이 자꾸 늦어져요

종종 서버의 응답이 늦어질때 요청이 서버에 엄청 몰리는게 문제인지 알고 싶을때가 있다. 이때엔 네트워크 연결수로 확인해볼수 있다.

$ netstat -nap | grep ESTAB | wc

연결수가 지나치게 많다면 어디선가 자꾸 연결이 생성되고 있다고 보면된다. 요청이 외부에서 들어온다면 몰리는 것이고 아니라면 뭔가 서버에 이상이 있는 것이다.

$ netstat -nap | grep TIME_WAIT | wc

TIME_WAIT 수가 비정상적으로 많으면 들어오는 요청을 서버에서 제대로 처리를 못하고 있다고 보면된다. 한마디로 병목현상이 벌어지고 있는 것이다.

 

5) 디스크 상태 확인

서버는 한번 전원이 들어오면 오랜시간 방치하는 경우가 많기 때문에 디스크에 쓰레기가 쌓이는 경우가 많다. 디스크가 꽉 차버리면 시스템에서 파일을 못 만들게 되고 결국 서버가 죽는다. 디스크 볼륨별로 얼마나 차 있는지, 빈 공간이 얼마나 남았는지 알고 싶다면 다음명령어로 확인한다.

$ df -h

root와 swap 볼륨이 충분한 여유가 있어야 한다.

 

6) 로깅 상태 확인

 

이건 번외인데 서버 초보들이 자주 범하는 실수라 적어둔다. 리눅스의 서버 로그는 /var/log 폴더 아래 저장이 되는데 여기에 본인 어플리케이션의 로그를 log rotation 시켜놓지 않는 경우가 있다.

그래서 단일 로그파일이 수 기가 바이트를 우습게 넘기는걸 종종 목격하는데 파일이 크면 클수록 프로세스가 처리하기 힘들어지고 결국 성능 저하로 연결된다. 메모리가 점점 늘어나고, 디스크 읽기 쓰기 성능이 계속 저하되는 증상을 보이지만 모니터링을 하지 않기 때문에 모르는 경우도 많고 이게 문제인지도 몰라서 고생하는걸 여러번 봤다.

log rotate를 처음 들어보고, 본인 서버 어플리케이션 성능이 계속 저하된다면 본인 서버의 로그가 어디 찍히는지 확인해보자.

---

서버는 클라이언트와 다르게 한번 띄워두면 상당히 오랜시간 손대지 않는 편이다. 그러다보니 오래된 건물처럼 시간이 지날수록 삐거덕 거리고 금이 가게 되며 그런상태로 더 오래 방치하면 어느날 갑자기 무너져 내려 서비스에 큰 장애를 일으킨다. 결국 서버의 전원을 넣는 순간부터 우리는 숙명처럼 계속 서버를 관리해줘야만 한다.

그래서… 건물에 관리인이 있듯 서버도 모니터링 & 알람 솔루션 (APM)이 있다. 이러한 솔루션은 우리가 미처 신경쓰지 못한 장애의 징조들을 미연에 알아차릴수 있도록 해주며 신뢰성 높은 서비스를 제공할수 있도록 만들어 준다. 다만 기존의 솔루션들은 서버의 물리적 상태(CPU, 메모리, 디스크 등등)에만 집중해 왔기 때문에 서비스의 유저가 겪는 논리적, 기능적 관점에서의 장애엔 취약하다. 위에 필자가 언급한 테스트 방법들은 물리적인 상태를 확인하는 것에 국한되어 있기 때문에 이 테스트들이 모두 정상적이어도 서버의 기능(로직)이 이상하게 동작하는건 잡아내기 어렵다. 서버 자원은 펑펑 남아도는데 고객에게 중요한 로그인이나 결제가 안되는 일이 생긴다는 것이다. 특히 한 서비스가 다른 서비스들에 API로 서로 연결되어 있는 경우엔…

 

우리 회사가 만들고 있는 HBSMITH는 ....

 

펌 : https://medium.com/hbsmith/linux-%EC%84%9C%EB%B2%84-%EC%9E%A5%EC%95%A0%EC%9B%90%EC%9D%B8-%ED%8C%8C%EC%95%85%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-7accec423bb5

Linux 서버 장애원인 파악은 어떻게?