EC2 서버 Down 시 원인 분석

베하 안녕하세요 ~~! BTC_현상수배범입니다.

이번 시간에는 EC2 서버 Down 시 원인 분석(로그 분석)에 대해 알아보도록 하겠습니다.

 

지난밤 서버에 무슨일이 있었는지, 프로세스가 제대로 동작하지않거나, 죽어있는경우

서버가 강제종료되지않았는지, 재부팅된건 아닌지, 의심스러울때가 있습니다.

 

리눅스에서는 서버 재부팅, 셧다운 등에 대한 로그를 남기고 종료되기 때문에,

서버에 대한 장애원인파악이 쉽습니다! 따라서 서버 Down과 관련된 로그들을 파악해보도록 하겠습니다!

 

1. DataDog&Whatap

• CPU Usage(%) / Process CPU Usage (%) / Memory used (%) / Top RSS Memory (%) 확인 후 최대 사용 중인 Process 확인

2. Health DashBoard 이벤트 로그에서 maintenace 관련 서버 reboot 내용이 있는지 확인

 

3. CloudTrail 이벤트 기록 보기 - 이벤트 이름[RebootInstances]

 

4. 관련 로그 파일 및 리부트 기록 확인

• /var/log/messages |grep "Command" : ssh를 통해 reboot시 command를 통해 부트이미지 실행에 대해서 로그를 남깁니다. 
• /var/log/messages |grep "Power"
• /var/log/dmesg
• /var/log/syslog
• last reboot or /var/log/secure 등으로 ip , reboot 관련 로그 파악
  • last #전체 로그인/로그아웃, 시스템 시작/종료 기록을 확인할 수 있다.
  • last -F # 연도를 포함하여 시간을 자세하게 표시한다.
  • last -[숫자] # 최대 출력하는 라인 수를 지정한다. (최근순)
  • last [계정명] # 특정 계정의 로그인/로그아웃 기록을 확인할 수 있다.
  • last reboot # 시스템 재부팅 로그를 확인 할 수 있다.
• window일 경우 : 이벤트 뷰어(eventvwr.msc) → windows 로그, 응용 프로그램 및 서비스 로그 확인

5. 추가 사항

• /var/log/httpd/error.log or /var/log/nginx/error.log 등 웹 에러 로그 확인
• netstat -nltp , ps -ef 네트워크, 프로세스 확인 등
• sar/free/top 메모리 사용량 확인
• 커널이 완전히 업데이트 되었는 지 확인 : ex) sudo yum update kernel

 

 

💡 개인적으로 부팅 문제 관련하여 check 해볼 만한 사항

 

1. EC2 Instsance type 변경 작업 시

• EBS root device 포함 - 추가 device가 연결 되어있을 때 → 같은 타입으로(ex: c5.xlarge → c5.large) 변경할 경우 문제가 발생하지 않지만, 다른 타입으로(ex: c5.xlarge → m5.xlarge) 변경할 경우 부팅 안되는 경우가 있음. 이유: 타입 자체가 바뀌고 EC2 Instance를 재부팅할 때 /etc/fstab에서 UUID 값이 적용되지 않고 올라오는 경우가 있기 때문에 타입 변경 작업할 때 타입 변경 가능한 지에 대한 여부 확인 필요
• 기간이 오래된 EC2 Instance type 변경 시 → 오래된 EC2 Instance를 다른 타입으로(ex: c5.xlarge → m5.xlarge) 변경 후 재부팅 시 Nvme가 적용되지 않은 상태에서 부팅이 되는 경우 부팅 X

2. EBS 작업시 /etc/fstab에 루트 UUID 값 날려 먹을 경우

 

3. 부팅은 성공하였지만 SSH 접근이 안되는 경우

• 서버 내 .ssh폴더를 날리거나 서버 내 .ssh폴더 밑에 key 값 날린 경우 → 해결책은 test용도 신규 서버를 만들어 기존 서버 EBS Detach 후 신규 서버에 attach하고 마운팅하여 .ssh 폴더 생성 후 Key 값 넣어주고 다시 Detach 후 기존 서버 Attach 

재부팅이나 재시작 관련 내용을 정리해보자면

1) 인스턴스가 상태 검사 실패 - 메모리 부족(OOM), I/O 오류(블록 장치), 오래된 Linux 커널, /etc/fstab의 잘못 구성된 파일 시스템 정의, SELinux 구성 오류 등

2) 기본 하드웨어 결함으로 인해 인스턴스 재시작하여 정상인 새 하드웨어로 교체

3) 예약된 유지 관리 기간에 인스턴스 재시작

4) 사용자 또는 애플리케이션이 인스턴스 재시작

5) 커널 버그 - sudo yum update kernel

 

이정도로 요약해볼 수 있을 것 같습니다.

 

[관련 문서]

https://repost.aws/ko/knowledge-center/ec2-instance-automatic-reboot-cause https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#viewing_status

Status checks for your instances - Amazon Elastic Compute Cloud

 

가끔 업무를 하거나 작업을 하다보면 이러한 당황스러운 일들이 일어날 수도 있을 것 같은데 , 참고하여 도움이 되셨으면 합니다! 

다음번에는 더 신선한 주제로 찾아뵐게요~~ 모두들 베빠~