왜
메트릭 한도 조사(TeamPiKi/infra#42)에서 spring_data_repository_invocations_seconds_* 가 384 시리즈를 쓰면서 대시보드·알림 어디에서도 참조가 0건인 것이 드러났다. 처음엔 감축 대상으로 뒀으나, 지우는 대신 뷰에 올려 값어치를 쓰는 쪽으로 방향을 잡았다.
트레이스의 JDBC 스팬(piki-db query)은 단건 맥락을 보여주지만 추세는 못 보여준다. "어느 repository 메서드가 자주 불리고 느려지고 있나"는 메트릭만 답할 수 있고, 그 데이터는 이미 수집되고 있다.
무엇을
infra/grafana/dashboard.json 의 의존성 row(HikariCP 커넥션풀 옆)에 패널 2개를 추가한다.
- Repository 호출률 (상위 10) —
topk(10, sum by (repository, method) (rate(spring_data_repository_invocations_seconds_count[$__rate_interval])))
- Repository 평균 소요시간 (상위 10) — 같은 그룹의
_sum / _count 비율
$environment 변수를 따르고, 카디널리티가 크므로 topk 로 상위만 그린다.
왜
메트릭 한도 조사(TeamPiKi/infra#42)에서
spring_data_repository_invocations_seconds_*가 384 시리즈를 쓰면서 대시보드·알림 어디에서도 참조가 0건인 것이 드러났다. 처음엔 감축 대상으로 뒀으나, 지우는 대신 뷰에 올려 값어치를 쓰는 쪽으로 방향을 잡았다.트레이스의 JDBC 스팬(
piki-db query)은 단건 맥락을 보여주지만 추세는 못 보여준다. "어느 repository 메서드가 자주 불리고 느려지고 있나"는 메트릭만 답할 수 있고, 그 데이터는 이미 수집되고 있다.무엇을
infra/grafana/dashboard.json의 의존성 row(HikariCP 커넥션풀 옆)에 패널 2개를 추가한다.topk(10, sum by (repository, method) (rate(spring_data_repository_invocations_seconds_count[$__rate_interval])))_sum/_count비율$environment변수를 따르고, 카디널리티가 크므로topk로 상위만 그린다.