Linux 가동 중지 시간 로그는 "/var/log/"에 있습니다. Linux의 "/var/log/" 로그 로그에는 메시지, 커널 오류 로그 demsg 등이 포함됩니다. sa 레코드는 CPU, 메모리, 등. 성능 파일. sa 파일을 사용하여 충돌 중 CPU 및 메모리 상태를 확인합니다.
이 튜토리얼의 운영 환경: linux5.9.8 시스템, Dell G3 컴퓨터.
Linux 가동 중지 시간 로그는 어디에 있나요?
Linux 호스트 다운타임 문제 해결 아이디어
원인 분석
서버 분류, 웹 서버, 데이터베이스 서버, 파일 서버, 미들웨어, 기타 서버.
웹 서버 분석: 일반적인 웹 애플리케이션 apache, nginx, IIS 등
CPU, 메모리, IO 디스크, 애플리케이션 BUG, 커널 BUG, 하드웨어 등 다운타임의 원인은 다양합니다.
시스템 및 커널 버전
프로세스
1. 시간 기록, 기록 로그인 및 재시작 시간
last restart
last -F | grep crash
비정상적인 사용자에 대한 로그인 기록 확인
last
2. 먼저 시스템을 확인하세요. 통나무. 예를 들어 Linux의 /var/log/ 하위 로그 로그에는 메시지, 커널 오류 로그 demsg 등이 포함됩니다. sa 레코드는 CPU, 메모리 등의 동작을 기록하는 성능 파일이며, 해당 시스템의 실행 상태를 기록합니다. 그림과 같이 작동 중인 CPU.
sa 파일을 사용하여 종료 중 CPU 상태 확인
sa 파일을 사용하여 종료 중 메모리 상태 확인
로그 볼륨이 큰 경우가 많습니다
퍼지 쿼리도 수행할 수 있습니다 , 예를 들어
오류 보고서 보기
tail -200 /var/log/messages |grep "Error" cat /var/log/dmesg |grep "Error"
커널 충돌 로그 확인
tail -200 /car/log/messages |grep "crash"
OOM이 발생하는지 확인하세요. 일반적으로 kill은 프로세스를 종료합니다.
cat /var/log/messages |grep -i "kill"
다운타임 기간의 로그도 확인할 수 있으며, 15:00의 로그도 확인하세요. 12월 11일
cat /vat/log/messages |grep "Feb 11 15*"
3. 메모리 사용량 보기
free -m, 스왑 사용량, 남은 메모리 및 캐시를 확인하세요. swap을 사용했는데 available이 충분하지 않은 경우 cat /proc/sys/vm/swappiness 매개변수도 확인해야 합니다. 0으로 설정되어 있으면 메모리가 부족하다는 의미입니다.
4. io 및 파일 시스템 사용량 보기
유휴 상태 및 iowait를 관찰합니다. 캐시는 디스크를 읽고 쓸 때 사용되며 이는 일반적으로 시스템 메모리의 40%를 차지합니다. 그러나 캐시가 다 소모될 때까지 중간에 120초의 버퍼 시간이 있습니다. 디스크에 쓰기 전 120초입니다. 읽고 쓰는 작업이 빈번할 때 가끔 멈춤 현상이 발생하기 쉽습니다.
IO 읽기 및 쓰기 속도가 매우 느린 경우 디스크 성능에 병목 현상이 있음을 의미합니다.
파일 시스템 사용량
5. 보안 로그를 확인하세요
보안 로그는 /var/log/secure입니다. 호스트에 로그인하여 악의적인 행위를 한 사람이 있는지 기록 기록을 확인하세요. 폐쇄와 같은.
6. kdump 및 크래시 도구를 사용하여 커널 분석
서버에서 kdump 서비스가 활성화되어 있는지 확인하고 /var/crash 디렉터리에서 해당 날짜에 생성된 vmcore 파일을 찾으세요. vmcore 파일을 분석하려면 크래시 도구를 사용하세요.
Kdump는 메모리 이미지를 로컬 하드 디스크에 덤프할 수 있을 뿐만 아니라 NFS, SSH 및 기타 프로토콜을 통해 다른 시스템의 장치에 메모리 이미지를 덤프하는 데 사용됩니다.
Kdump는 Kexec와 Kdump의 두 가지 구성 요소로 나뉩니다.
Kexec는 시간이 많이 걸리는 BIOS 감지를 거치지 않고 실행 중인 커널(프로덕션 커널)의 컨텍스트에서 새 커널을 부팅할 수 있게 해주는 커널용 빠른 부팅 도구로, 커널 개발자가 커널을 더 쉽게 디버깅할 수 있습니다.
Kdump는 효과적인 메모리 덤프 도구입니다. Kdump를 활성화하면 프로덕션 커널은 커널이 충돌할 때 Kexec를 통해 새 커널로 빠르게 부팅할 수 있도록 메모리 공간의 일부를 예약하므로 시스템을 다시 시작할 필요가 없습니다. 충돌이 발생한 프로덕션 커널의 메모리 이미지를 덤프할 수 있습니다.
7. 서비스 로그 및 모니터링 소프트웨어 확인
다운타임 동안 프로세스의 점유율을 찾을 수 있으면 비정상적인 점유율이 있는 서비스를 기반으로 로그를 확인할 수 있습니다.
서비스 로그에는 일반적으로 데이터베이스, 웹 서비스, 미들웨어, 프레임워크 등이 포함됩니다.
모니터링 소프트웨어의 과거 이미지를 볼 수도 있고 아래와 같이 피크 포인트와 다운타임 포인트의 이미지 분석을 찾을 수도 있습니다.
8. 요약
시스템 다운타임에는 여러 가지 이유가 있으므로 프로세스에 따라 신중하게 분석해야 합니다.
관련 권장 사항: "Linux 비디오 튜토리얼"
위 내용은 Linux 충돌 로그는 어디에 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!