서버 문제 조사 방향

서버 고장으로 문제가 발생한 원인은 단번에 생각할 수 있는 것이 매우 적다.우리는 기본적으로 다음과 같은 단계에서 착수할 것이다.

1. 가능한 한 문제의 원인과 결과를 분명히 한다

단번에 서버 앞에 끼어들지 마라. 너는 먼저 이 서버에 대해 얼마나 알고 있는 상황과 고장난 구체적인 상황을 알아야 한다.그렇지 않으면 무에서 활을 쏘는 것일 가능성이 높다. 반드시 알아야 할 문제는 고장난 표현이 무엇입니까?응답 없음?잘못 보고하다고장은 언제 발견했습니까?장애가 재현됩니까?마지막으로 전체 플랫폼에 대한 업데이트 내용은 무엇입니까(코드, 서버 등)?장애가 발생한 특정 사용자 그룹은 무엇입니까?인프라(물리적, 논리적) 문서를 찾을 수 있습니까?모니터링 플랫폼을 사용할 수 있습니까?(예를 들어 Munin, Zabbix, Nagios, New Relic...무엇이든지 가능) 로그를 볼 수 있습니까?(예를 들어 Loggly, Airbrake, Graylog...) 마지막 두 가지가 가장 편리한 정보원이지만 큰 희망을 갖지 마세요. 기본적으로 없을 거예요.더 이상 모색할 수밖에 없어요.

2. 누가 있습니까?

$ w  
$ last 

이 두 가지 명령으로 누가 온라인이고 어떤 사용자가 방문했는지 봅시다.이것은 무슨 관건적인 단계는 아니지만, 다른 사용자가 일을 하고 있을 때 시스템을 디버깅하지 않는 것이 가장 좋다.한 산이 두 호랑이를 용납하지 않는다는 말이 있잖아.(ne cook in the kitchen is enough.)

3. 전에 무슨 일이 있었습니까?

$ history 

이전 서버에서 실행된 명령을 확인하십시오.보시면 틀림없습니다. 앞에서 본 누가 로그인했는지 정보까지 합치면 좀 쓸모가 있을 것입니다.또한 관리자로서 자신의 권한을 이용하여 다른 사람의 프라이버시를 침해하지 않도록 주의해야 한다.
이 명령을 실행하는 시간을 표시하기 위해 HISTIMEFORMAT 환경 변수를 업데이트해야 할 수도 있습니다.그렇지 않으면 언제 실행될지 모르는 명령만 봐도 미치겠다.

4. 현재 실행 중인 프로세스는 무엇입니까?

$ pstree -a  
$ ps aux

이것은 모두 기존 프로세스를 보는 것이다.psaux의 결과는 비교적 난잡하고 pstree-a의 결과는 비교적 간단명료하며 실행 중인 프로세스와 관련 사용자를 볼 수 있다.

5. 감청된 네트워크 서비스

$ netstat -ntlp  
$ netstat -nulp  
$ netstat -nxlp

나는 일반적으로 이 세 개의 명령을 분리해서 실행하는데, 한꺼번에 모든 서비스를 열거하는 것을 보고 싶지 않다.netstat-nalp도 괜찮아요.하지만 나는numeric 옵션을 절대 사용하지 않을 것이다.실행 중인 모든 서비스를 찾아서 실행해야 하는지 확인하십시오.개별 감청 포트를 확인합니다.netstat에 표시된 서비스 목록의 PID와 psaux 프로세스 목록은 같습니다.
만약 서버에 여러 개의 Java나 Erlang 같은 프로세스가 동시에 실행되고 있다면, PID에 따라 각각의 프로세스를 찾을 수 있는 것이 매우 중요하다.
일반적으로 우리는 모든 서버에서 실행되는 서비스가 좀 적고 필요할 때 서버를 늘릴 수 있도록 권장한다.만약 서버에 삼사십 개의 감청 포트가 열려 있는 것을 보았다면, 기록을 해서 나중에 시간이 있을 때 정리하고 다시 서버를 조직해라.

6. CPU 및 메모리

$ free -m  
$ uptime  
$ top  
$ htop

다음 문제에 주의하십시오. 아직 남은 메모리가 있습니까?서버가 메모리와 하드디스크 사이에서 swap을 하고 있습니까?남은 CPU가 있습니까?서버는 몇 코어입니까?일부 CPU 코어가 너무 많이 로드되었습니까?서버의 최대 부하는 어디에서 왔습니까?평균 부하는 얼마입니까?

7. 하드웨어

$ lspci  
$ dmidecode  
$ ethtool

여러 서버가 있는지 또는 베어 메탈 상태인지 확인할 수 있습니다. RAID 카드를 찾으십시오(BBU 대체 배터리 장착 여부),CPU, 비어 있는 메모리 슬롯이러한 상황에 따라 하드웨어 문제의 출처와 성능 개선 방법을 대체적으로 이해할 수 있다.네트워크 카드를 설치했습니까?반이중 상태로 실행 중입니까?속도가 10MBps?TX/RX가 잘못 보고되었습니까?

8. IO 성능

$ iostat -kx 2  
$ vmstat 2 10  
$ mpstat 2 10  
$ dstat --top-io --top-bio

이 명령들은 백엔드 성능을 디버깅하는 데 매우 유용하다.디스크 사용량 확인: 서버 하드 드라이브가 가득 찼습니까?swap 교환 모드 (si/so) 를 열었습니까?CPU 사용처: 시스템 프로세스?사용자 프로세스?가상 머신?dstat은 나의 가장 사랑이다.그것으로 누가 IO를 하고 있는지 볼 수 있다. MySQL이 모든 시스템 자원을 먹었는가?아니면 PHP 프로세스입니까?

9. 마운트 지점 및 파일 시스템

$ mount  
$ cat /etc/fstab  
$ vgs  
$ pvs  
$ lvs  
$ df -h  
$ lsof +D / /* beware not to kill your box */ 

모두 몇 개의 파일 시스템을 마운트했습니까?어떤 서비스 전용 파일 시스템이 있습니까?(예: MySQL?)파일 시스템의 마운트 옵션은 무엇입니까:noatime?default? 파일 시스템이 읽기 전용 모드로 다시 마운트되었습니까?디스크 공간이 아직 남아 있습니까?큰 파일이 삭제되었지만 비우지 않았습니까?만약 디스크 공간에 문제가 있다면, 당신은 구역을 확장할 공간이 있습니까?

10. 코어, 인터럽트 및 네트워크

$ sysctl -a | grep ...  
$ cat /proc/interrupts  
$ cat /proc/net/ip_conntrack /* may take some time on busy servers */  
$ netstat  
$ ss -s

당신의 중단 요청은 CPU 처리에 균형 있게 분배됩니까, 아니면 어떤 CPU 핵이 대량의 네트워크 중단 요청이나 RAID 요청으로 과부하됩니까?SWAP 스왑 설정은 무엇입니까?워크스테이션에 있어서 swappinness를 60으로 설정하면 좋지만 서버에 대해서는 너무 나쁘다. 서버에 SWAP 교환을 영원히 하지 않는 것이 가장 좋다. 그렇지 않으면 디스크에 대한 읽기와 쓰기가 SWAP 프로세스를 잠글 수 있다.conntrack_max가 서버의 데이터에 대처할 수 있도록 충분하게 설치되었습니까?다른 상태(TIME_WAIT,...) TCP 접속 시간 설정은 어떻게 됩니까?존재하는 모든 연결을 표시하려면netstat이 비교적 느릴 것입니다. 먼저 ss로 전체적인 상황을 볼 수 있습니다.너는 또한 Linux TCP tuning을 보고 네트워크 성능 개선의 몇 가지 요점을 이해할 수 있다.

11. 시스템 로그 및 커널 메시지

$ dmesg  
$ less /var/log/messages  
$ less /var/log/secure  
$ less /var/log/auth

오류와 경고 메시지를 보십시오. 예를 들어 연결 수가 너무 많아서 그런지 보십시오.하드웨어 오류나 파일 시스템 오류가 있는지 확인하십시오.이러한 오류 사건을 앞에서 발견한 의문점과 시간적으로 비교할 수 있는지 분석한다.

12. 정시 임무

$ ls /etc/cron* + cat  
$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

어떤 정시 작업이 너무 자주 실행됩니까?일부 사용자는 숨겨진 시간 작업을 제출했습니까?장애가 발생했을 때 마침 어떤 백업 작업이 수행되고 있습니까?

13. 애플리케이션 시스템 로그

이 안에는 분석할 수 있는 것이 많지만, 아마도 너는 운영자로서 그것을 자세히 연구할 시간이 없을 것이다.전형적인 LAMP(Linux+Apache+Mysql+Perl) 응용 환경에서:Apache & Nginx;접근과 오류 로그를 찾고 5xx 오류를 직접 찾아서 limit_가 있는지 확인하십시오zone 오류.MySQL; mysql에서log에서 오류 메시지를 찾아서 구조적 손상이 있는 테이블이 있는지, innodb 복구 프로세스가 실행 중인지, 디스크/index/query 문제가 있는지 확인하십시오.PHP-FPM; php-slow 로그를 설정하면 오류 정보 (php, mysql,memcache,...) 를 직접 찾고, 설정하지 않으면 빨리 설정합니다.Varnish; varnishlog와 varnishstat에서hit/miss비를 검사합니다.설정 정보에 어떤 규칙이 누락되어 최종 사용자가 당신의 백엔드를 직접 공격할 수 있는지 보십시오.HA-Proxy; 백엔드 상태는 어떻습니까?건강 상태 검사가 성공했습니까?프런트엔드입니까 아니면 백엔드의 대기열 크기가 최대치에 도달했습니까?

결론

이 5분이 지나면 다음과 같은 상황에 대해 잘 알 수 있을 것이다. 서버에서 실행되는 것은 모두 무엇입니까?이 고장은 IO/하드웨어/네트워크나 시스템 설정(문제가 있는 코드, 시스템 내 핵 조정,...)과 관련이 있는 것으로 보인다.이 고장은 네가 익숙한 몇 가지 특징이 있니?예를 들어 데이터베이스 인덱스를 잘못 사용하거나apache 백엔드 프로세스가 너무 많습니다.너는 심지어 진정한 고장 원인을 찾을 수도 있다.아직 찾지 못했어도 위의 상황을 파악한 후에 당신은 지금 깊이 파고들 수 있는 조건을 갖추고 있습니다.계속 노력하자!
다음에서 시작합니다.http://blog.jobbole.com/36375/