[요약] Handling Billions of Metrics with Prometheus/Thanos

reference - Kubeday Singapore 2023: Handling Billions of Metrics with Prometheus/Thanos

https://static.sched.com/hosted_files/kubedaysingapore2023/54/Kubeday%20Singapore%202023%20-%20Handling%20Billions%20of%20Metrics%20with%20Prometheus_Thanos.pdf

 

 

Agenda

1. Prometheus와 Thanos를 통한 대규모 메트릭 진화
2. 블루그린, 카나리 배포를 위한 argo rollout 과 매트릭
3. Numaproj를 통해 AIOPS 를 위한 매트릭 활용
4. ArgoCD 매트릭 확장 대시보드
5. Prometheus Kafka Adaptor를 통한 매트릭 -> event bus로의 골든시그널 push

Prometheus와 Thanos를 통한 대규모 메트릭 진화

• RED 방법론으로 골든시그널 생성. rate (처리율), errors (오류 수), duration (처리 시간)
• prometheus kafka adpator 로 골든시그널을 publish
• Thanos 도입 = prometheus HA 구성, 3rd party storage에 매트릭 보관
  • admin -> Thanos query -> prometheus (sharding)
    • sharding 에 의한 변화
      • admin -> Thanos query -> Thanos recieve -> s3
      • Thanos ruler -> Thanos receive/prometheus kafka adaptor/prometheus storage adaptor -> Thanos query
  • admin -> Thanos query -> Thanos store -> s3 (or minio 등 호환)
  • prometheus main /query에 직접엑세스로 prometheus  부하 증가에 대한 조치
    • Thanos query를 용도별로 (여기서는 admin, Numaproj, argocd) 나누고 recieve도 각각

Argo-Rollouts

• opensource deployment controller
• 블루그린, 카나리, 매트릭을 활용한 progressive delivery 지원

AIOPS with Metrics

• 이상점수 사용 -> 이상 감지 속도 up
• MTTD(평균감지시간), MTTR(평균수리시간) 단축
• Argo-Rollouts은 요구되는 품질을 불충족한 변경사항에 대한 자동 롤백에 유용
• challenges
  • 과거 데이터 엑세스
  • 부하기반 scale
  • but, cluster prometheus 는 많은 동작을 하고 있음(룰평가, HPA매트릭 서빙 등)
• 초기 해결방안
  • s3 에 8일간의 매트릭 보관
  • Thanos Store로 s3 데이터 조회
  • Thanos query frontend 사용으로 큰 데이터셋 조회
  • 단점: 모든매트릭이 유용하지않고, s3 버켓에 모든매트릭이 포함되며, 전체TSDB 블록을 메모리에 올리는 행위가 AIOPS매트릭조회시 발생
• 개선안
  • 필요한 매트릭정보만 Thanos Receive에 쓰고, local TSDB에 8일간의 매트릭 보관
  • s3대신 EBS 사용
  • query frontend는 그대로 사용
  • 장점
    • 데이터 저장, 조회 빈도가 낮아져 전체 퍼포먼스 향상
    • 당연하게도 큰 비용절감

ArgoCD Live Metrics

• argoCD의 새로운 extension
• argoCD UI를 통해 CPU, Memory, HTTP Errors 확인 가능

 

Golden Signals Metrics to Kafka

• 요건
  • 복수개의 카프카 토픽으로의 데이터 전송
  • 태그기반 필터링
• Challenges
  • 오픈소스 Prometheus-kafka-adapter는 복수개의토픽 지원하지않고, graceful shutdown, connection handling 없음
  • ~25%의 메모리 과다사용
  • 해결: custom prometheus kafka adapter 개발로 해결

 

 

• 리뷰 후기
  • 큰규모의 클러스터를 운영하면서 정리된 내용이라 흥미롭다.
  • prometheus는 항상 rethink 이기보다 afterthought에 가까웠었는데 과정을 다시 생각해보게됐다
  • 커스텀 프로메테우스 카프카 어댑터가 궁금한데 데모영상이 없어서 아쉽고, 쓰다보니 또 다시 번역이 되간다