Prometheus

💿 Prometheus

메트릭 기반의 오픈소스 모니터링 시스템

• PromQL 기반의 단순하면서 강력한 데이터 모델

Monitoring(모니터링)

종류

• 알림(alerting): 문제가 발생한 시기나 시점을 파악
• 디버깅(Debugging): 문제의 근본 원인을 규명, 해결
• 추세파악(trending): 긴급하지 않은 문제인 경우에는 시스템이 어떻게 사용되고 시간에 따라 변화하는지도 확인
  • 알림과 디버깅은 보통 몇 분부터 몇 시간까지 시간 단위로 발생하기 때문
• 플러밍(Plumbing): 데이터 파이프라인 구축
  • 결국 모든 모니터링 시스템은 데이터 처리 파이프라인

범주

• 프로파일링(profiling): 모든 시간에 대해 모든 이벤트의 컨텍스트를 가질 수 없지만 제한된 기간의 일부 컨텍스트를 가질 수 있다는 방식으로 접근
  • Tcpdump: 지정된 필터를 기반으로 네트워크 트래픽을 기록(디스크 공간이 부족해 질 수 있음)
  • Debug builds: 함수 호출 타이밍 같은 정보를 모두 수집(성능에 영향을 끼침)
  • eBPF: 파일 시스템부터 네트워크 기호까지 커널 이벤트에 대해 상세하게 프로파일링
• 트레이싱(Tracing): 관심 기능을 통과하는 이ㅏㄹ부 이벤트처럼 수백개의 이벤트 중특정 이벤트에만 집중한다.
  • ex) HTTP 요청 중 하나를 샘플링하고 이 요청에 대해 데이터베이스나 캐시 같은 백엔드와 통신하는데 얼마나 오랜 시간이 소비되었는지 확인
  • 분산 트레이싱(distributed tracing): 원격 프로시저 호출에서 한 프로세스에서 다른 프로세스로 전달되는 요청에 고유한 ID를 추가해, 해당 요청이 처적되어야 하는지 여부 등 프로세스 전반에 걸친 작업을 추적한다.(Zipkin, Jaeger)
  • 샘플링: 데이터 볼륨 유지 및 계측 성능에 영향을 미치는 것
• 로깅(Logging): 제한된 이벤트 집합을 살펴보고 각 이벤트에 대한 컨텍스트 일부를 기록
  • ex) 수신되는 모든 HTTP 요청이나 발신되는 모든 DB 호출 같은 이벤트를 살펴보고 기록
  • 범주
    • 트랜잭션 로그(Transaction logs): 매우 중요함. 주로 비용과 관련된 기능이나 사용자가 직접 사용하는 주요기능이 트랜잭션 로그에 속함
    • 요청 로그(request logs): 모든 HTTP 요청이나 DB 호출을 추적하는 경우의 로그다. 사용자가 직접 사용하거나 내부 최적화의 구현에 쓰임
    • 애플리케이션 로그(application logs): 프로세스 자체에 관한 로그
    • 디버그 로그(Debug logs): 생성과 저장에 비용이 많이 듬
  • 예로는 ELK 스택과 그레이로그 등이 있다.
• 매트릭(Metric): 컨텍스트를 대부분 무시하고 다양한 유형의 이벤트에 대해 시간에 따른 집계(aggregation)을 추적
  • ex) HTTP 요청 횟수, 요청처리 시간, 현재 진행중인 요청 수
  • 로그에 많은 필드를 기록할 수는 없다.
    • 메트릭은 프로세스 전반에 걸쳐 이벤트 정보를 수집할 수 있지만 일반적으로 카디널리티가 제한된 컨텍스트는 1~2개 이상의 필드를 갖지 않는다.
    • 로그는 한가지 유형의 이벤트에 대해 모든 정보를 수집할 수 있지만 카디널리티가 제한되지 않은 컨텍스트에 대해 수백 개 필드만 추적할 수 있다.

즉 Prometheus는 개별 이벤트보다는 전반적인 시스템의 상태와 동작, 성능을 추적하도록 설계되었다.

• 다시말해, Prometheus는 처리하는데 4초가 걸린 15개의 요청이 마지막 1분동안 발생했고 결과적으로 40번의 DB 호출과 17번의 캐시 히트와 2건의 고객 구매가 일어났다는 사실에만 주의를 기울임
• 각 호출에 걸린 비용과 코드 경로는 프로파일링이나 로깅의 관심사

💿 Prometheus 구조

내부 모듈

• Retrival: 메트릭을 수집할 대상 서버에 접근해서(HTTP) 메트릭을 가져오거나 아니면 Pushgateway를 통해서 접근할 수 없는 곳에 있는 데이터(inner server, firewall 내부의 metric 등)을 가져오는 역할
  • Proxy Forwarding을 해서 접근할 수 없는 곳에 데이터가 존재하는 경우 이때 사용하는 대안(사내망에 데이터가 있어서 외부에서 scrape를 못하는 경우)
• TSDB: 가져온 데이터를 저장하고 시간의 흐름에 따라 조회를 할 수 있어야 하므로 시계열 데이터(time-series)를 저장할 수 있는 저장소
  • Local Storage, Remote Storage 두가지 방법 사용

구조

• Service Discovery: Prometheus는 기본적으로 모니터링 대상 목록을 유지하고 있으며 대상에 대한 ip나 기타 접속 정보를 설정 파일에 주어서 모니터링 정보를 가져오는 방식을 사용한다.
• Exporter: 모니터링 Agent로 타겟 시스템에서 메트릭을 읽어서 Prometheus가 풀링 할 수 있도록 함
• Push Gateway: 서비스 레벨의 일괄처리 작업에 대한 메트릭 캐시
  • 일괄처리 작업: 시간 단위나 일 단위 등의 방식으로 정기적인 일정에 따라 수행됨
    • 지속적으로 동작하지 않기 때문에 Prometheus는 이러한 작업에 대한 정보를 정확하게 수집할 수 없다.
    • 실제로 적용하는 instance 레이블이 없음 즉 하나의 머신이나 프로세스 인스턴스에 묶이는 것이 아니라 모든 서비스에 적용됨
    • 예를 들어 모든 서비스에 대한 가비지 컬렉션을 수행하는 작업, 고장난 머신을 찾기위한 데이터 센터의 일괄처리 작업
• 브릿지: 클라이언트 라이브러리로 메트릭을 원하는 방식으로 처리할 수 있게 함
• 파서: 프로메테우스 표시 형식을 파싱할 수 있는 기능(그 밖의 모니터링 시스템이나 로컬 도구에 전달 할 수 있다.)

💿 메트릭

종류

• 카운터(Counter): 이벤트의 개수나 크기를 추적하며, 주로 특정 경로의 코드가 얼마나 자주 실행되는지 추적하는데 사용
• 게이지(Gauge): 현재 상태에 대한 스냅샷
  • 카운터가 얼마나 빨리 증가하는가(미분값)인 반면 게이지는 실제값에 관심을 둔다
  • ex) 대기열 내의 항목 개수, 캐시의 메모리 사용량, 활성 스레드 개수,레코드가 처리된 마지막 시간
• 서머리(Summary): 값의 증감을 관찰하고 전체 합계를 확인
  • 특정 시간 내의 전체 값이나 양을 구성하기 편함
• 히스토그램(Histogram): 응답 크기, 요청 기간 등 start ~ end 단위의 주기내에서 값의 증감을 관할하고 전체 합계를 모두 확인
  • 버킷: 1밀리초에서 10초 범위를 다룬다.(Web App의 일반적인 대기시간의 범위를 처리하기 위함)

형식

<메트릭 이름="">{<레이블 키="">=<레이블 값="">, <레이블 키="">=<레이블 값=""> ...} <메트릭 값=""> []

• 레이블: metric의 특징을 표현
  • 계측 레이블: 라이브러리 내부에서 알 수 있는 내용을 담고있음
    • HTTP 요청 타입이나 통신 대상 DB등
  • 대상 레이블: 데이터를 수집하는 특정 모니터링 대상을 식별
  • 카디널리티: Prometheus가 확보한 Metric 개수
• 타임스탬프: Unix epoch 시간 부터 경과된 시간을 밀리초 단위의 정수로 표시