junha-ahn
commented
1 year ago 매트릭에 관해서
출처 (더 자세한 정보는 해당 출처로)
- https://stackoverflow.com/questions/67964176/springboot-observability-on-max-count-sum-metrics
- Prometheus rate() 연산의 실행 원리
Count / Sum
count와 sum은 일반적으로 평균을 계산할때 사용됩니다.
count는 횟수를 누적한다sum은 무언가의 총 가치를 보유하고 있다.
http_server_requests_seconds_sum 10
http_server_requests_seconds_count 5 - 위의 예를 들어보면, HTTP 요청이 5개 있었고, 총 지속시간은 10초였다
sum / count로 나누면 평균 요청시간은 2초이다.- average request duration (=average latency) 라는 유용한 패널을 만들 수 있다.
Rate
시계열 데이터 중에는 그 자체의 값보다 변화량이 더 중요한 경우가 있다
예를 들어 리눅스의 cpu 사용량은 어떤 프로세스가 실행되는 동안 cpu를 점유한 시간으로 정의된다. cpu 점유 시간 자체는 프로세스가 종료되기 전까지 계속 증가할 수 밖에 없기 때문에, 단순히 cpu 점유 시간이 많은 프로세스를 점검하는 것보다 cpu 점유 시간이 최근 빠르게 늘어난 프로세스를 점검하는 것이 시스템 관리 측면에서 훨씬 도움이 된다.
rate() 연산은 지정한 시간 범위 내에 메트릭이 변화한 정도를 보기 위한 연산이다. 특히 Counter 타입의 메트릭과 자주 사용되는데, 끊임없이 증가하기만 하는 raw data를 볼 이유가 없기 때문이다. Counter 타입 메트릭의 대표적인 예로 앞서 소개한 cpu 사용 시간이 있다.
rate() 계산 방법
rate는 range vector의 처음과 끝의 샘플을 이용해 '초당 평균 변화율'을 계산한다. t1과 t2 사이의 초당 평균 변화율은 (sample(t2) - sample(t1)) / (t2 - t1) 을 통해 계산한다. 당연히 range vector 내에 최소한 두 개의 샘플이 존재해야 한다
너무 짧은 시간(1분)의 테스트인 Spike Test가 대부분의 그래프를 그려내지 못하는 이유도 다음 이유때문이였다.
예를 들어 1분 동안의 rate를 계산한다고 가정하자. 데이터는 15초마다 수집 되었고 값은 [10, 20, 50, 80] 이다. rate는 첫 샘플인 10과 마지막 샘플인 80을 통해 계산한다. 앞서 소개한 공식대로 계산하면70 / 60 = 1.166 이 된다.
물론 위의 상황에서 첫 샘플과 마지막 샘플을 이용해 rate를 구할수도 있다. 그러나 이렇게 되면 1분 간의 평균 변화율이라는 쿼리의 의도와 맞지 않게 된다. Prometheus는 실제 점 대신 가상의 점을 추측하여 사용하는 외삽(extrapolation)을 이용한다.
외삽을 하는 방법은 다음과 같다. 우선 첫 샘플과 끝 샘플을 이은 직선을 긋고 기울기를 구한다. 이 기울기가 관측되지 않은 기간에도 유지되었을 것이라고 가정하고, time-range 경계에 가상의 점을 찍는다. 이 가상의 점들끼리 rate() 연산을 해 변화량을 구한다.
데이터의 왜곡을 방지하기 위해 시간 범위의 경계와 샘플의 경계가 너무 멀 때는 외삽으로 찍는 점의 범위를 제한한다.
Request Count Per Second
rate(http_server_requests_seconds_count[5m])- Prometheus는 지정된 간격(예제에서는 5분)에서 샘플을 가져와 현재 시점(으로 추정되는 값)과 차이를 계산한다
- 얻은 값을 seconds in the interval (5m)으로 나눈다
구간이 짧으면 그래프가 톱처럼 보이고, 구간이 길면 선이 더 매끄럽고 변화를 표시하는 속도가 느려진다.
Average Request Duration
http_server_requests_seconds_sum / http_server_requests_seconds_count하지만 그래프에서는 직선만 보일 가능성이 높습니다. 이는 해당 측정항목값이 시간이 지남에 따라 너무 커지고, 이 쿼리가 차이를 표시하려면 정말 급격한 변화가 발생해야 하기 때문. 이러한 특성으로 데이터 간격 샘플에 대한 평균을 계산하는게 더 좋다. increase() 함수를 사용해서 inteval 동안 매트릭이 어떻게 변화했는지에 대해 '근사값'을 얻을 수 있다.
increase(http_server_requests_seconds_sum[5m]) / increase(http_server_requests_seconds_count[5m]) Scrape Interval 조절
출처
- https://stackoverflow.com/questions/66549609/what-is-the-minimum-scrape-interval-in-prometheus
- https://www.robustperception.io/keep-it-simple-scrape_interval-id/
- https://grafana.com/blog/2020/09/28/new-in-grafana-7.2-__rate_interval-for-prometheus-rate-queries-that-just-work/
요약
- 1초 등의 너무 짧은 시간은 의미가 없다 (네트워크 지연 등)
- 모든 서비스에 단일한 scrape interval을 사용해라
그렇다면 나는 어느정도의 inteval을 사용해야할까?
일반적으로 Grafana와 Promethus 모두 Scrape Inteval을
60s으로 설정하는 것이 좋습니다. from
그러나 1분 미만의 Spike Test가 목적임으로 inteval을 15s으로 설정하자.
Description
성능테스트에 따른 대시보드 고도화
Latency파악을 위해 모든 대시보드에 항목 추가기타
아래와 같은 키워드로 Computing 자원 대시보드를 잘 찾아야...
Data Empty
data empty문제는 모두 짧은 테스트 시간으로 인해 발생하는 데이터 부족이 원인 (rate그래프 등)15s로 조정To do
Spring AppNginxK6이후 작업
users/signin엔드포인트 unknown 문제 해결 (링크)Test Checklist
테스트 시나리오 1
테스트 시나리오 2