웹·앱 로그 장애 분석 보고서 LPIC›로그 분석·어려움

새벽 배포 직후 고객사에서 "오전 9시쯤부터 결제 API가 간헐적으로 실패한다"는 문의가 들어오면, 운영 담당자는 모니터링 대시보드가 잡아내지 못한 구간을 확인하기 위해 서버에 직접 접속해 원본 로그를 펼칩니다. 장애 보고서에는 감이 아니라 숫자가 들어가야 하므로, 특정 시간대 오류 건수와 비정상 응답을 유발한 상위 클라이언트, 그리고 어느 모듈에서 실패가 집중됐는지를 손으로 집계하게 됩니다.

리눅스의 텍스트 로그는 대부분 한 줄이 한 사건이고, 공백으로 구분된 필드가 일정한 자리를 차지합니다. 이 규칙성 덕분에 grep으로 대상 줄을 좁히고, awk로 원하는 필드만 꺼내고, sort와 uniq를 이어 붙여 빈도를 세는 조합이 성립합니다. 여기서 흔한 실수는 단순 문자열 검색과 필드 단위 판별을 같은 것으로 여기는 일입니다. 특정 숫자로 시작하는 값은 상태코드 자리뿐 아니라 응답 크기나 메시지 본문에도 나타날 수 있어, 줄 어딘가에 그 문자열이 있는지와 정해진 필드 값이 그러한지는 전혀 다른 조건입니다. 날짜 필터 역시 마찬가지로, 여러 날짜가 섞인 파일에서는 시간 조건만으로 충분하지 않습니다.

이런 집계 유형은 LPIC-1의 텍스트 스트림 처리와 로그 관리 영역에서 반복해서 다뤄지며, 서버 운영자와 SRE가 장애 보고서를 작성할 때 가장 먼저 쓰는 기본기입니다.