반응형
for 개발자, DevOps, Data Analyst/Scientist
- Prometheus : 메트릭 & 얼러트 기반 오픈소스 모니터링 솔루션
- Grafana : 옵저버빌리티를 위한 오픈소스 기반 데이터 시각화 플랫폼
- 프로메테우스 개요
- 프로메테우스 아키텍쳐
- Prom QL
- Data Collection
- Alert
- Grafana 개요 및 구성
- 리눅스 명령어/지식 필요, Docker, Docker-compose 사용 경험 있으면 좋음
1. Prometheus 개요
1) Prometheus란?
- Metric Collector + Metric DB
- 오픈소스 monitoring/alerting tool으로 SoundCloud에 의해 2012년 시작되어 2016년에 v1 출시함
- 메트릭 수집 + 시각화 + 알람이 핵심 기능
- 오픈소스 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로 구성된다.
2) Scrape
- Prometheus는 기본적으로 Pull 방식으로 time-series data를 scrape하며, agent가 서버로 Push 하는 경우는 제한적이다.
- 두 가지 형태로 HTTP Scraping을 하는데, 그 첫 번째는 /metrics endpoint에서 직접적으로 스크래핑하는 것이며, 나머지는 Exporter를 거쳐 application, node, DB에서 스크래핑하는 것이다.
Exporters : 코드를 직접 수정할 수 없는 패키징 SW Metrics를 노출시킬 때, 네트워크와 스토리지, DB 또는 시스템 계측 시 사용한다.
Official Exporters로 등록된 것으로는 Consul, Memcached, MySQL Server, Node 등이 있다.
3) Pushgateway
- Pull 방식을 사용하지 않고 어플리케이션이나 서비스에서 직접 Metrics를 Push하는 API를 제공한다.
- 언제 끝날지 모르는 짧은 주기의 Batch Job 등 특정 시점에서 Scrape이 불가능한 환경에서 주로 사용한다.
- Firewall/NAT로 인해 네트워크가 분리된 경우는 Pushgateway가 아닌 PushProx를 적용한다.
4) Client Libraries
- Official Library : Go, Python, Java, Ruby
- Unofficial Library : Bash, C/C++, Perl, PHP, R, Dart
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을 위해 고가용성을 유지해야 한다.
- Client-side Discovery : Service Registry에서 서비스의 위치를 찾아 호출하는 방식으로 서비스 instance 생성 시 NW 위치가 service registry에 등록되고 instance가 종료될 때 삭제된다. Client가 사용가능한 서비스를 알기 때문에 상황에 따라 적절한 Load Balancing이 가능하지만 Client - Service Discovery 사이에 의존성이 생긴다는 단점이 존재한다.
6) Prometheus의 장단점
- 장점
- 하나의 장소에 여러 가지 Metrics 데이터 수집 가능
- 문제 분석을 위해 시각화(대시보드) 구성이 용이함. Grafana에서 별도의 대시보드를 만들 수 있지만 간단한 Ad-hoc UI 제작 가능함.
- 서비스 장애 / 비가동 상황 시 빠른 파악과 알림 구성이 쉬움.
- 수많은 Metrics를 직접 보지 않아도 되므로 트래픽/오버헤드 감소
- Pull 방식이 불가능한 경우 Pushgateway로 Push 방식 수집 가능
- 하나의 장소에 여러 가지 Metrics 데이터 수집 가능
- 단점
- billing 데이터와 같은 정확한 데이터로 활용하는 것은 적합하지 않음.
- 장애 상황에 새로운 데이터를 수집하지 못했을 경우를 고려하기 힘듦.
- 시계열 데이터가 아닌 경우, 즉 일반적인 log나 index가 필요한 데이터의 경우 적합하지 않음.
- billing 데이터와 같은 정확한 데이터로 활용하는 것은 적합하지 않음.
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
- 독립적으로 구성된 Datasource마다 별도의 Query Editor를 제공하며, Grafana Core에서 제공하지 않는 Datasource들은 Plugin으로 추가 가능
- Query Editor
- 여러 가지 중첩된 Query(Compound Query)를 수행할 수 있으며 Datasource별로 특정 기능을 수행할 수 있도록 관련 기능을 탑재함.
- Query 내에 다양한 템플릿 변수 등을 통해 동적으로 데이터 탐색 가능 (PromQL의 한계 보완)
- 여러 가지 중첩된 Query(Compound Query)를 수행할 수 있으며 Datasource별로 특정 기능을 수행할 수 있도록 관련 기능을 탑재함.
- Panels
- Query 결과를 시각화하며 Plugin으로 확장 제공한다. graph, singlestat, alert list, heatmap, table 등의 여러 형태를 시각화할 수 있다.
- Rows
- 여러 Panel을 포함하는 논리적인 개념으로, collapse / uncollapse 기능이 있음.
- Dashboard
- Panel과 Row로 구성되며, 정해진 시간을 설정하여 Naming과 Tagging, 그리고 Sharing이 가능한 Dashboard를 생성할 수 있음.
반응형
'Data Engineering' 카테고리의 다른 글
[ELK] Elasticsearch 검색 Query 종류 (추천/비추천 패턴) (0) | 2023.06.03 |
---|---|
[ELK] Elasticsearch 클러스터 트러블 슈팅 및 모니터링 (2) | 2023.05.05 |
[ELK] Container 환경의 Elasticsearch에 대해 알아두면 좋은 것들 (0) | 2023.04.08 |
댓글