[Grafana] Opentelemetry: spanmetric 구성하기

이전 포스트
https://blog.naver.com/sssang97/223764113482
https://blog.naver.com/sssang97/223761188760

단순히 API에 대한 기록을 보고 싶다면 Tempo 등을 사용해서 trace를 기록하면 된다.
그러면 API들이 얼마나 호출되었는지, 오류율이 얼마인지 같은 통계성 데이터를 보고 싶다면 어떻게 해야할까?

그런걸 위한 기능요소 중 하나가 바로 spanmetric이다. 각각의 span을 기반으로 metric을 구성한다는 의미다.

본 포스트에서는 otel-collector를 기반으로 prometheus에 통계를 쑤셔넣고 사용하는 방법을 간단히 다뤄보겠다.

otel-collector 설정

spanmetric은 실제로 span-trace 데이터를 기준으로 생성되는 메트릭 데이터다.

connectos 옵션을 통해서 데이터를 어떻게 넘겨받을 지를 정의할 수 있다.

connectors:
  spanmetrics:
    namespace: http_server_request
    dimensions:
      - name: http.method
      - name: http.status_code
      - name: http.route
      - name: service.namespace	
    histogram:
      unit: s
    exemplars:
      enabled: true
    events:
      enabled: true
      dimensions:
        - name: exception.type
        - name: exception.message

http_server_request라는 접두어로 metric이 쌓이게 했고, http.method를 비롯한 span의 데이터들을 계승받아서 저장하도록 했다.
그리고 기록 단위는 초 단위다. 기본값은 밀리초단위인데, 난 그정도는 필요없어서 이렇게 했다.

이 부분이 특히 grafana 대시보드 환경에서 특히 개떡같이 되어있는 부분 중 하나다.
보통은 대시보드 템플릿 라이브러리를 가져다가 편하게 쓰는 것을 원할 것이다.

로그나 trace는 어느 정도 정형화가 되어있고 선형적인 데이터라서 대충 쑤셔넣고 아무거나 띄우면 시각화가 잘 되는데, 이건 잘 안된다.
otel-collector 자체가 하위호환을 보장하지 않고 0,* 상태로 폭주중인 것도 있고, span에게서 계승받는 데이터도 다 자기들 맘대로 채워넣고 그런다. 그래서 grafana 라이브러리에 있는 opentelemetry 템플릿들 보면 데이터 형태나 metric 이름을 가정한게 다 다르다.

제대로 쓰려면 어느 정도 데이터 수집 구조를 알고 설정할 줄도 알아야 한다.

service에도 spanmetric 관련 옵션을 적당히 채워준다.

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]
    metrics/spanmetrics:
      receivers: [spanmetrics]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      exporters: [spanmetrics, otlp]
  telemetry:
    metrics:
      address: 0.0.0.0:8888
      level: detailed

이 정도면 된다.

span->metric 전이는 otel-collector 수준에서 다 해주는거라서, 이미 metric&trace 설정이 잘 되어있다면 애플리케이션 수준에서 에이전트 조정을 더 해줘야 할 것은 없다.

Grafana 대시보드 활용

이제 대시보드 라이브러리 가져다가 직접 띄워보고 써보자.

난 이 라이브러리를 사용했다.
https://grafana.com/grafana/dashboards/22784-lightweight-apm-for-opentelemetry/

혹시 삭제되었을 때를 가정한 다운로드 json 백업
첨부파일22784_rev3.zip파일 다운로드 아무튼 저걸 import해서 대시보드를 띄워보면

매우 높은 확률로 데이터가 뻗어있을 것이다.
실제로 단순 timeseries로 조회해보면 데이터가 다 있음에도.

하나 열어서 보고 고치면서 써보자.

해석해보면, http_server_request_duration_seconds_count라는 메트릭을 조회하되, job으로 필터를 걸고, 집계하고 해서 값을 나타낸다는 뜻이다.

내 경우엔 위에서 http_server_request를 namespace로 설정하고, histogram을 second로 조정했기 때문에 완전히 동일한 이름으로 메트릭이 생성되었다.
그런데 job이 좀 이상하다. 이 경우에는 k8s에서의 사용만을 전제하고 저 필드가 있을 것이라 기대하는데, 지금 내 환경과 구성에서는 service_namespace와 service_name이 따로 있다.

필터를 조정해보자.

이러면 따로따로 존재하는 필드에 대해서 필터를 걸 것이고

조회도 잘 되기 시작할 것이다.

다른거 또 안되는걸 보면

http_response_status_code로 응답코드를 필터링해서 오류를 보여주고 있다.
근데 나는 방금 위에서 http.status_code로 span 데이터를 그대로 전이시켰는데, 이러면 기본적으로 http_status_code라는 이름으로 매핑되어서 불일치가 발생한 것이다.

다시 맞춰서 돌려보면 이제 또 잘 뜰 것이다.

비슷한 느낌으로 이래저래 조정하다보면

적당히 그럴듯한 모습이 될 것이다.

참조
https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/connector/spanmetricsconnector/README.md