리눅스 서버 로그에서 에러 한 줄만 보지 말고 grep -C로 앞뒤 흐름 확인하는 법

리눅스 서버 로그에서 에러 한 줄만 보지 않고 grep -C 명령어로 에러 앞뒤 흐름을 함께 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 장애가 발생했을 때 로그에서 ERROR 한 줄을 찾으면 뭔가 원인을 찾은 것처럼 느껴질 때가 있습니다.

하지만 실제 운영 환경에서는 에러 한 줄만 보고 바로 판단하면 놓치는 부분이 많습니다.

예를 들어 로그에 이런 줄이 있다고 해보겠습니다.

 

ERROR Failed to process request

 

이 줄만 보면 요청 처리에 실패했다는 것은 알 수 있습니다. 하지만 왜 실패했는지는 아직 모릅니다.

바로 앞에서 DB 연결이 실패했는지, 외부 API 응답이 늦었는지, 설정값이 잘못됐는지, 특정 요청이 반복됐는지는 앞뒤 로그를 같이 봐야 알 수 있습니다.

이럴 때 사용하는 명령어가 grep -C입니다.

이번 글에서는 리눅스 서버에서 에러 로그를 확인할 때 grep -C로 에러 앞뒤 흐름을 같이 보는 방법을 정리합니다.

에러 한 줄만 보면 위험한 이유

장애 로그를 볼 때 grep으로 에러 키워드를 찾는 것은 좋은 시작입니다.

 

grep -i "error" service.log

 

하지만 이 명령어는 error가 들어간 줄만 보여줍니다.

문제는 로그라는 것이 한 줄만 보고 끝나는 경우가 많지 않다는 점입니다.

예를 들어 이런 흐름일 수 있습니다.

10:15:01 Request started
10:15:02 Calling external API
10:15:10 API response timeout
10:15:10 ERROR Failed to process request
10:15:11 Retry started

 

여기서 ERROR Failed to process request만 보면 요청 처리 실패만 보입니다.

하지만 앞줄을 같이 보면 외부 API timeout이 먼저 발생했다는 것을 알 수 있습니다.

 

그래서 에러 로그는 보통 에러 줄 + 앞뒤 흐름을 같이 보는 것이 좋습니다.

로그에서 grep으로 에러 키워드를 찾는 기본 방법은 아래 글에서 먼저 정리했습니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

 

가상의 운영 상황 예시

예를 들어 웹 서비스에서 500 오류가 발생했다고 가정해보겠습니다.

[상황]
- 사용자 화면에서 500 오류 발생
- 장애 발생 시각은 10:15 전후로 추정
- 애플리케이션 로그에서 error 키워드 확인 필요
- 단순히 에러 한 줄이 아니라 에러 전후 흐름 확인 필요

 

이때 아래처럼 검색할 수 있습니다.

 

grep -i "error" /app/logs/service.log

 

하지만 이 방식은 에러가 발생한 줄만 보여줍니다.

에러 전후 흐름까지 보려면 아래처럼 확인하는 것이 좋습니다.

 

grep -i -C 3 "error" /app/logs/service.log

 

이 명령어는 error가 포함된 줄뿐 아니라, 그 앞뒤 3줄까지 함께 보여줍니다.

장애 원인을 찾을 때는 이 앞뒤 몇 줄이 작은 손전등 역할을 합니다. 에러 한 줄은 표지판이고, 앞뒤 로그는 길바닥에 남은 발자국입니다.

1단계. grep -C 기본 사용법

grep -C는 검색한 줄의 앞뒤 로그를 같이 보여주는 옵션입니다.

기본 형태는 아래와 같습니다.

 

grep -C 3 "ERROR" service.log

 

이 명령어는 ERROR가 들어간 줄을 찾고, 그 줄의 앞뒤 3줄을 같이 보여줍니다.

대소문자 상관없이 찾고 싶다면 -i를 같이 씁니다.

 

grep -i -C 3 "error" service.log

 

애플리케이션 로그라면 이렇게 볼 수 있습니다.

 

grep -i -C 3 "error" /app/logs/service.log

 

이렇게 하면 에러 한 줄만 보는 것보다 훨씬 상황을 파악하기 좋습니다.

2단계. 앞뒤 3줄과 5줄은 언제 쓸까?

처음에는 숫자를 어떻게 줘야 할지 헷갈릴 수 있습니다.

보통은 아래 정도로 시작하면 무난합니다.

grep -i -C 3 "error" service.log

 

앞뒤 3줄은 짧은 에러 흐름을 볼 때 좋습니다.

로그가 조금 더 길거나, Java 예외처럼 스택트레이스가 길게 찍히는 경우에는 5줄이나 10줄을 볼 수도 있습니다.

 

grep -i -C 5 "error" service.log

 

grep -i -C 10 "exception" service.log

 

다만 처음부터 너무 크게 잡으면 출력이 많아져서 다시 보기 어려워집니다.

초보 운영자라면 보통 아래 순서가 좋습니다.

1차 확인: grep -i -C 3 "error" service.log
2차 확인: grep -i -C 5 "error" service.log
예외 로그 확인: grep -i -C 10 "exception" service.log

 

처음에는 -C 3 또는 -C 5부터 시작하는 것이 좋습니다.

3단계. grep -C 결과는 어떻게 보일까?

예를 들어 로그가 이렇게 있다고 해보겠습니다.

10:15:01 Request started
10:15:02 User login checked
10:15:03 Calling external API
10:15:10 API response timeout
10:15:10 ERROR Failed to process request
10:15:11 Retry started
10:15:12 Retry failed
10:15:13 Response returned 500

 

여기서 아래 명령어를 실행합니다.

 

grep -i -C 3 "error" service.log

 

그러면 이런 식으로 앞뒤 로그까지 같이 볼 수 있습니다.

10:15:02 User login checked
10:15:03 Calling external API
10:15:10 API response timeout
10:15:10 ERROR Failed to process request
10:15:11 Retry started
10:15:12 Retry failed
10:15:13 Response returned 500

 

이렇게 보면 단순히 에러 한 줄이 아니라, 에러 전후에 어떤 일이 있었는지 같이 보입니다.

여기서는 ERROR보다 앞에 있는 API response timeout이 더 중요한 단서일 수 있습니다.

즉, 장애 판단은 이렇게 흘러가야 합니다.

ERROR 발견
→ 앞뒤 로그 확인
→ timeout 선행 여부 확인
→ 외부 API 연동 구간 의심
→ 요청 흐름과 연동 상태 추가 확인

 

에러 한 줄만 보고 애플리케이션 문제라고 단정하면, 실제 원인이 외부 API 지연인 상황을 놓칠 수 있습니다.

4단계. 최근 로그에서만 grep -C 사용하기

큰 로그 파일 전체를 대상으로 grep -C를 쓰면 결과가 많아질 수 있습니다.

장애가 방금 발생한 상황이라면 최근 로그에서만 보는 것이 더 편합니다.

 

tail -n 1000 service.log | grep -i -C 3 "error"

 

애플리케이션 로그라면 이렇게 볼 수 있습니다.

 

tail -n 1000 /app/logs/service.log | grep -i -C 3 "error"

 

이 명령어는 최근 1000줄 안에서 error가 들어간 줄을 찾고, 그 앞뒤 3줄을 같이 보여줍니다.

장애 직후에는 아래처럼 보는 흐름이 괜찮습니다.

 

tail -n 500 /app/logs/service.log | grep -i -C 3 "error"

 

로그가 많으면 500줄, 1000줄 정도로 범위를 잡고 확인하면 됩니다.

최근 로그를 먼저 확인하는 기본 흐름은 아래 글에서도 정리했습니다.

https://opsnote.tistory.com/20

리눅스 서버 로그 확인할 때 cat부터 치지 말고 tail과 less로 안전하게 보는 법

 

5단계. 실시간 로그 확인과 grep -C는 역할이 다릅니다

grep -C는 이미 쌓인 로그에서 앞뒤 흐름을 확인할 때 좋습니다.

반면 tail -f는 지금 새로 찍히는 로그를 실시간으로 확인할 때 좋습니다.

간단히 나누면 이렇습니다.

이미 쌓인 로그에서 에러 전후 흐름 확인
→ grep -C

서비스 재기동이나 테스트 요청 후 새 로그 확인
→ tail -f

 

예를 들어 장애가 이미 발생한 뒤 원인을 추적한다면 아래처럼 봅니다.

 

tail -n 1000 /app/logs/service.log | grep -i -C 3 "error"

 

서비스를 재기동하거나 테스트 요청을 보내면서 로그가 새로 찍히는지 봐야 한다면 아래처럼 봅니다.

 

tail -n 100 -f /app/logs/service.log

 

실시간 로그 확인 방법은 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/21

리눅스 서버 장애 났을 때 tail -f로 실시간 로그 확인하는 법

 

6단계. ERROR 말고 다른 키워드에도 사용할 수 있습니다

grep -C는 ERROR에만 쓰는 것이 아닙니다.

장애 상황에서는 아래 키워드들도 자주 봅니다.

exception
timeout
failed
refused
denied
killed
oom
fatal
critical

 

예를 들어 timeout 앞뒤 로그를 보고 싶다면 아래처럼 확인합니다.

 

grep -i -C 5 "timeout" /app/logs/service.log

 

Exception 앞뒤 로그를 보고 싶다면 아래처럼 볼 수 있습니다.

 

grep -i -C 10 "exception" /app/logs/service.log

 

OOM 관련 로그를 보고 싶다면 아래처럼 확인할 수 있습니다.

 

grep -i -C 5 "oom" /app/logs/service.log

 

키워드별로 앞뒤 몇 줄을 볼지는 로그 성격에 따라 다르게 잡으면 됩니다.

error      → -C 3 또는 -C 5
timeout    → -C 5
exception  → -C 10
oom        → -C 5
refused    → -C 3
denied     → -C 3

 

정답이 딱 정해져 있다기보다, 처음에는 작게 보고 필요하면 넓히는 방식이 좋습니다.

7단계. 여러 키워드와 같이 쓰기

여러 키워드를 한 번에 보고 싶을 때는 -E와 같이 쓸 수 있습니다.

 

grep -i -C 3 -E "error|exception|timeout" service.log

 

최근 로그에서만 보고 싶다면 이렇게 씁니다.

 

tail -n 1000 service.log | grep -i -C 3 -E "error|exception|timeout"

 

이렇게 하면 error, exception, timeout 중 하나라도 포함된 줄을 찾고, 해당 줄의 앞뒤 3줄을 같이 보여줍니다.

다만 키워드가 많아질수록 결과도 많아질 수 있습니다.

처음에는 한두 개 키워드로 보고, 필요하면 늘리는 것이 좋습니다.

예를 들어 이렇게 단계적으로 볼 수 있습니다.

 

tail -n 1000 /app/logs/service.log | grep -i -C 3 "error"

 

tail -n 1000 /app/logs/service.log | grep -i -C 5 "timeout"

 

tail -n 1000 /app/logs/service.log | grep -i -C 10 "exception"

 

한 번에 모든 키워드를 넣는 것보다, 의심되는 키워드별로 나눠 보는 것이 더 깔끔할 때도 많습니다.

8단계. grep -A, grep -B도 알아두면 좋습니다

grep -C는 앞뒤를 같이 보는 옵션입니다.

비슷한 옵션으로 -A, -B도 있습니다.

-C : 앞뒤 줄을 같이 보기
-A : 검색된 줄 이후 줄 보기
-B : 검색된 줄 이전 줄 보기

 

예를 들어 에러 이후 흐름만 보고 싶다면 아래처럼 확인합니다.

 

grep -i -A 5 "error" service.log

 

에러 이전 흐름만 보고 싶다면 아래처럼 확인합니다.

 

grep -i -B 5 "error" service.log

 

앞뒤를 같이 보고 싶다면 아래처럼 확인합니다.

 

grep -i -C 5 "error" service.log

 

초보 운영자 입장에서는 처음에는 -C만 알아도 충분합니다.

나중에 로그 흐름을 더 세밀하게 보고 싶을 때 -A, -B를 같이 익히면 됩니다.

9단계. grep -C 사용할 때 주의할 점

grep -C는 에러 흐름을 보기 좋지만, 몇 가지 주의할 점도 있습니다.

- 앞뒤 줄이 너무 적으면 원인 흐름을 놓칠 수 있음
- 앞뒤 줄이 너무 많으면 결과가 복잡해짐
- 검색 키워드가 너무 흔하면 결과가 너무 많아짐
- 에러 한 줄만 보고 원인을 확정하면 안 됨
- 오래된 에러와 현재 장애를 혼동하면 안 됨
- 실제 로그 공유 시 민감 정보는 마스킹해야 함

 

특히 error라는 단어가 너무 많이 찍히는 로그에서는 결과가 길어질 수 있습니다.

그럴 때는 최근 로그 범위를 줄이거나, 키워드를 더 구체적으로 잡는 것이 좋습니다.

 

tail -n 500 service.log | grep -i -C 3 "timeout"

 

또는 특정 시간대와 함께 볼 수도 있습니다.

grep "10:15" service.log | grep -i -C 3 "error"

 

다만 로그 시간 형식은 서버마다 다를 수 있으므로, 먼저 로그가 어떤 형식으로 찍히는지 확인하는 것이 좋습니다.

10단계. 로그 파일이 너무 크면 먼저 크기부터 확인하기

운영 서버에서는 로그 파일이 생각보다 클 수 있습니다.

grep -C를 사용하기 전에 로그 파일 크기를 먼저 보는 습관이 좋습니다.

 

ls -lh /app/logs/service.log

 

예시입니다.

-rw-r--r-- 1 app app 2.1G May 22 10:20 service.log

 

이렇게 큰 로그 파일이라면 처음부터 전체 파일을 대상으로 검색하기보다 최근 로그부터 확인하는 것이 좋습니다.

 

tail -n 1000 /app/logs/service.log | grep -i -C 3 "error"

 

로그 파일이 계속 커지는 상황이라면 logrotate 설정이나 반복 오류 여부도 같이 확인해야 합니다.

로그 파일이 계속 커질 때 확인하는 순서는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법

 

11단계. /var/log를 확인할 때는 /var 용량도 같이 보기

운영 서버에서는 /var/log 아래에 로그가 많이 쌓입니다.

만약 같은 에러가 반복적으로 찍히고 있다면 로그 파일이 빠르게 커질 수 있습니다.

이때는 /var 용량도 함께 확인하는 것이 좋습니다.

 

df -h /var

 

du -xhd1 /var/log 2>/dev/null | sort -h

 

/var가 가득 차면 로그 기록 실패, 서비스 오류, 패키지 설치 실패 같은 문제가 생길 수 있습니다.

/var 용량이 찼을 때 위험한 이유와 확인 순서는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/68

리눅스 서버 /var 용량이 찼을 때 위험한 이유와 안전한 확인 순서

 

12단계. 운영 서버에서 안전하게 보는 순서

운영 서버에서는 무작정 전체 로그를 뒤지는 것보다 범위를 정해서 보는 편이 좋습니다.

초보 운영자 기준으로는 아래 순서가 무난합니다.

1. 로그 파일 위치 확인
2. 로그 파일 크기 확인
3. 최근 로그 범위 확인
4. 에러 키워드 검색
5. grep -C로 앞뒤 흐름 확인
6. 반복 발생 여부 확인
7. 필요하면 tail -f로 실시간 확인
8. 프로세스, 포트, 리소스 상태 같이 확인

 

명령어로 정리하면 아래처럼 볼 수 있습니다.

 

ls -lh /app/logs/service.log
tail -n 500 /app/logs/service.log
tail -n 500 /app/logs/service.log | grep -i -C 3 "error"
tail -n 500 /app/logs/service.log | grep -i -C 5 "timeout"

 

필요하면 서비스 상태도 같이 봅니다.

 

ps -ef | grep example-app

 

ss -lntp | grep ':8080'

 

로그만 보고 바로 재기동하기보다, 프로세스와 포트 상태도 같이 확인하는 것이 좋습니다.

서버 재기동 전 기본 체크리스트는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/19

리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

 

13단계. 실무 보고 예시

grep -C로 앞뒤 로그를 확인했다면 이렇게 정리할 수 있습니다.

애플리케이션 로그에서 error 키워드 기준으로 앞뒤 로그를 함께 확인했습니다.
에러 직전 외부 API timeout 로그가 확인되어,
해당 연동 구간을 우선 확인하겠습니다.

 

반복 발생이 보이면 이렇게 쓸 수 있습니다.

최근 500줄 기준 동일 에러가 반복적으로 확인됩니다.
grep -C 옵션으로 전후 로그를 확인한 결과,
특정 요청 이후 동일 오류가 반복되는 것으로 보입니다.

 

원인이 아직 불명확할 때는 이렇게 정리할 수 있습니다.

error 키워드 기준으로 앞뒤 로그를 확인했으나,
단일 로그만으로 원인 확정은 어렵습니다.
서비스 프로세스, 포트 상태, 외부 연동 응답 여부를 추가 확인하겠습니다.

 

로그 파일이 빠르게 커지고 있다면 이렇게 쓸 수 있습니다.

동일 에러 로그가 반복적으로 출력되고 있어 로그 파일 증가 가능성이 있습니다.
현재 에러 발생 흐름과 함께 /var 용량 영향을 추가 확인하겠습니다.

 

이렇게 쓰면 “에러 로그 확인했습니다”보다 훨씬 낫습니다.

정리하면

리눅스 서버에서 에러 로그를 확인할 때는 에러 한 줄만 보면 부족할 때가 많습니다.

기본 grep은 해당 줄만 보여줍니다.

 

grep -i "error" service.log

 

앞뒤 흐름까지 보고 싶다면 grep -C를 씁니다.

 

grep -i -C 3 "error" service.log

 

최근 로그에서만 보고 싶다면 아래처럼 확인합니다.

 

tail -n 500 service.log | grep -i -C 3 "error"

 

에러 이후만 보고 싶다면 -A를 사용할 수 있습니다.

 

grep -i -A 5 "error" service.log

 

에러 이전만 보고 싶다면 -B를 사용할 수 있습니다.

 

grep -i -B 5 "error" service.log

 

초보 운영자라면 이 문장만 기억해도 좋습니다.

에러 한 줄만 보고 원인을 단정하지 말고, grep -C로 앞뒤 흐름까지 함께 확인하세요.

grep -C는 에러가 발생한 줄만 보는 것이 아니라, 그 앞뒤에 어떤 요청이나 메시지가 있었는지 함께 확인할 때 유용합니다.  
장애 로그는 한 줄보다 흐름이 더 중요할 때가 많습니다.

grep으로 기본 키워드 검색을 먼저 정리하고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/24

리눅스 서버 로그에서 에러 찾을 때 grep만 믿지 말고 앞뒤 흐름까지 확인하는 법

 

정상 로그가 너무 많이 섞여 있을 때는 grep -v로 제외 조건을 걸어 필요한 로그만 좁혀볼 수 있습니다.

https://opsnote.tistory.com/26

리눅스 서버 로그에서 정상 로그가 너무 많을 때 grep -v로 제외하고 확인하는 법

 

로그 파일이 계속 커질 때 바로 비우지 않고 확인하는 순서는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/7

리눅스 서버 로그 파일이 계속 커질 때 바로 비우지 말고 확인하는 법