시스템 (CPU load, mem usage, disk I/O access) 로그 장기 저장

일단 CPU 와 I/O 에 대한 문제 판단은 sar, top 의 CPU 정보를 참고할 수 있습니다.
CPU 의 sys, user 가 많이 사용 된다면 CPU 연산의 이슈이고, I/O wait 이 많이 발생한다면 CPU 연산 로직을 잘못 사용하여 block 이 걸리거나 CPU 외부의 data 통신에 의한 block (Disk i/o 지연 등..) 에 의해 발생한다고 볼 수도 있습니다. 그 외에 자잘한 패킷 통신이 엄청 많을 경우에는 CPU 의 soft irq 자원이 소모되어 CPU power 나눠 먹기를 할 수도 있습니다.

메모리는 대충 동작하는 응용 프로그램의 메모리 사용량의 문제가 되는 구조적인 문제가 많이 발생하는 편이고, 그 외에 memory leak 이 있거나 또는 memory 자체의 불량으로 인한 성능 저하 등이 발생할 수 있습니다. 불량의 경우에는 대부분 커널 로그에 남거나 또는, BMC (baseboard management controller) 로그에 남게 됩니다. BMC 로그는 ipmi sel log 를 이용하여 확인이 가능하고, 요즘 서버들은 web interface 로 서버 관리가 가능 하므로, 여기서 확인을 할 수 있습니다.

다만, 제 경험상 대부분의 T/S 은 개인적 역량으로 이루어지지, 딱 이렇게 해야 된다는 건 없는 것 같습니다. 그냥 데이터를 모아놓고, 그 데이터를 이용해서 판단을 하는 것이지, 모여진 데이터를 정형화 시키려고 하는 건 좀 부질없지 않나 싶습니다. 리소스 용량 판단이나 이로 인한 장애 방지를 위해서라면 모르겠지만, 현재 발생한 문제를 파악하기 위하여 정형화 시킨다는 건 좀 어불 성설인듯 싶습니다.

제가 만난 장애 중에는... NTP 로 시간 동기화를 하고 있음에도 불구하고 서버 간의 1초 차이가 장애를 만든 경우도 있습니다. 물론 race condition 이라서 정말 찾기 힘들었습니다. ㅠㅠ 그냥 소 뒷걸음 치다가 쥐 밟은 격으로 찾았다는...

대충 정리해 보면.. 문제가 발생하는 서버를 발견 한다면,

1. system log 나 BMC log 를 통하여 물리적 H/W fault 가 있는지 확인. 예를 들어, CPU / memory fault, Disk medium error, Raid controller reset, Fan fault 등등
2. 특정 resouce 에 편중된 사용량 확인 (cpu, memory, network, disk 등등). 이건 서버의 역할에 따라 내/외부의 문제인지를 파악
2-1 내부적 이슈일 경우, 리소스 잡아먹는 하마 색출, 하마가 왜 그러는지 reverse engineering
2-2 외부적 이슈일 경우.. 는 그때 그때 알아서.. 또는 해당 담당 팀으로 토스~

이런식으로 많이 진행되는 것 같습니다.