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

리눅스 서버 로그에서 grep -v 명령어로 health check, 정상 응답, 반복 로그를 제외하고 필요한 장애 로그만 확인하는 방법을 설명하는 대표 이미지

 

리눅스 서버에서 장애 로그를 확인하다 보면 로그가 너무 많이 찍혀서 오히려 보기 어려울 때가 있습니다.

에러를 찾으려고 로그를 열었는데 INFO 로그, health check 로그, access log, 정상 요청 로그가 계속 섞여 있으면 정작 봐야 할 내용을 놓치기 쉽습니다.

이럴 때 사용할 수 있는 명령어가 grep -v입니다.

grep이 특정 문자열을 포함한 줄을 찾는 명령어라면, grep -v는 반대로 특정 문자열이 들어간 줄을 제외하고 보여주는 명령어입니다.

이번 글에서는 리눅스 서버 로그가 너무 많을 때 grep -v로 불필요한 로그를 빼고 확인하는 방법과, 운영 서버에서 제외 조건을 사용할 때 주의할 점을 정리합니다.

grep -v는 언제 사용할까?

보통 로그를 볼 때는 grep으로 에러를 찾습니다.

 

grep -i "error" service.log

 

그런데 어떤 상황에서는 에러를 찾는 것보다 불필요한 로그를 빼는 것이 더 편할 때가 있습니다.

예를 들면 이런 경우입니다.

- INFO 로그가 너무 많을 때
- health check 로그가 계속 찍힐 때
- 정상 access log가 너무 많을 때
- 특정 IP 요청을 제외하고 보고 싶을 때
- favicon, static 파일 요청이 계속 섞일 때
- 특정 문구가 반복되어 화면을 가릴 때

 

장애 상황에서는 로그가 많을수록 좋은 것이 아닙니다.

중요한 것은 봐야 할 로그가 보이는 것입니다.

 

로그 확인의 기본 흐름은 먼저 최근 로그를 보고, 필요한 키워드로 좁히고, 앞뒤 흐름을 확인하는 것입니다. tail, less, grep 기본 사용법은 아래 글들과 함께 보면 좋습니다.

https://opsnote.tistory.com/20

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

 

https://opsnote.tistory.com/24

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

 

가상의 운영 상황 예시

예를 들어 운영 서버 access log에 아래와 같은 로그가 계속 찍힌다고 가정해보겠습니다.

GET /health 200 OK
GET /health 200 OK
GET /metrics 200 OK
GET /health 200 OK
GET /api/order 500 Internal Server Error
GET /health 200 OK
GET /favicon.ico 404 Not Found

 

이 상태에서 전체 로그를 보면 health check와 metrics 로그가 너무 많아서 실제로 봐야 할 500 오류가 묻힐 수 있습니다.

이럴 때는 반복되는 정상 로그를 제외하고 볼 수 있습니다.

tail -n 1000 access.log | grep -v "/health"

 

여러 정상 로그를 제외하고 싶다면 아래처럼 볼 수 있습니다.

tail -n 1000 access.log | grep -v -E "/health|/metrics|favicon.ico"

 

이렇게 하면 로그 숲에서 잔가지가 조금 걷히고, 실제 확인해야 할 요청이 더 잘 보입니다.

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

grep -v의 기본 형태는 아래와 같습니다.

grep -v "제외할문구" 로그파일

 

예를 들어 INFO 로그를 제외하고 보고 싶다면 이렇게 씁니다.

grep -v "INFO" service.log

 

이 명령어는 INFO가 들어간 줄을 빼고 나머지 로그만 보여줍니다.

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

grep -v "INFO" /app/logs/service.log

 

대소문자까지 신경 쓰기 싫다면 -i 옵션을 같이 쓸 수 있습니다.

grep -i -v "info" /app/logs/service.log

 

이렇게 하면 INFO, Info, info가 들어간 줄을 모두 제외할 수 있습니다.

초보 운영자라면 일단 이렇게 기억하면 됩니다.

grep "문구"    → 해당 문구가 들어간 줄을 찾음
grep -v "문구" → 해당 문구가 들어간 줄을 제외함

 

2단계. health check 로그 제외하기

운영 로그를 보다 보면 헬스체크 로그가 계속 찍히는 경우가 있습니다.

예를 들어 이런 로그가 반복될 수 있습니다.

GET /health 200 OK
GET /health 200 OK
GET /health 200 OK

 

이런 로그가 너무 많으면 실제 장애 로그가 잘 보이지 않습니다.

이럴 때는 grep -v로 /health가 들어간 줄을 제외할 수 있습니다.

 

grep -v "/health" access.log

 

최근 로그에서만 보고 싶다면 tail과 같이 씁니다.

 

tail -n 500 access.log | grep -v "/health"

 

이렇게 하면 최근 500줄 중에서 /health 요청을 제외한 로그만 볼 수 있습니다.

다만 health check 로그를 무조건 의미 없는 로그로 보면 안 됩니다.

헬스체크가 갑자기 실패하거나 응답 코드가 200이 아닌 상태로 바뀌었다면, 그것 자체가 중요한 단서가 될 수 있습니다.

그래서 처음에는 원본 로그를 조금 확인한 뒤, 반복되는 정상 헬스체크 로그만 제외하는 것이 좋습니다.

3단계. 정상 응답 로그를 제외하고 보기

애플리케이션이나 웹서버 access log에서 정상 응답이 너무 많이 찍힐 때도 있습니다.

예를 들어 200 OK가 너무 많으면 장애 상황에서는 방해가 될 수 있습니다.

 

grep -v "200 OK" access.log

 

최근 로그에서 정상 응답을 제외하고 보고 싶다면 이렇게 볼 수 있습니다.

 

tail -n 1000 access.log | grep -v "200 OK"

 

이렇게 보면 500, 502, 503, 504 같은 비정상 응답이 더 눈에 잘 들어올 수 있습니다.

하지만 주의할 점이 있습니다.

200 OK라고 해서 항상 의미 없는 로그는 아닙니다. 장애 상황에 따라 정상 요청 흐름도 같이 봐야 할 수 있습니다.

예를 들어 사용자는 오류를 겪고 있는데 access log에는 200만 찍힌다면, 화면 내부 API 호출, 프론트엔드 오류, 캐시, 리다이렉션 문제를 따로 봐야 할 수도 있습니다.

grep -v는 소음을 줄이는 도구이지, 판단을 대신해주는 도구가 아닙니다.

4단계. 여러 조건을 한 번에 제외하기

제외하고 싶은 문구가 하나가 아닐 때도 있습니다.

예를 들어 /health, /metrics, 200 OK를 빼고 보고 싶다면 이렇게 연결할 수 있습니다.

 

tail -n 1000 access.log | grep -v "/health" | grep -v "/metrics" | grep -v "200 OK"

 

의미는 이렇습니다.

1. 최근 1000줄을 본다
2. /health 로그를 뺀다
3. /metrics 로그를 뺀다
4. 200 OK 로그를 뺀다

 

조금 더 간단히 쓰고 싶다면 -E 옵션을 사용할 수 있습니다.

 

tail -n 1000 access.log | grep -v -E "/health|/metrics|200 OK"

 

이렇게 하면 여러 제외 조건을 한 번에 처리할 수 있습니다.

다만 grep -v 조건이 많아질수록 내가 무엇을 제외했는지 헷갈릴 수 있습니다.

장애 상황에서는 명령어를 너무 복잡하게 만들기보다, 하나씩 확인하면서 제외하는 편이 안전합니다.

5단계. grep -v와 grep을 같이 쓰기

grep -v는 다른 grep과 같이 쓰면 더 유용합니다.

예를 들어 최근 로그에서 error가 들어간 줄을 찾되, health 관련 로그는 제외하고 싶다면 이렇게 볼 수 있습니다.

 

tail -n 1000 service.log | grep -i "error" | grep -v "/health"

 

여러 에러 키워드를 찾으면서 특정 정상 로그를 제외할 수도 있습니다.

 

tail -n 1000 service.log | grep -i -E "error|exception|timeout" | grep -v "/health"

 

반대로 불필요한 로그를 먼저 제외한 뒤 에러 키워드를 찾을 수도 있습니다.

 

tail -n 1000 service.log | grep -v "/health" | grep -i -E "error|exception|timeout"

 

두 방식은 상황에 따라 다르게 쓸 수 있습니다.

에러 후보가 너무 많을 때
→ grep으로 먼저 찾고, grep -v로 불필요한 결과 제외

정상 로그가 화면을 너무 많이 가릴 때
→ grep -v로 먼저 소음 제거 후 grep으로 에러 검색

 

중요한 것은 명령어 순서보다 무엇을 제외했는지 알고 보는 것입니다.

에러 키워드를 찾는 기본 grep 사용법과 grep -C로 앞뒤 흐름을 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/24

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

 

https://opsnote.tistory.com/25

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

 

6단계. 특정 IP 로그 제외하기

운영 중에는 특정 IP에서 들어오는 요청이 너무 많아서 로그 확인이 어려울 때도 있습니다.

예를 들어 문서용 IP인 203.0.113.10 요청을 제외하고 보고 싶다면 아래처럼 볼 수 있습니다.

 

grep -v "203.0.113.10" access.log

 

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

 

tail -n 1000 access.log | grep -v "203.0.113.10"

 

다만 실제 운영 서버의 IP를 외부 문서나 블로그에 그대로 쓰면 안 됩니다.

블로그나 보고서에 쓸 때는 반드시 문서용 IP로 바꾸거나 마스킹해야 합니다.

실제 IP: 내부 운영 IP 그대로 사용 금지
문서용 예시: 203.0.113.10
마스킹 예시: 10.xxx.xxx.xxx

 

로그에는 IP뿐 아니라 도메인, 계정명, 토큰, 세션 정보가 포함될 수 있으니 외부 공유 전에는 반드시 가리는 습관이 필요합니다.

7단계. 특정 파일 요청 제외하기

웹서버 access log를 보면 정적 파일 요청이 많이 섞일 수 있습니다.

예를 들면 이런 요청입니다.

GET /favicon.ico
GET /static/app.js
GET /static/style.css
GET /images/logo.png

 

장애 상황에서 API 오류를 보고 싶은데 이런 요청이 너무 많이 섞이면 로그가 어수선해집니다.

이럴 때는 아래처럼 제외할 수 있습니다.

 

tail -n 1000 access.log | grep -v -E "favicon.ico|/static/|/images/"

 

이렇게 하면 정적 파일 요청을 어느 정도 걷어내고 API 요청이나 오류 로그에 집중할 수 있습니다.

다만 정적 파일 요청도 상황에 따라 중요할 수 있습니다.

예를 들어 배포 후 CSS, JS 파일이 404로 떨어진다면 화면 깨짐의 원인이 될 수 있습니다.

그래서 제외 조건은 항상 “지금 확인하려는 문제와 관련이 없는 로그”에만 적용하는 것이 좋습니다.

8단계. grep -v 사용할 때 위험한 예시

grep -v는 편하지만, 잘못 쓰면 필요한 로그까지 빼버릴 수 있습니다.

예를 들어 아래 명령어는 조심해야 합니다.

 

grep -v "error" service.log

 

이렇게 하면 error가 들어간 줄을 빼버리게 됩니다.

장애 원인을 찾아야 하는데 중요한 줄을 스스로 숨기는 셈입니다.

또 이런 경우도 조심해야 합니다.

 

grep -v "fail" service.log

 

fail이 들어간 줄이 실제 장애 단서일 수도 있기 때문입니다.

너무 넓은 조건도 위험합니다.

 

grep -v "GET" access.log

 

GET 요청을 모두 제외하면, 실제로 봐야 할 사용자 요청 흐름까지 사라질 수 있습니다.

초보 운영자라면 이렇게 생각하면 좋습니다.

반복되는 정상 로그만 제외한다.
장애 키워드는 제외하지 않는다.
제외 조건을 적용하기 전에 원본 로그를 먼저 본다.
제외한 조건을 보고서나 메모에 남긴다.

 

grep -v는 “불필요한 로그를 제거하는 도구”이지, “원인을 자동으로 찾아주는 도구”는 아닙니다.

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

로그 파일이 너무 큰 상태에서 계속 grep을 반복하면 확인이 오래 걸릴 수 있습니다.

먼저 파일 크기를 확인합니다.

 

ls -lh /app/logs/service.log

 

예시입니다.

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

 

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

 

tail -n 1000 /app/logs/service.log | grep -v "/health"

 

또는 최근 로그에서 에러 후보만 찾습니다.

 

tail -n 1000 /app/logs/service.log | grep -v "/health" | grep -i -E "error|exception|timeout"

 

로그 파일이 계속 커지는 상황이라면 단순히 grep으로 보는 것에서 끝나면 안 됩니다.

 

반복 오류, debug 로그, logrotate 설정 여부도 같이 확인해야 합니다.

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

https://opsnote.tistory.com/7

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

 

10단계. /var/log를 볼 때는 /var 용량도 같이 보기

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

grep -v로 정상 로그를 제외해서 보고 있는데도 같은 에러가 계속 반복된다면, 로그 파일이 빠르게 커지고 있을 수 있습니다.

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

 

df -h /var

 

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

 

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

 

/var에는 로그뿐 아니라 캐시, 스풀, 서비스 데이터도 함께 쌓입니다. /var 용량이 찼을 때 어떤 경로를 먼저 확인해야 하는지는 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/68

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

 

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

로그가 너무 많을 때는 무작정 제외 조건부터 걸지 말고, 원본 로그를 조금 본 뒤 반복되는 정상 로그를 확인하는 것이 좋습니다.

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

1. 최근 로그를 먼저 확인한다
2. 반복적으로 많이 나오는 정상 로그를 찾는다
3. 제외해도 되는 문구인지 판단한다
4. grep -v로 해당 로그를 제외한다
5. error, timeout 같은 키워드를 같이 확인한다
6. 제외 조건 때문에 중요한 로그가 빠지지 않았는지 다시 확인한다
7. 필요하면 앞뒤 로그와 실시간 로그도 확인한다

 

명령어로 보면 이런 흐름입니다.

 

tail -n 500 /app/logs/service.log

 

반복되는 /health 로그가 많다면 아래처럼 제외합니다.

 

tail -n 500 /app/logs/service.log | grep -v "/health"

 

에러 키워드까지 같이 보고 싶다면 아래처럼 확인합니다.

 

tail -n 1000 /app/logs/service.log | grep -v "/health" | grep -i -E "error|exception|timeout"

 

에러 앞뒤 흐름이 필요하다면 grep -C도 함께 사용합니다.

 

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

 

장애가 지금도 발생 중인지 확인해야 한다면 tail -f로 실시간 로그도 같이 봅니다.

 

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

 

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

https://opsnote.tistory.com/21

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

 

12단계. 실무 보고 예시

grep -v로 불필요한 로그를 제외하고 확인했다면 이렇게 정리할 수 있습니다.

최근 애플리케이션 로그에서 반복적으로 발생하는 health check 로그를 제외하고 확인했습니다.
제외 후 error, exception, timeout 키워드 기준으로 추가 확인하겠습니다.

 

정상 응답 로그를 제외하고 봤다면 이렇게 쓸 수 있습니다.

access log에서 정상 200 응답 로그를 제외하고 비정상 응답 여부를 확인했습니다.
일부 timeout 관련 요청이 확인되어 해당 시간대의 서버 상태를 추가 확인하겠습니다.

 

아직 원인이 확실하지 않을 때는 이렇게 정리할 수 있습니다.

반복 로그를 제외하고 확인했으나, 단일 로그 기준으로 원인 확정은 어렵습니다.
프로세스 상태, 포트 상태, 애플리케이션 로그를 함께 확인하겠습니다.

 

제외 조건을 명확히 남기고 싶다면 이렇게 정리할 수 있습니다.

최근 1000줄 기준 /health, /metrics 요청을 제외하고 로그를 확인했습니다.
제외 조건 적용 후에도 동일 ERROR 로그가 반복되어 에러 전후 흐름을 추가 확인하겠습니다.

 

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

정리하면

리눅스 서버 로그가 너무 많을 때는 grep -v로 불필요한 로그를 제외하고 볼 수 있습니다.

기본 형태는 아래입니다.

 

grep -v "제외할문구" service.log

 

INFO 로그를 제외하려면 아래처럼 확인합니다.

 

grep -v "INFO" service.log

 

헬스체크 로그를 제외하려면 아래처럼 볼 수 있습니다.

 

tail -n 500 service.log | grep -v "/health"

 

여러 조건을 제외하려면 -E 옵션을 사용할 수 있습니다.

 

tail -n 1000 access.log | grep -v -E "/health|/metrics|favicon.ico"

 

에러 키워드와 같이 보려면 아래처럼 확인합니다.

 

tail -n 1000 service.log | grep -v "/health" | grep -i -E "error|exception|timeout"

 

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

로그가 너무 많을 때는 grep -v로 반복되는 정상 로그를 제외하고, 실제로 봐야 할 로그만 남깁니다.

다만 제외 조건을 너무 넓게 잡으면 필요한 에러 로그까지 같이 빠질 수 있습니다.  
그래서 grep -v는 결과를 줄이는 용도로 사용하되, 조건을 적용한 뒤에도 남은 로그가 의미 있는지 다시 확인해야 합니다.

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

https://opsnote.tistory.com/24

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

 

에러 한 줄만 보고 원인을 놓치지 않으려면 grep -C로 앞뒤 흐름도 함께 확인하는 것이 좋습니다.

https://opsnote.tistory.com/25

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

 

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

https://opsnote.tistory.com/7

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