쇼핑몰 WAS 모니터링 타겟 추가로 운영 가시성 확보

쇼핑몰 WAS 한 대를 Prometheus 타겟에 추가했다. 스케일 자체는 작은 작업이었는데, 할 때마다 느끼는 게 있어서 조금 길게 남겨본다.

관찰 가능성(observability) 스택을 처음 구성할 때는 "일단 돌아가게만 하자"는 마음으로 몇 가지를 빼두는 경우가 많다. 내부 배치 서버라든가, 트래픽 적은 어드민 WAS라든가. 그러다 진짜 장애가 났을 때 "그 서버만 메트릭이 없네"가 된다. 이번엔 그 전에 넣었으니 다행이다.

구조 개요

현재 스택은 Spring Boot Actuator → Prometheus scrape → Grafana 시각화 흐름이다. Zipkin/Tempo도 트레이싱용으로 연동돼 있고, 로그는 Loki로 떨어진다.

Actuator 설정은 아래처럼 최소한만 노출한다.

management:
  endpoints:
    web:
      exposure:
        include: health,prometheus
  metrics:
    export:
      prometheus:
        enabled: true

include에 * 넣으면 편하긴 한데, env, beans, heapdump 같은 엔드포인트가 같이 열린다. 운영 환경에서 그건 좀 부담스럽다. health와 prometheus만 넣는 게 현재 팀 기준이고, 내부 네트워크에서만 붙을 수 있도록 IP 필터도 별도로 달아뒀다. 허용 목록에 없는 IP는 403이 아니라 아예 연결이 안 되는 방향으로.

이번 작업에서 한 번 막힌 게 있었는데, YAML 파싱 문제였다. IP 목록을 YAML 파일에서 읽어서 필터에 넘기는 로직이 있는데, 값 앞뒤에 공백이 섞여 들어오면서 허용 IP인데 차단이 되는 상황이 생겼다. trim() 한 줄로 해결되긴 했지만, 설정값을 코드에서 가공 없이 그대로 쓰는 습관이 얼마나 위험한지 다시 확인했다. 외부에서 들어오는 문자열은 늘 방어적으로 다뤄야 한다.

Grafana 대시보드 지표 선택 기준

타겟이 추가되면 Grafana에서 바로 볼 수 있도록 datasource 설정과 대시보드를 갱신했다. 매번 새 WAS 추가할 때마다 같은 작업을 반복하게 되는데, 그 과정에서 나름 정리된 지표 우선순위가 생겼다.

전부 한 대시보드에 욱여넣으면 정작 장애 때 뭘 봐야 할지 헷갈린다. 팀에서는 Overview 대시보드 하나, 서비스별 상세 대시보드 하나로 분리해서 쓰고 있다. Overview는 한 화면에 전체 WAS 상태를 훑을 수 있게, 상세는 특정 인스턴스 문제를 파고들 때 열어본다.

알림 설정은 임계치 초과 시 슬랙 채널로 보내게 연동해뒀다. p99 레이턴시가 기준 이상으로 올라가거나 에러율이 일정 비율을 넘으면 바로 알림이 온다. 야간에 장애가 터졌을 때 메트릭이 없으면 아침에 로그 뒤지는 것밖에 방법이 없는데, 그 경험을 한 번 하고 나서 알림 설정에 더 신경 쓰게 됐다.

Loki 연동도 해뒀다. 특정 에러 로그 패턴이 대시보드의 에러율 스파이크와 겹치는 구간을 바로 드릴다운할 수 있어서 원인 추적 시간이 꽤 줄었다. 메트릭만 있으면 "에러가 늘었다"는 건 알지만 "왜"는 로그를 따로 뒤져야 하는데, 두 개를 한 화면에서 연결할 수 있으면 그 갭이 사라진다.

이번 작업에서 정리된 것들

관찰 가능성 스택은 한번 잘 잡아두면 이후 추가가 빠른 반면, 설계가 어긋나면 타겟이 늘어날수록 관리 부채가 쌓인다. Prometheus 타겟 설정을 파일 기반으로 관리하는지, 서비스 디스커버리로 자동화했는지에 따라 WAS 한 대 추가 비용이 크게 달라진다.

• 정적 파일 관리: prometheus.yml에 직접 추가. 단순하지만 서버 늘어날수록 수작업 증가
• 파일 기반 서비스 디스커버리: file_sd_configs로 외부 JSON/YAML 파일 참조. 파일만 갱신하면 reload 없이 반영 가능
• Kubernetes 환경이라면 Prometheus Operator + ServiceMonitor CRD 조합이 표준적인 방향

현재는 정적 파일이지만, WAS 수가 일정 이상 넘어가면 파일 SD 전환을 검토해야 할 것 같다. 이번 추가를 하면서 수작업의 피로를 조금 느꼈다.

YAML 파싱 이슈처럼, 운영 인프라 설정 파일은 사람이 직접 편집하는 만큼 사소한 실수가 꽤 나온다. 들여쓰기 틀리거나, 공백 섞이거나. 설정 파일을 코드로 관리하고 변경 시 lint나 검증 단계를 거치는 게 귀찮아도 결국 시간을 아껴준다는 걸 다시 한번 확인했다.