Tutoriel Linux

Linux에서 Grep: 로그에서 오류 찾기

Débutant2 min de lecture

활성 서버에서 cat /var/log/syslog를 실행하면 주로 한 가지 결과가 나타납니다: 너무 많은 줄. 서비스가 중단되거나 오류가 발생했을 때, 먼저 서비스 이름, 시간, 그리고 구체적인 메시지를 확인하세요. grep을 사용하면 발생한 일에 대한 설명을 잃지 않고 잡음을 줄일 수 있습니다.

이 방법은 /var/log에 있는 파일이나 journalctl의 출력에도 적용됩니다. 전체 저널을 대체하지는 않으며, 신뢰할 수 있는 출발점을 찾고 그 주위를 넓히는 데 사용됩니다.

Tux가 루브의 Linux 로그에서 특정 오류를 검색하고 있습니다.
특정 오류를 찾아서 그 주변의 줄을 다시 읽어보세요.

읽기 쉬운 검색부터 시작하기

행 번호를 추가하고 대소문자를 무시하세요, 프로그램이 Error, ERROR 또는 error를 혼용하는 경우:

grep -n -i 'error' /var/log/mon-service.log

-n은 행 번호를 표시합니다. 이 옵션은 less에서 파일을 다시 열거나 두 검색을 비교하거나 티켓에 내용을 복사할 때 유용합니다. 작은따옴표는 패턴에서 특수 문자의 해석을 방지합니다. grep 매뉴얼은 검색 및 컨텍스트 옵션을 자세히 설명합니다.

  • -i는 대소문자를 구분하지 않고 검색합니다.
  • -n은 행 번호를 추가합니다.
  • -F는 텍스트를 리터럴 문자열로 처리하며, ., [, 또는 ?가 포함된 오류에 유용합니다.
  • -E는 확장 정규 표현식을 활성화합니다.
  • -C 3는 각 일치 항목에 대해 세 줄을 전후로 표시합니다.

정확한 오류를 위해서는 -F를 사용하는 것이 좋습니다. IP 주소, 경로 또는 괄호가 있는 메시지는 정규 표현식으로 해석될 수 있습니다:

grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/mon-service.log

오류를 설명하는 줄 유지하기

ERROR로 표시된 줄은 단독으로 원인을 나타내는 경우가 드뭅니다. 결론을 내리기 전에 맥락을 표시하세요:

grep -n -i -C 3 'error' /var/log/mon-service.log

grep -n -i -A 5 'failed' /var/log/mon-service.log

grep -n -i -B 5 'panic' /var/log/mon-service.log

-C 3는 양쪽에서 세 줄을 유지합니다. -A는 다음 줄만 표시하고, -B는 이전 줄만 표시합니다. 여러 개의 오류가 떨어져 있는 경우, grep은 그룹을 --로 구분합니다. 이 구분자는 저널에 포함되지 않습니다.

여러 증상을 알고 있는 경우 -E로 조합하세요:

grep -n -i -E 'error|failed|timeout|refused' /var/log/mon-service.log

이 명령은 반드시 귀하의 사건과 관련되지 않은 메시지도 반환합니다. 이후 프로세스 이름, 포트 또는 요청 식별자를 추가하는 것이 좋으며, 임의로 키워드 목록을 늘리지 않도록 하세요.

grep을 사용하기 전에 journalctl 필터링하기

systemd를 사용할 경우, 먼저 저널을 사건의 단위 및 시간으로 제한하세요. 다른 서비스의 메시지를 혼합하는 것을 피할 수 있습니다:

journalctl -u nginx --since '30 minutes ago' --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager | grep -n -i -C 2 'error'

nginx를 예를 들어 postgresql, docker 또는 귀하의 애플리케이션 서비스의 실제 단위 이름으로 교체하세요. 사고가 재부팅 후 발생한다면, 현재 부팅 상태를 유지하기 위해 -b를 추가하세요. journalctl 매뉴얼는 단위 및 기간별 필터에 관해서도 설명합니다. journalctl과 마지막 부팅의 로그에 대한 가이드는 이 필터를 자세히 설명합니다.

문제의 시간을 설정하기 전에 수년 간의 로그에서 검색을 시작하지 마세요. 오후 2시 12분에 보인 오류는 오후 2시 12분 주위의 짧은 시간대를 가질 가치는 있습니다. 이후 원인이 드러나지 않으면 좀 더 넓은 범위를 읽어보세요.

재현 중 서비스 추적하기

재현 가능한 문제를 위해 두 번째 터미널을 열고 오직 새로운 줄만 보세요:

journalctl -fu nginx

tail -F /var/log/nginx/error.log | grep --line-buffered -i -E 'error|warn|failed'

journalctl -f는 실시간 저널을 추적합니다. tail -F는 파일 회전 후에도 계속해서 작동하므로, 많은 로그 애플리케이션에 대해 tail -f보다 더 안전합니다. --line-buffered 옵션은 grep으로 파이프 처리한 후 흐름을 읽기 쉽게 유지합니다.

그런 다음, 실패하는 동작을 한 번만 트리거하세요: HTTP 요청, 수동 재부팅 또는 테스트 연결. 여러 테스트를 동시에 실행하면 어떤 줄이 어떤 시도에 해당하는지 알 수 없습니다. 일반 파일을 추적하는 경우 tail을 사용한 우리의 방법을 참조할 수 있습니다.

오류를 찾았다면, 시간, 관련 단위 또는 프로세스를 기록하고, 메시지 주변의 줄을 기록하세요. 이는 천 줄의 로그를 복사하여 붙여넣는 것보다 유용하며, 잘못된 서비스를 식별하기 전에 구성을 수정하는 것을 방지합니다.

n