Rails 애플리케이션에 들어오는 존재하지 않는 URL 요청은 404 응답을 내더라도 Rollbar에 예외 이벤트를 쌓을 수 있다. ActionController::RoutingError를 Rollbar 보고 대상에서 제외하면 이런 이벤트가 모니터링 할당량과 조사 시간을 차지하는 일을 줄일 수 있지만, 요청 자체를 차단하거나 Rails의 처리 부담을 없애지는 않는다.
게시물에 나온 요청은 /private-key, /.env.live, /.env.stage처럼 비밀 정보가 담길 수 있는 파일 경로를 여러 디렉터리에서 빠르게 탐색하는 형태였다. Rails는 일치하는 경로가 없으면 ActionController::RoutingError를 발생시키고, 운영 환경에서는 이를 404 응답으로 처리한다. 그러나 Rollbar가 예외도 수집해, 존재하지 않는 파일을 찾는 요청마다 모니터링 이벤트가 발생했다.
Rollbar 화면에는 PerplexityBot 1.0, OAI-AdsBot 1.0, MoonshotBot 1.0 같은 이름도 보였다. 다만 화면에 표시된 것은 파싱된 클라이언트 라벨이지 전체 User-Agent 값이 아니며, 발신자를 확인해 주지도 않는다. 게시물은 원시 사용자 에이전트와 요청 로그의 클라이언트 IP를 확인하고, 가능한 경우 운영자가 공개한 검증 지침과 대조하라고 설명한다. 스크린샷의 server.host는 애플리케이션 서버를 가리키므로 스캐너의 출발지 IP로 볼 수 없다.
게시물에 소개된 변경은 기존 Rollbar 초기화 파일에 예외 필터를 추가하는 것이다.
# config/initializers/rollbar.rb Rollbar.configure do |config| # Existing configuration... config.exception_level_filters.merge!( 'ActionController::RoutingError' => 'ignore' ) end
이 설정은 처리되지 않은 라우팅 오류를 Rollbar 이벤트로 보내지 않으며, 알 수 없는 URL에는 계속 404를 반환한다. 다른 애플리케이션 예외는 계속 Rollbar에 전달된다. merge!를 사용하므로 기존 예외 필터도 유지된다. 자세한 내용은 Rollbar의 Ruby 예외 필터 문서에서 확인할 수 있다.
다만 이 필터는 정상적인 링크 오류로 발생한 라우팅 오류도 숨길 수 있다. 그런 오류를 찾으려면 액세스 로그와 404 지표를 살펴봐야 한다. 라우팅 오류가 중요한 서비스라면 알려진 스캔 경로만 걸러내는 좁은 필터가 더 적절할 수 있다. Rollbar.error(exception)처럼 명시적으로 호출하는 보고에도 필터를 적용하려면 use_exception_level_filters: true 옵션이 필요하다.
이 조치는 Rollbar의 잡음을 줄이는 데 그친다. 스캐너 요청을 막거나 Rails가 요청을 처리하는 데 드는 작업을 없애지는 않는다. 트래픽이 고객에게 영향을 줄 만큼 부담이 되면 Rails에 도달하기 전 요청을 제한하거나 필터링하는 별도 조치가 필요하다. New Relic에서 응답 시간이 일시적으로 약 160ms까지 올랐다가 이전 수준에 가까워졌지만, 해당 차트와 Rollbar 이벤트 화면은 서로 다른 시간대를 다룬다. 두 화면만으로 스캔 요청이 지연을 일으켰다고 단정할 수 없으며, Rollbar 보고가 외부 처리 시간의 원인이었는지도 집계 차트만으로는 확인되지 않는다.
게시물은 기존 애플리케이션을 넘겨받는 팀이라면 자주 발생하는 예외와 그에 해당하는 요청·추적 정보를 함께 살펴보고, 어떤 이벤트를 오류 보고에 남길지와 각 알림의 담당자를 정하라고 제안한다. 서비스에 영향을 주는 오류와 예상 가능한 인터넷 잡음을 구분하면 모니터링 용량과 조사 시간을 중요한 장애에 더 집중할 수 있다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요