일반적으로 kubernetes 클러스터 pod의 Metric을 모니터링하기 위해 Prometheus를 구축을 하게된다.운영되는 서비스와 범위가 확장됨에 따라 Prometheus가 모니터링할 대상의 갯수도 증가하게 되는데, 이에 따라 Prometheus에 가해지는 부하가 증가하게 될 것이다. 이러한 Prometheus의 몇 가지 한계점은 아래와 같이 정리될 수 있다.문제점내용확장성 제한기본적으로 Prometheus는 단일 서버 구성을 전제로 설계되어있어 수평적 확장에 어려움이 존재한다.SPoF(Single Point of Failure) 문제Prometheus를 단일 서버로 운영하게 되는 경우, 해당 노드에 장애가 발생하면 Metric 수집이 불가해 모니터링이 불가능하다.HA(High Availabilit..
Prometheus
Prometheus 공식 문서에 따르면 Prometheus에서 Alert는 크게 2가지 컴포넌트로 구성되어있다.Alert Rule : PromQL을 기반으로 정의하는 알람이 발생할 규칙AlertManager : 수신받은 Alert를 다양한 서비스에 notify를 수행오늘은 Prometheus의 Alert 아키텍쳐를 알아보도록 한다. Alerting RulePrometheus 쿼리문(PromQL)을 바탕으로 정의하는 알람 조건, 조건에 맞아 알람이 발생하면 연결된 외부 서비스로 알람을 전달하게 된다.Prometheus에서 Alert Rule을 선언하는 방법으로 Prometheus 웹 GUI 상에서 선언해주는 방법과 설정파일을 작성하는 방법이 존재한다.groups:- name: example rules: ..
Helm kubernetes의 패키지 매니저, 배포하는 환경에 따라 설정값을 따로 정의해서 배포할 수 있도록 패키지 매니저 역할을 한다. Helm에서 패키지는 ‘Chart’라고 하며, chart는 kubernetes 애플리케이션의 리소스 정의로 이루어진다. Helm을 통해 Chart를 설치하는 과정은 Chart가 정의된 helm repo를 추가하고, 해당 repo를 통해 install한다. Helm 아키텍쳐 Helm 아키텍쳐의 구성요소에는 쿠버네티스 클러스터, Helm 클라이언트, Helm Chart Repository가 있다. Helm 클라이언트가 Chart Repository로부터 Chart를 다운로드받고, 이 Chart를 기반으로 쿠버네티스 클러스터의 API 서버와 통신해 Chart를 적용하게 된다..
이번에는 EC2 인스턴스의 Metric을 Prometheus로 수집하고, Grafana까지 연동까지 진행해보도록한다. Prometheus와 Grafana가 연동된 아키텍쳐 구조를 먼저 보도록한다. 각 노드들의 node-exporter로 부터 Prometheus 서버가 metric을 Pull해오고, Grafana가 Prometheus 서버에 PromQL을 날려 쿼리 결과를 가져와 Dashboard 형태로 보기좋게 구성을 해주게 된다. Prometheus 설치수집한 Metric 데이터를 모을 인스턴스에 Prometheus를 설치한다.공식 페이지에서 Prometheus 설치는 바이너리 / 소스 / Docker 이미지 형태로 제공한다.이 글에서는 Docker 이미지를 받아 컨테이너 방식으로 설치하도록 한다. ..
서버나 서비스 등의 운영에 있어서 모니터링은 필수 요소이다.개발 Language 못지않게 모니터링 툴/시스템들도 굉장히 다양한 종류가 존재하고 새롭게 생겨나고 있다. 나는 기존에는 Cloudwatch Agent나 Logstash + Datadog 등을 이용해서 서버나 서비스에서 발생하는 데이터들을 모니터링하도록 구성했었다. 다만, Datadog의 요금정책 등의 이슈들로 인해 다른 모니터링 도구 탐색을 하게 되었다.그렇게 최근들어 알게된 Prometheus를 적용하고 깊게 공부해보고자 해서, 이 시리즈를 작성하기로 했다. 이번에는 Prometheus의 기본 개념과 특징을 알아보도록한다. PrometheusMetric 수집 모니터링 오픈소스 프로젝트, SoundCloud사에서 개발했으며 CNCF 소속 프로젝..