본문 바로가기
Data Engineering

[Data Analyst] Prometheus & Grafana 이해와 활용 (오픈소스 모니터링 시스템)

by newstellar 2021. 9. 10.
반응형
for 개발자, DevOps, Data Analyst/Scientist

 

  • Prometheus : 메트릭 & 얼러트 기반 오픈소스 모니터링 솔루션
  • Grafana : 옵저버빌리티를 위한 오픈소스 기반 데이터 시각화 플랫폼
  1. 프로메테우스 개요
  2. 프로메테우스 아키텍쳐
  3. Prom QL
  4. Data Collection
  5. Alert
  6. Grafana 개요 및 구성
  • 리눅스 명령어/지식 필요, Docker, Docker-compose 사용 경험 있으면 좋음

 

1. Prometheus 개요

 

1) Prometheus란?

  • Metric Collector + Metric DB
    • 오픈소스 monitoring/alerting tool으로 SoundCloud에 의해 2012년 시작되어 2016년에 v1 출시함

    • 메트릭 수집 + 시각화 + 알람이 핵심 기능



2) 용어

  • Monitoring : query count, error count, 처리 시간, 서버 활성 시간 등의 정량적 수치를 실시간으로 처리하는 행위

  • Observability : 모든 장애 가능성을 알 수 없다는 예측 불가능을 전제로 하며, Monitoring의 상위 개념. 모니터링을 통해 상태를 확인하고, 특정 임계치에 대한 Alert를 발생시키기 위해 Metrics을 수집

  • Metrics : 응용 프로그램 및 서비스의 성능/품질을 측정하기 위한 정량 데이터
    ex) DB 또는 API의 Latency time, Request content length, Cache hit/miss count

  • Tracing : 서비스 요청에 대한 어플리케이션 또는 서비스 구조 확인을 뜻하며, 모든 서비스들 간의 데이터 흐름을 시각화하여 아키텍처 상의 병목 현상 파악을 목표로 함

  • Logging : 실행중인 프로세스에서 발생하는 이벤트인 Log를 수집해서 보여주는 것
    ex) ELK, EFK

  • White-box monitoring : 로그, JVM의 프로파일링 등의 interface 또는 내부 통계정보를 보내주는 HTTP 핸들러를 포함한, 시스템 내부에서의 측정기준에 근거한 모니터링. 대시보드 시각화로서 내부 작동 상태를 확인 및 예측할 수 있음.

  • Black-box monitoring : 외부에서 사용자의 관점으로 테스팅하는 것으로, 서비스 포트 오픈 여부, HTTP request에 대한 status code가 올바른지 관찰함.



3) Metrics 수집 방식의 이해

  • Push : 모니터링 주체가 서버에 정보를 보내는 것으로, CMDB 및 수집 서버 정보가 필요함. 메트릭 정보가 변경될 때마다 일괄 배포하며 대표적인 SW로는 TICK Stack(Telegraf + InfluxDB + Chronograf + Kapacitor)과 Nagios가 있음.

 

  • Pull : agent처럼 수집 서버 정보를 몰라도 서버에서 필요한 메트릭을 수집하는 방식으로,

 


2. Prometheus Architecture

 

1) Basic Component

  • Prometheus는 크게 메트릭을 수집/저장하는 중앙 서버인 Prometheus Server와 시스템/어플리케이션과 관련된 데이터를 expose하는 agent인 Exporters로 구성된다.

 

prometheus-architecture



2) Scrape

  • Prometheus는 기본적으로 Pull 방식으로 time-series data를 scrape하며, agent가 서버로 Push 하는 경우는 제한적이다.

 

  • 두 가지 형태로 HTTP Scraping을 하는데, 그 첫 번째는 /metrics endpoint에서 직접적으로 스크래핑하는 것이며, 나머지는 Exporter를 거쳐 application, node, DB에서 스크래핑하는 것이다.

    image

Exporters : 코드를 직접 수정할 수 없는 패키징 SW Metrics를 노출시킬 때, 네트워크와 스토리지, DB 또는 시스템 계측 시 사용한다.

image

Official Exporters로 등록된 것으로는 Consul, Memcached, MySQL Server, Node 등이 있다.

 

 

3) Pushgateway

  • Pull 방식을 사용하지 않고 어플리케이션이나 서비스에서 직접 Metrics를 Push하는 API를 제공한다.

 

  • 언제 끝날지 모르는 짧은 주기의 Batch Job 등 특정 시점에서 Scrape이 불가능한 환경에서 주로 사용한다.

 

  • Firewall/NAT로 인해 네트워크가 분리된 경우는 Pushgateway가 아닌 PushProx를 적용한다.

    image



4) Client Libraries

  • Official Library : Go, Python, Java, Ruby

 

  • Unofficial Library : Bash, C/C++, Perl, PHP, R, Dart

    image



5) Service Discovery

  • Cloud 환경에서는 scale-in/out 등 인스턴스가 생성/소멸되거나 배포하는 과정에서 서비스의 IP가 동적으로 변경되는 일이 잦다. 이때 Cloud에서의 변경사항을 API Gateway나 Client 서비스가 알아차리게 도와주는 것을 Service Discovery라고 한다.

 

  • Client-side Discovery vs Server-side Discovery 패턴
    • Client-side Discovery : Service Registry에서 서비스의 위치를 찾아 호출하는 방식으로 서비스 instance 생성 시 NW 위치가 service registry에 등록되고 instance가 종료될 때 삭제된다. Client가 사용가능한 서비스를 알기 때문에 상황에 따라 적절한 Load Balancing이 가능하지만 Client - Service Discovery 사이에 의존성이 생긴다는 단점이 존재한다.

    • Server-side Discovery : Load Balancer가 service registry로 query를 날리고 각 요청을 서비스 instance로 라우팅한다. 대표적으로 AWS Elastic Load Balancer(ELB)가 인터넷에서 들어오는 외부 트래픽을 로드밸런싱하는 사례다. 외에도 Kubernetes나 Marathon 등의 배포환경은 클러스터 내의 각 호스트에서 proxy를 실행한다. Client에서 Discovery 기능을 분리할 수 있으나 Load Balancing을 위해 고가용성을 유지해야 한다.

 

 

6) Prometheus의 장단점

  • 장점
    • 하나의 장소에 여러 가지 Metrics 데이터 수집 가능

    • 문제 분석을 위해 시각화(대시보드) 구성이 용이함. Grafana에서 별도의 대시보드를 만들 수 있지만 간단한 Ad-hoc UI 제작 가능함.

    • 서비스 장애 / 비가동 상황 시 빠른 파악과 알림 구성이 쉬움.

    • 수많은 Metrics를 직접 보지 않아도 되므로 트래픽/오버헤드 감소

    • Pull 방식이 불가능한 경우 Pushgateway로 Push 방식 수집 가능

 

  • 단점
    • billing 데이터와 같은 정확한 데이터로 활용하는 것은 적합하지 않음.

    • 장애 상황에 새로운 데이터를 수집하지 못했을 경우를 고려하기 힘듦.

    • 시계열 데이터가 아닌 경우, 즉 일반적인 log나 index가 필요한 데이터의 경우 적합하지 않음.

 


3. Grafana

1) 개요 및 핵심 개념

  • 오픈소스 기반의 분석/모니터링 도구로 다양한 DB 연동을 통해 대시보드(시각화) 구성 가능

  • 시계열 데이터 외에 log 및 trace도 시각화 가능

  • 하나의 대시보드에 여러 Panel(Graph, Gauge, Table 등) 구성할 수 있으며 자체Alert 기능을 제공한다. (email, slack, telegram, Kafka 등)

 

 

2) 구성 요소

  • Datasources
    • 독립적으로 구성된 Datasource마다 별도의 Query Editor를 제공하며, Grafana Core에서 제공하지 않는 Datasource들은 Plugin으로 추가 가능

    • 시계열 데이터 Storage : Prometheus, Graphite, InfluxDB

    • Logging : Loki, ElasticSearch

    • Tracing : Zipkin, Tempo, Jaeger

    • Cloud : CloudWatch, Azure Monitor, Grafana Cloud, Google Cloud Monitoring

 

  • Query Editor
    • 여러 가지 중첩된 Query(Compound Query)를 수행할 수 있으며 Datasource별로 특정 기능을 수행할 수 있도록 관련 기능을 탑재함.

    • Query 내에 다양한 템플릿 변수 등을 통해 동적으로 데이터 탐색 가능 (PromQL의 한계 보완)

 

  • Panels
    • Query 결과를 시각화하며 Plugin으로 확장 제공한다. graph, singlestat, alert list, heatmap, table 등의 여러 형태를 시각화할 수 있다.

 

  • Rows
    • 여러 Panel을 포함하는 논리적인 개념으로, collapse / uncollapse 기능이 있음.

 

  • Dashboard
    • Panel과 Row로 구성되며, 정해진 시간을 설정하여 Naming과 Tagging, 그리고 Sharing이 가능한 Dashboard를 생성할 수 있음.

 

반응형

댓글