로그를 모으는 데 드는 비용

로그를 한 자리에 모으기로 하고 각 서버에 수집기를 올렸다. 붙인 다음 날 응답 시간이 늘었다는 말이 나왔다.

Open Table of contents

붙이고 나서 늘어난 것

자원 사용량을 보니 수집기가 애플리케이션보다 많은 처리 능력을 쓰고 있었다. 디스크 읽기도 늘어 로그 파일을 계속 읽고 있었다.

로그를 모으는 것 자체가 공짜가 아니라는 것이 숫자로 드러났다. 붙인 뒤에 재 보지 않았으면 응답 지연의 원인을 애플리케이션에서 찾았을 것이다.

수집기 설정을 보니 각 서버에서 정규식으로 한 줄씩 뜯어 구조화하고 있었다. 초당 수천 줄이면 그만큼 정규식이 돈다.

보내는 비용보다 파싱하는 비용이 훨씬 컸다. 무엇이 비싼지를 가르지 않으면 전송량만 줄이는 엉뚱한 대응으로 간다.

파싱을 각 서버에서 저장소 쪽으로 옮기니 서버의 사용량이 크게 내려갔다. 저장소 쪽은 전용 장비라 그 처리를 감당할 여유가 있었다.

같은 처리를 어디서 하느냐가 비용을 통째로 바꾸므로 여유가 있는 쪽에서 하게 배치한다. 더 나은 방법은 애플리케이션이 처음부터 구조화된 형태로 쓰는 것이라 새로 쓰는 로그부터 그렇게 바꿨다.

종류별 양을 세어 보니 디버그 로그가 가장 많은데 아무도 보지 않았다. 오류와 경고와 접속과 감사만 보내고 디버그는 서버 파일로만 남겨 며칠 뒤 지우게 하니 전송량이 크게 줄었다.

보관 기간도 종류마다 다르게 뒀다. 오류와 감사는 오래 봐야 하고 접속 로그는 통계를 뽑은 뒤에는 덜 보므로 필요한 용량이 절반 아래로 내려갔다.

저장소가 죽으면 수집기가 못 보내므로 디스크에 쌓아 두고 붙으면 보내게 했다. 쌓이는 양에 상한을 두고 넘으면 오래된 것부터 버리게 했는데 로그 때문에 서비스가 멈추면 안 되기 때문이다.

수집기가 살아 있는지와 얼마나 밀렸는지와 버린 것이 있는지를 셌다. 로그 수집이 안 되면 아무 로그도 안 남으므로 그 상태는 로그가 아니라 별도 경로로 확인하게 했다.