1. 개요
최근에 Grafana에서 Query-less experience(쿼리를 하지 않는 경험)을 중요시하고 있는 것으로 보인다.
Query-less experience란 PromQL, LogQL, TraceQL 등을 수행하지 않고 Web UI에서 버튼만으로 사용자가 손쉽게 메트릭, 로그, 트레이스를 조회하고 손쉽게 디버깅을 할 수 있도록 하는 경험을 뜻한다.
이를 통해 Query를 잘 알지 못하는 사용자도 빠르게 관련된 메트릭을 찾아 문제를 빠르게 해결할 수 있도록 도와주는 것 같다.
Grafana에서는 크게 4가지의 Query-less 경험을 제공하려고 하는 것 같다.
[1] 시계열 메트릭 : Explore Metrics
https://www.youtube.com/watch?v=JbaPufQs5LY
[2] 로깅 : Explore Logs
https://www.youtube.com/watch?v=iH0Ufv2bD1U
[3] 프로파일링 : Explore Profiles
https://www.youtube.com/watch?v=_8SbNN5DRmQ
[4] 트레이싱 : Explore Traces
이건 아직 블로그나 공식 유투브에 올라오지 않았지만 최근 Tempo Community Call를 봤을 때 슬슬 준비중인 것으로 보인다.
https://www.youtube.com/watch?v=xsmlok1VDIA&list=PLDGkOdUX1Ujqe8WZ8T1h2pNjpll0t-KLw&index=43
2. Explore metrics, logs, traces, profiles에 대한 개인적 견해
2.1. Explore metrics
Explore metrics의 경우 자사 Grafana에 실제로 적용하고 사용도 해보았지만 결국 PromQL을 쓰게 되는 것 같다.
사용하기도 조금 불편할 뿐더러 유의미하지 않는 쿼리까지 수행하며 그래프를 보여주기 때문에 쿼리 속도 또한 다소 느릴 수 밖에 없다.
이 중 가장 중요한 부분이 '쿼리 속도'일 것 같은데 쿼리를 하지 않고 최대한 유의미한 결과를 보여주려고 하다보니 불필요한 쿼리까지 수행하게 되며 이는 단기간 쿼리에는 상관없겠지만 7일 이상의 쿼리를 수행하고자 하면 급속도로 느려지는 경험을 할 수 밖에 없다.
Explore Metrics 사용해보기
2.2. Explore logs
Explore logs는 Explore Metrics과는 반대로 꽤나 쓸만할 것으로 생각된다.
왜냐하면 Application의 로그 패턴을 분석하고 이를 그래프로 시각화하여 보여주기 때문이다.
하지만 이 또한 가장 우려되는 부분은 '쿼리 속도'인데 7일치 이상 쿼리를 조회했을 때도 단시간안에 패턴을 분석한 뒤 그래프로 보여주는게 과연 간단할지 의구심이 들 수밖에 없다.
따라서 쿼리를 최대한 빠르게 수행할 수 있는 환경이 갖춰져야 한다고 생각한다.
필자는 Chunk deduplication을 적용하기 위해 Chunk cache에 cache-stub 인자를 활성화하여 ingester에서만 chunk를 cache하고 querier에서는 object storage(s3)에서 fetch하여 memcache 인스턴스의 비용을 줄이고자 했다.
하지만 Explore logs를 하려면 최대한 캐싱을 적극 활용하여 query latency를 적극적으로 줄여야 할 것으로 보인다. 추가로 result cache도 적극적으로 캐싱하여 log message를 시계열 메트릭으로 변환하는 과정을 최소화해야하지 않을까 싶기도 하다.
Explore logs를 사용하기 위해서는 사전 준비가 몇가지 필요한 것으로 보인다.
- Grafana v11.0+
- Loki v3.0.0+
- limits_config.volume_enabled: true
- grafana-cli으로 plugin 설치
- ...
자세한 내용은 아래를 참고해보자.
https://grafana.com/docs/grafana-cloud/visualizations/simplified-exploration/logs/access/#install-in-loki
<<사용후기 추가>>
정말 느리고 아직 못 쓸 정도이니까, GA 되거나 레퍼런스가 많이 나올때까지 기다려보자..
2.3. Explore Traces
Explore Traces란 TraceQL Metrics를 활용하여 Trace 데이터를 기반으로 시계열 메트릭을 추출하여 유의미한 결과를 도출해내는 것으로 보인다.
(중요한건 아직 Frontend와 Backend 모두 한창 개발중인 것으로 보이기 때문에 Public Preview 조차 시간이 꽤나 걸릴 것으로 추측)
Tempo Community Call의 내용을 추측해보자면 위에 빨간색 박스가 'RED 메트릭'에 대한 그래프이고 3개의 그래프 중 하나를 클릭하면 아래에는 각각 Request, Error, Duration에 대한 그래프가 출력이 된다.
서비스 이름을 기준으로 필터링할수도 있어 보이고, 서비스이름을 필터링하지 않는다면 어떤 서비스에서 에러가 주로 발생하는지도 확인할 수 있다.
하지만, Explore Metrics와 Explore Logs와 다르게 Explore Traces는 '쿼리 속도'가 매우 현저히 느릴 것이라고 생각되고 만약 샘플링 정책이 적용되어 있다면 RED 메트릭은 완전한 메트릭을 도출할 수 없게 된다는 단점 또한 존재하게 된다.
TraceQL Metrics의 동작 원리를 아직 자세히 모르지만 아직까지는 Querier와 Metrics Generator가 과도한 일을 할 수 밖에 없는 구조이다.
Tempo가 애초에 'Time Range 내의 모든 Trace를 가져온 뒤, TraceQL 조건에 매칭되는 Span들을 Iterate하여 필터링'하는 과정을 거치기 때문에 여기에서도 상당히 과중한 업무를 하게 되는데 TraceQL Metrics까지 도입되면 Span 데이터를 시계열메트릭으로 변환해야하는 과정까지 거쳐야한다.
따라서 결론적으로 Explore Metrics는 과연 실무에서 사용할 때 도움이 될 수 있을까?라는 걱정이 들 수밖에 없다.
그래도 이런 부분만 개선이 되거나 최적화를 이뤄낸다면 3가지 Explore 메뉴 중 가장 쓸만한 게 아닐까 생각이 되기도 한다.
2.4. Explore Profiles
아직은 프로덕션 서비스에 이슈가 터질때나 부하테스트를 할 때만 사용하기 때문에 이 부분은 자세히 말을 못하겠다.
언젠간 Opentelemetry에서 Profile agent를 활용할 수 있게 되고 Pyroscope Helm Chart도 개선이 되면 추후에 적극적으로 도입에 대해 고민할 것 같다.
'Log,Monitorings' 카테고리의 다른 글
[ECK Elasticsearch] 데이터 노드가 재시작되면 레이턴시가 급증했던 이슈 (1) | 2024.12.05 |
---|---|
Opentelemetry에 대해서 간단히 알아보기 (1) | 2024.09.28 |
[Log] Grafana Loki 성능 최적화 방법 정리 (0) | 2024.04.07 |
[Opentelemetry Collector] RED Metric 생성과 샘플링 정책 완벽히 구성하기 (10) | 2024.03.19 |
[Log] Grafana Loki 로그 Write 시 참고 사항 (3) | 2024.02.17 |