Webflux & SCG - Grafana uri Path Metrics "UNKNOWN" 노출

Webflux & SCG - Grafana uri Metrics "UNKNOWN"

본문 제목만 보면 어떤문제인지 잘 감이 안온다. 

쉽게 말해보자면 아래와 같은 Grafana 모니터링 Dashboard 가 있을때 Http URI Path 가 사용자가 요청한 Path 가 나오는게 아닌

"UNKNOWN" 으로 표시되는 문제이다.

 

해당 문제는 Spring Cloud Gateway - Grafana 환경에서 발생하였다.

Spring Cloud Gateway(SCG) 는 reactive 프레임워크를 사용하고 있으며(반대는 mvc) SCG 에서는 둘중 어떤 프레임워크를 사용하던

동일한 문제가 발생중인것으로 확인되었다.

Spring Boot Observability

 

 

 

사진이 자세히 보이지 않으니 더 자세하게 보자면, 우리가 원하는 Metric 수집은 아래 처럼 path 경로가 나오는것이다.

 

 

 

 

하지만 아래처럼 200, 403 등 모든 요청이 UNKNOWN 으로 표기되며 어떤 Path 에 대한 Request 인지 확인할 수 없는 문제가 있다.

UNKNOWN

 

 

그라파나에서는 다른 정보들은 잘 보여지고 있었기 때문에 Metric 정보를 보내주는곳이 문제라고 생각했다.

필자의 경우 보안을 위해 Metric 을 제한적으로 노출시키고 있었는데 (Prometheus, Info, health)

prometheus 에 보내지는 Metric 정보를 확인해보니 실제로 URI Tag 가 UNKNOWN 이었다.

(캡쳐를 못해놨다,...)

 

 

GPT의 도움을 받아 yml 상에서 여러 시도를 진행해 보았다.

management:
  metrics:
    tags:
      uri: "http.path"  # 기본적으로 URI 태그 추가
  endpoints:
    web:
      exposure:
        include: prometheus
  metrics:
    web:
      server:
        request:
          autotime:
            enabled: true

라던지 ,,,

 

management:
  observations:
    http:
      server:
        requests:
          name: http.server.requests

이런 설정들이었다. GPT 의 요지는 "SCG 에서는 Path 요청을 처리할때 UNKNOWN 이 나올 가능성이 있다." 라고 했다.......(?)

 

여러가지 설정을 했음에도 불구하고 똑같이 UNKNOWN 이 노출되었기 때문에 구글링을 하며 좀더 찾아보았다,,,,,,,,,,

한글로는 아무리 검색해도 아무곳도 없었다...

Stack Over Flow 또한 동일한 케이스가 보이지 않았다.

 

최후의 방법으로 SCG Repository, Spring Repository 의 Issue 들을 찾아보기 시작했다. Spring Cloud Gateway 에서 나처럼

Prometheus + Grafana 조합으로 Monitoring 을 시도해본 사람은 분명 있을거라고 생각했기 때문이다 ,,,,,

 

 

 

결과는 

 

 

 

https://github.com/spring-cloud/spring-cloud-gateway/issues/891

Bug: uri metric label on gateway routes appears as "UNKNOWN" in prometheus export · Issue #891 · spring-cloud/spring-cloud-gat

 

완벽하게 동일한 이슈가 존재했다....... 비록 2019 년 이슈이긴하지만 공식적으로는 해결된 내용을 찾지 못했다 ..

2021년 댓글에는 Spring 자체의 문제라고 결정되었다고 한다,,(?)

비슷한 이슈로는 아래 이슈가 존재한다(Spring)

https://github.com/spring-projects/spring-boot/pull/15609

 

 

 

 

아래 댓글들을 더 보던 도중 "danparisi" 라는 개발자의 2024년도 댓글을 봤다.(24년도까지 해결이 안되었다는 말 같다.)

 

https://github.com/spring-projects/spring-boot/pull/15609#issuecomment-2250236409

Align WebFluxTags#uri() with WebMvcTags#uri() by dreis2211 · Pull Request #15609 · spring-projects/spring-boot

 

WebFlux 의 Tags#Uri() 문제를 해결한 코드였다. 

(더 아래에 보면 Reactive가 아닌 MVC 방식에서 해결된 Code 도 존재함.)

 

 

Solution Code

 

이 설정은 /metrics API에서 URI 값이 UNKNOWN으로 설정되는 문제를 해결하기 위한 코드이고, 기본 키 값들을 가져와서

URI 값이 UNKNOWN 이거나 null 인경우 실제 URI 값을 넣어주는것으로 보인다.

 

 

 

적용 이후 재배포를 진행해봤더니,,,,,,,

모든 URI Path 가 정상적으로 모니터링되는것을 확인할 수 있었다......

 

 

 

다만 해당 이슈에서 추가적인 문제가 제기되었고, 이 방법에 문제가 있을수도 있다는것을 알게되었다.

 

URI Path 를 이런 방식으로 모두 수집하게 된다면(Metric)

카디널리티 폭팔(Cardinality Explosion) 이 발생할 수 있다고 한다...

 

 

메트릭 시스템에서 카디널리티는 Label 의 조합으로 인해 생성될 수 있는 데이터 포인트 개수를 의미한다.

즉, 카디널리티 폭팔은 Metric Data 가 폭발적으로 증가한다는 것이다..

http_server_requests_seconds_count{method="GET", status="200", uri="/api/users/1"} 1 http_server_requests_seconds_count{method="GET", status="200", uri="/api/users/2"} 1 http_server_requests_seconds_count{method="GET", status="200", uri="/api/users/3"} 1 http_server_requests_seconds_count{method="GET", status="200", uri="/api/users/4"} 1 http_server_requests_seconds_count{method="GET", status="200", uri="/api/users/5"} 1 ...

이런식으로 동적 URL 들을 Tag 로 그대로 저장하게 되며, ID 값 마다 새로운 Metric 이 생성되고, Request 가 많아질수록

Metric 개수가 폭발적으로 증가한다. 그에따라 저장공간과 조회 성능이 급격하게 저하된다.

 

즉 아래와 같은 보안취약점을 유발할 수 있다.

1. OOM 공격 가능
2. 서비스 장애 유발 가능(Dos, Slow Query)
3. 디스크 사용랑 폭발

 

URI Path Pattern 을 실제 패턴을 저장하여(동적 패턴 -> 정적 패턴) 방지하던지,,,,, 아니면 Prometheus 설정에서

최대 카디널리티 제한을 걸어두는것이 가장 좋은 방법처럼 보여진다... 

global:
  scrape_interval: 15s

limits:
  max_time_series: 100000  # 10만 개 이상 메트릭이 저장되지 않도록 제한
  max_samples_per_query: 5000  # 한 번의 쿼리에서 최대 5000개 샘플만 조회 가능

 

 

비싸고 좋은 모니터링 툴을 사용한다면,,, 이런 문제는 다 해결해줬을테지만,,, 무료로 가성비를 따져야 하는 상황이니 

시스템에 필요 요소를 잘 선택하여 설정해야 할 것 같다.