도메인별 로그 분리로 모니터링 확장성 확보

site-pv 모니터링 시스템에 새로운 도메인을 추가하는 작업이었다. 단순히 도메인명을 리스트에 넣는 것만이 아니라, 전용 access.log를 분리하고 표시 구조까지 정리했는데, 이 과정에서 로그 기반 모니터링 시스템을 확장할 때 무엇을 고려해야 하는지 다시 한번 정리할 수 있었다.

기존 구조의 한계와 분리의 필요성

원래 site-pv는 여러 도메인의 페이지뷰 데이터를 수집·분석하는 역할을 하고 있었다. 도메인이 하나둘 추가될 때는 문제가 안 보이지만, 로그 파일이 방대해지면서 몇 가지 문제가 생긴다. 첫째, 특정 도메인의 트래픽만 추적하려 할 때 전체 로그에서 필터링하는 오버헤드가 늘어난다. 둘째, 로그 로테이션(rotation)이나 백업 전략을 도메인별로 달리 가져가기 어렵다. 셋째, 장애나 이상 트래픽을 분석할 때 해당 도메인의 로그만 빠르게 격리해서 볼 수 없다.

그래서 saju.opsvoro.com을 추가할 때, 처음부터 전용 access.log를 분리하기로 했다. 도메인별 로그 파일을 나눠 관리하면 쿼리 성능이 올라가고, 나중에 다른 도메인을 추가할 때도 같은 패턴을 반복할 수 있다.

구현: 도메인·로그경로 매핑과 표시목록

실제 수정은 site-pv.py에서 두 가지를 정리했다. 하나는 도메인과 로그 파일 경로를 명확히 매핑하는 설정 구조다.

# 도메인별 access.log 경로 매핑 (설정 예)
DOMAIN_LOGS = {
    'existing.domain': '/var/log/existing.access.log',
    'another.service': '/var/log/another.access.log',
    'saju.opsvoro.com': '/var/log/saju.opsvoro.access.log',
}

이렇게 하면 코드에서는 도메인만 알면 바로 해당 로그 파일을 찾을 수 있다. 나중에 로그 경로 정책이 바뀌어도 이 설정만 수정하면 된다.

두 번째는 표시목록 업데이트다. 모니터링 대시보드나 관리 화면에서 도메인 목록을 렌더링할 때, 수동으로 리스트를 관리하면 누락하거나 순서가 꼬인다. 그래서 위의 설정 딕셔너리 key들을 순회해서 표시목록을 자동으로 생성하도록 처리했다:

# 표시목록 자동 생성
DISPLAYED_SITES = list(DOMAIN_LOGS.keys())

이 방식이면 새 도메인을 추가할 때 DOMAIN_LOGS에만 추가하면 표시목록도 자동으로 갱신된다. 휴먼 에러를 줄이고, 설정이 단일 소스 오브 트루스(single source of truth)가 된다.

확장성과 관리 관점에서 본 개선

실제로 이런 구조는 다른 로그 기반 모니터링에서도 자주 본 패턴이다. ELK 스택(Elasticsearch-Logstash-Kibana)도 index를 도메인/서비스별로 분리하는 게 표준이고, 젠킨스나 CI/CD 시스템의 빌드 로그도 프로젝트/Job별로 격리한다. 이게 단순히 "깔끔함" 차원이 아니라 성능과 유지보수성을 결정하는 아키텍처 선택이라는 점을 이번 작업으로 또 확인했다.

팀 관점에서의 의미

이 작업은 단순한 피처 추가가 아니라 기존 시스템의 확장성을 개선하는 것이었다. 새 도메인이 추가되고, 또 추가될 것인데, 매번 코드 여러 곳을 뜯어고치는 것보다 처음부터 확장 가능한 구조를 만드는 게 팀의 운영 비용을 줄인다. 누군가 다음에 도메인을 추가할 때 "어디를 수정하지?" 하고 헤맬 필요가 없어진다. 설정 파일만 열면 된다.

또 로그 파일을 분리하면서, 로테이션 정책이나 저장 기간을 도메인별로 다르게 가져갈 기반도 마련했다. 트래픽 패턴이 다른 서비스들이면 보관 기간을 달리 설정할 수 있다는 뜻이다. 지금은 당장 필요 없지만, 추후 스토리지 비용을 줄여야 할 때 유연하게 대응할 수 있다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.