FEAT: Add Operation throughput and latency metrics by mbean.

[brido4125]

🔗 Related Issue

https://github.com/jam2in/arcus-works/issues/615

⌨️ What I did

아래의 정보를 MBean을 통해 노출시켜 jmx-export를 통해 수집될 수 있도록 하였습니다.
메트릭들의 수집 단위는 하나의 java process 입니다.
즉, N개의 ArcusClient 전부에 대한 수집방식입니다.

• Throughput
  • Completed : 연산에 성공한 Op 개수
  • Canceled : 내부 / 외부(사용자)에 의해서 취소된 Op 개수
  • Timeouted : timeout이 발생한 Op 개수
• Latency : 최근 10,000개의 연산에 대한 아래 항목별 Latency 수집
  • avgLatency
  • minLatency
  • maxLatency
  • 25% Latency
  • 50% Latency
  • 75% Latency

그라파나 대시보드는 이슈 내에 기입되어 있습니다.

[uhm0311]

1차 리뷰 의견입니다.

[uhm0311]

2차 리뷰 의견입니다.

[uhm0311]

이것만 수정하면 될 것 같습니다.

[brido4125]

@jhpark816

이 PR을 리뷰하기전에 본 구현이 어떤 목적의 변경인지 또는 해당 구현에 대한 설명이 필요하신가요?
필요하다면 오프라인으로 준비하겠습니다.

[jhpark816]

@brido4125
우선 순위가 낮아서 다른 작업들을 먼저 보고 있습니다.
이 작업에 대해 나중에 살펴보고, 설명 여부를 요청할게요.

[namsic]

아래 내용 중에 잘못 이해한 부분이 있나요?

1. resetStatistics() 직접 호출하지 않으면 lastTime은 변하지 않는 값입니다.
2. 따라서 elapsedSeconds는 계속해서 커지게 됩니다.
3. 구동 이후 충분한 시간이 흐른 뒤에는, 순간적인 요청량 변화가 Throughput에 드러나지 않게 됩니다.

예를 들어,
모니터링 시작 이후 하루(86,400 초)동안 요청이 없으면, CompleteOps metric 값은 0입니다.
하루가 지나는 시점에 초당 10,000개 요청을 1분간 처리한 후 CompleteOps metric 다시 확인해 보면,
초당 처리량은 6 (600,000 / 86,460 = 6.93…)으로 나타날 것 같은데, 맞나요?

[brido4125]

node-exporter나 arcus-exporter 등의 다른 메트릭 수집프로그램에서는
초당 요청량 등을 보통 어떻게 처리하나요?

알고 있는 context가 있으면 설명 부탁드려요

[namsic]

metric type은 대부분 counter와 gauge로 나눌 수 있는데, 둘의 차이를 알고 있나요?
요청량과 같은 수치는 일반적으로 exporter 수준에서 초당 변화량을 계산하지 않고, 누적값을 counter metric으로 내보냅니다.

예를 들어, arcus_cmd_get metric은 초당 get 요청 처리량이 아니라
구동 이후 누적 get 요청 처리량(== memcached stats 결과를 그대로 사용)이고, 계속해서 증가만 하는 값입니다.

실제로 초당 요청량은 Grafana에 작성된 promQL 질의가 수행되면서 계산됩니다.

https://prometheus.io/docs/prometheus/latest/querying/examples/

[brido4125]

Throughput 관련 메트릭들은 counter 타입으로 수집되도록 변경했습니다.

[jhpark816]

@brido4125
본 PR을 아직 리뷰 못한 상태이지만, merged_next_time 태그를 달아 두었습니다.
따라서, 본 PR도 naver 저장소의 brido4125/metrics 브랜치로 옮기고 PR 보내 주시죠.