예기치 않은 Linux 서버 종료를 조사하는 방법은 무엇입니까?

데비안 6의 공격대 10에서 4xSSD가 장착 된 새로운 Xeon 55XX 서버에서 서버가 구축 된 후 2 주 이내에 2 개의 임의 종료가 발생했습니다. 종료하기 전에 대역폭 로그를 살펴 본다고해서 비정상적인 것은 아닙니다. 서버로드는 일반적으로 매우 낮으며 (약 1) 멀리 배치됩니다. 서버가 다운되는 동안 정전이없는 것 같습니다.

나는 / var / log를 보았지만 조사해야 할 로그와 무엇을 찾아야할지 확실하지 않습니다. 힌트를 주셔서 감사합니다.

먼저 "셧다운"이라고 물어봐야합니까? 머신이 재부팅되거나 실제로 정지 했습니까? 중지되면 잘못 구성되었거나 (BIOS에있을 수 있음) 시스템이 실제로 종료 된 것입니다 (예 : init 0).

그렇지 않은 경우 문제는 커널 패닉이나 소프트웨어 트리거 하드웨어 결함처럼 들리므로 주 후보는 / var / log / syslog 및 /var/log/kern.log입니다. 물론 서버가 일부 서비스 (예 : 아파치)를 실행하면 힌트를 얻을 수도 있습니다.

종종 이런 상황에서는 로그 항목이 생성되지만 시스템에 문제가 있기 때문에 항목을 디스크에 쓸 수 없습니다. 박스가 같은 위치에 있으면 콜로 파트너가 시리얼 콘솔에 연결할 가능성이 있습니다. 위의 로그에서 의심스러운 것을 찾지 못하면 내가 볼 곳입니다.

머신이 직렬 콘솔에 연결되어 있지 않고 로그에 아무것도없는 경우 네트워크를 통해 다른 상자에 syslog를 보내는 것을 고려할 수 있습니다. 네트워크 인터페이스가 약간 더 오래 지속될 수 있으며 syslog 서버에서 로그 메시지를 읽을 수 있습니다. rsyslog 또는 syslog-ng를 살펴보십시오.

최신 정보:

아래 @Johann에 동의합니다. 중지의 원인은 프로세서 온도 워치 독입니다. lmsensor 또는 smartctl (보통 가장 쉬운 방법)을 통해 상자의 온도를 확인 / 플로팅하십시오. 수집 된 것이 시간이 지남에 따라 많은 수의 변수를 추적하는 데 필적 할 수 없다는 것을 알았습니다. IPMI와 lm- 센서 및 hddtemp를 모두 수행 할 수 있습니다. 또한 일부 BIOS :는 온도 정지 이벤트를 기록합니다.

먼저을 확인하고 싶습니다 /var/log/syslog. 당신이 확실하지 무엇을 찾아야하는 경우, 당신은 단어를보고 시작할 수 있습니다 error, panic하고 warning.

grep -i error /var/log/syslog

사용 가능한 시스템 그래프가있는 경우 (예 : Munin). 그것들을 점검하고 비정상적인 패턴을 찾으십시오. munin이 설치되어 있지 않은 경우 설치하는 것이 좋습니다 ( apt-get install munin munin-node)

또한 시스템 충돌과 관련 될 수있는 흥미로운 메시지가 있는지 루트 메일을 확인해야합니다.

확인해야 할 다른 로그 파일은 응용 프로그램 오류 로그입니다. 예를 들어 /var/log/apache2/error.log또는 유사합니다. 문제를 일으키는 정보가 포함되어있을 수 있습니다.

내 경험상 "예기치 않은 정지"는 거의 항상 과열로 인해 발생합니다. lm_sensors를 통해 온도와 팬 속도를 확인하고 그것들이 좋은지 확인하십시오.

최근에는 동일한 패턴이있었습니다. 지원이 수동으로 시작한 후 약 1 시간 후에 서버가 중지되었습니다. 이 시간이 지나면 CPU 온도가 BIOS에서 구성된 임계 값 (iirc 60 또는 70 ° C)에 도달하여 시스템이 중지됩니다. CPU 팬 고장으로 인한 이러한 모든 문제. 팬을 교체 한 후 모든 것이 정상으로 돌아 왔습니다.

/ var / log 디렉토리에는 여러 개의 로그 파일이 있으며 하위 디렉토리도 포함됩니다.

/var/log/boot

과

/var/log/boot.log

위의 파일로 시작하십시오.

종료를 트리거 한 원인을 확인하는 두 가지 방법이 있습니다. 먼저 하드웨어의 문제에 대해 대역 외 관리 콘솔을 확인하십시오. SNMP를 구성하고 이메일을 받거나 경고를위한 모니터링 소프트웨어에 트랩을 추가하는 것이 좋습니다.

그런 다음 운영 체제를 통해 /var/log/messages(RedHat 기반 배포판) 또는 /var/log/syslog(Debian Based distros)를 확인할 수 있습니다.

디스크 하위 시스템은 문제가 발생했을 때 영향을 받기에 충분히 복잡합니다. 로그 파일에는 거의 아무것도 없기 때문입니다.

시리얼 콘솔을 통해 로그인하십시오. 여기에는 케이블을 연결하고 회선을 픽업하는 다른 시스템이 필요하지만 실제로 문제를 잡을 가능성이 더 큽니다.

물론 노드에 Oracle의 ALOM / ILOM과 유사한 내장 관리 시스템이있는 경우 가능한 문제점 및 로그 파일을 확인할 수도 있습니다.

다음 명령으로 시스템이 다운되었다는 사실을 시스템이 알고 있는지 확인할 수 있습니다.

sudo last -1x reboot
sudo last -1x shutdown

info =>가 없으면 전원이 끊어 지거나 외부의 무언가가 손실 될 수 있습니다

재부팅 / 종료 시간에 대해 로그에 info => 검색이있는 경우