[ Monitoring ] 인프라 모니터링 파이프라인 설계하기 #2

 

지난 글에서, 모니터링을 하는 방식에는 2가지가 존재한다고 했었습니다.

모니터링 방식에는 2가지 방식이 존재합니다
가져오거나(pull-based monitoring system) 받거나(push-based monitoring system)

 

이를 기억하고, 인프라 모니터링 도구인 프로메테우스 먼저 공부해보겠습니다.

프로메테우스

Prometheus는 대상(Target)으로부터 메트릭 값을 받아오는 모니터링 시스템

즉, Pull-based monitoring system입니다.

Pull 기반은 Target에 직접적으로 접근하여 데이터를 Scraping 하며 그 대상이 되는 Target은 데이터를 노출 시킬 방법이 필요하며 Prometheus는 이러한 니즈에 대해 생태계가 잘 구축되어있습니다.

• CNCF 오픈소스 모니터링 솔루션
• Target Metric을 pull 방식으로 수집
• Custom Format을 통한 효율적인 데이터 식별
• PromQL(Prometheus Query Language)을 사용하여 시계열 데이터를 실시간으로 선택하고 집계

⇒ 사용하는 가장 큰 이유는 “다양하고 직접 개발이 가능한 Exporter” 와 “Kubernetes 환경의 모니터링” 이 가능합니다.

 

 

프로메테우스는 서비스 디스커버리 기능을 내장하고 있어 프로메테우스 서버가 동적으로 타깃 서비스를 찾고 모니터링 할수 있습니다.

서비스 디스커버리 : 서비스 간 통신과 검색을 단순화하고 자동화하는 기술 또는 접근 방식을 나타냅니다. 애플리케이션의 확장성, 안정성, 유지 보수성을 개선하는데 도움이 됩니다. 

 

동작 순서

1. 프로메테우스 서버는 컨피그맵에 기록된 내용을 바탕으로 대상을 읽어옵니다.
2. 읽어온 대상에 대한 메트릭을 가져오기 위해 API 서버에 정보를 요청합니다.
3. 요청을 통해 알아온 경로로 메트릭 데이터를 수집합니다.

단점

프로메테우스는 앞서 명시된 것 처럼 값을 읽어오는데에는 탁월하나, '저장' 방식에서 일부 단점을 지니고있습니다.

https://owin2828.github.io/devlog/2020/03/13/etc-5.html

• 위의 그림처럼, 각 Region에 프로메테우스를 배치 한 뒤, 이를 Master에 Aggregate하는 방식이 프로메테우스가 공식적으로 권장하는 다중화 방식즉 Clustering과는 거리가 멉니다.
• 싱글 호스트 아키텍처이기 때문에 저장용량이 부족하면 디스크 용량을 늘리는 것 밖에 방법이 없습니다.
• 프로메테우스 서버가 다운되거나, 설정 변경 등을 위해서 재시작을 할 경우 그간의 metric은 유실됩니다.
• 일정 풀링 주기를 기반으로 metric을 가져오기 때문에 풀링하는 순간의 스냅샷 정보만 알 수 있습니다.
  • 스냅샷의 연속된 모음이기 때문에 근사값의 형태를 띕니다.

DB 다중화라 함은 보통 Replicas 간에 Discovery를 수행한 뒤, 데이터 샤딩, 장애 시 HA, 데이터 Loss 방지 및 서비스 무중단을 보장하는 것을 의미합니다. 그러나 프로메테우스는 클러스터링 개념과는 조금 거리가 있는데, 프로메테우스의 다중화는 Chunk 단위의 샤딩을 제공하는 구조가 아니기 때문입니다.

 

이게 무슨 뜻이냐면, 위처럼 여러 개의 프로메테우스를 각 Region마다 배치한 뒤 이를 Master에서 Aggregate 하는 Federation 방식이 프로메테우스 측에서 공식적으로 권장하는 다중화 방식이기 때문입니다. 이러한 Federation 구조는 Downsampling과 같은 작업을 수행해 별도로 저장하는 용도로는 적합할지는 모르겠지만, 적어도 클러스터링과는 거리가 있어 보입니다.

( 자세한 설명은 여기를 참고하세요.)

또한 프로메테우스는 대략적인 Metrics 추세를 파악하기에는 좋을 수도 있지만, APM에서 필요한 모든 지표를 추적해 세밀한 조정을 하기에는 적합하지 않을 수도 있음을 알아 두어야 합니다.

출처

 

---

프로메테우스에 대해 간단히 알아보았습니다.

그렇다면 이 프로메테우스를 이용해서 어떻게 인프라 모니터링이 가능할까요?

 

모니터링을 위해서는 특정 서비스/인프라의 데이터를 수집, 저장, 전송, 시각화를 해줘야 합니다.

이 일련의 과정을 한번 탐색해봅시다.

 

데이터 수집

프로메테우스 공식 문서

먼저 데이터를 수집하기 전에 어떠한 데이터를 가져올 것인지 알아야 합니다.

1. 프로메테우스 서버를 이루는 요소 중 하나인 Retrieval에서 Service discovery에 정의되어 있는 Target을 식별합니다.
2. Service discovery는 Target을 yaml 형태로 정의한 파일로 저장되어 있으며,
   메트릭을 수집할 대상을 동적으로 설정하는 것을 가능하게 해주고,
   이를 통해 Auto-Scale 되는 Virtual Machine EC2 Instance 그리고 Kubernetes Cluster로부터 메트릭 수집을 가능하게끔 도와줍니다.
3. Target이 정의되면 Retrieval에서 Target에 존재하는 Exporter를 통해 메트릭을 스크래핑 합니다.

exporter ?

시스템의 정보를 수집하고 HTTP endpoint로 메트릭을 노출시켜주는 기능을 가지고 있습니다.

exporter는 설치형 에이전트이며 누군가 개발한 export를 설치하거나 자신이 개발하여 사용할 수 있습니다. AWS RDS, ELB같은 Cloud Provider 관리형 서비스에는 설치가 불가능합니다.

아래는 exporter가 어떻게 HTTP 엔드포인트로 노출되고 메트릭을 노출시키는지 보여주는 캡처입니다.

 

 

Pushgateway

는 exporter로 부터 스크리핑한 데이터를 push받아주는 서버입니다.

역할은 임시 및 배치작업 즉, 수명이 짧은 서비스에 대한 메트릭을 가져오기위해 사용 합니다.

Prometheus는 Exporter를 통해 다양한 서비스와 시스템에 대한 메트릭을 수집할 수 있도록 생태계가 구성되어있습니다.

프로메테우스의 아키텍쳐에서 가장 눈여겨 봐야할 것은 서버가 exporter의 데이터를 pull 해간다는 것입니다. Exporter는 단지 /metrics 엔드포인트를 가진 http 서버일 뿐입니다. 이 구조로 프로메테우스 서버는 트래픽에 대한 고려없이 많은 대상을 모니터링할 수 있게 됩니다. 프로메테우스 서버가 수집한 데이터는 TSDB에 저장되며 promql을 사용해 쿼리를 보낼 수 있습니다.

 

 

데이터 저장

프로메테우스 서버는 메트릭 수집, 메트릭 저장, 알림전송, 데이터 노출 등 모니터링 서비스의 대부분을 차지하고 있습니다.

• Retrieval
  • Retrieval은 앞서 언급한 데이터 수집을 총괄하는 역할을 합니다.
• Storage
  • Storage는 Local Storage(default)와 Remote Storage를 사용가능
  • TSDB (Time Series Database)형식을 따릅니다.
  • TSDB(시계열 데이터베이스)란 일정한 시간 동안 수집된 일련의 순차적으로 정해진 데이터 셋의 집합이라고 알고 계시면 될 것 같습니다.
  • 모니터링 시스템에는 시간별로 데이터를 구분해야하는데 이는 그래프에 사용되거나 쿼리문을 통한 데이터 분석시 필요하기에 TSDB를 사용하게됩니다.
• HTTP server
  • HTTP server에서는 프로메테우스 서버가 가지고있는 메트릭을 다른 시각화 또는 데이터 활용을위해
    HTTP API로 메이터를 수집, 추가, 삭제를 하기위하여 존재합니다.

프로메테우스는 꽤 오래된 프로젝트라 조금 아쉬운 면이 몇 개 있습니다.
그 중 하나는 데이터 저장방식인데요. 특히 쿠버네티스 위에서 사용할땐 여러가지 방법으로 세팅할 수 있습니다. 프로메테우스는 기본적으로 메모리 혹은 프로세스가 떠 있는 노드의 디스크에 데이터를 저장합니다. 하지만 데이터를 무한정 저장할 수는 없으니, 특정 용량이나 특정 기간까지의 데이터만 저장하고 오래된 데이터는 삭제하는 방식을 사용하고 있습니다.

먼저 쿠버네티스 환경에서 메모리에 데이터를 저장하는 방식은 굳이 보지 않아도 안좋은 방법입니다. 파드가 어떤 이유로 재실행되면 그동안의 데이터가 모두 날라갈 뿐더러 많은 양의 데이터를 저장하기도 힘듭니다. 또한 노드의 디스크를 쓰는 방식 역시 좋지 않습니다. 파드는 재실행될 수 있지만, 항상 같은 노드에서만 스케줄링이 되어야 합니다. 만약 노드에 문제가 생기면 역시나 그동안의 데이터를 다 날려버리는거죠.

결국 데이터를 어떻게 안전하게 관리하느냐가 쟁점인데요. 온프레미스 환경에서 데이터를 비교적 안전하게 관리하려면 Longhorn 과 같은 블록 스토리지를 사용할 수도 있고 클라우드를 사용할 수 있다면 EBS와 같은 클라우드 서비스가 제공하는 블록 스토리지를 사용할 수도 있습니다. 그런데 이 두 방법으로도 해결하지 못하는 문제는 데이터 저장 용량에 한계가 있다는겁니다. 큰 디스크를 설치하거나 클라우드에 큰 스토리지를 요청해 받을 수도 있지만, 어쨋든 용량은 한정되어 있고 큰 용량을 사용하면 처음부터 괜히 비용만 많이 쓰게 됩니다.

 

또 다른 큰 문제는 확장성입니다. 만약 모니터링해야하는 타겟들이 많아지고 프로메테우스에 들어가는 쿼리들도 많아지면 프로메테우스 서버는 부하가 걸리게 됩니다. 아쉽게도 프로메테우스는 왜인지는 모르겠지만, 확장성에 취약하게 만들어졌습니다. (아마 10년전에 만들어져서?) 그런데 하나의 프로메테우스로는 모자라 두개의 프로메테우스가 필요하다면 어떻게 될까요.

두개의 프로메테우스 서버는 쿼리를 처리하는 일은 반으로 줄겠지만, 메트릭은 중복으로 수집하게 됩니다. db에 똑같은 데이터가 두개씩 쌓이죠. 각각의 서버가 서로 겹치지 않는 메트릭을 수집하게 해야합니다. 쿠버네티스 환경에서 자동으로 오토스케일링되며 타겟도 알아서 나누기란 쉽지 않아보입니다.

이런 프로메테우스를 현대 소프트웨어 환경에서도 잘 쓸 수 있도록 한 것이 타노스 입니다. 고가용성과 장기간 데이터 보존이 가능한 프로메테우스 셋업이라고 홍보하고 있죠. 타노스 역시 CNCF 프로젝트에 들어가게 되었는데 왜 프로메테우스를 개선해 2.0으로 만들지 않고 타노스가 나왔는지는 모르겠네요.

타노스는 프로메테우스의 기능을 쪼개서 쿼리 처리, 메트릭 수집, 데이터 저장 하는 컴포넌트를 분리하고 데이터는 오브젝트 스토리지에 저장하게 해 효율적인 비용으로 데이터를 장기간 쌓을 수 있도록 했습니다. 타노스에 대한 자세한 소개는 다음 포스트에서 하는 것으로 하고 여기서는 타노스가 프로메테우스를 쿠버네티스 환경에서 사용하기 아주 좋게 만들었다. 정도로만 소개하겠습니다.

 

(출처:https://juhyungson.com/blog/-3)

 

타노스를 활용한 아키텍처의 예시)

https://jominseoo.tistory.com/77

 

프로메테우스의 HA 구성 ?

대규모 모니터링 환경에서의 프로메테우스 사용 시 고려사항은 3가지 입니다.

• 디스크 부하
• 가용성
• 데이터 처리량(PromQL 호출) 부하

가용성과 데이터 처리는 Prometheus Federation 기능을 사용하여 어느정도 해소할 수 있습니다.

각각의 프로메테우스 서버가 타겟으로부터 메트릭을 가져오면 상단에 위치한 프로메테우스 서버가 데이터를 바라보게됩니다.최상단의 프로메테우스는 자기가 메트릭을 가지고있는 것처럼 보여집니다.

 

이런 구성을 한다면 타겟으로부터 데이터를 수집하는 프로메테우스 서버가 다운이 되어도 다른 서버에서 메트릭을 수집하기 때문에 데이터 수집 및 저장 단계에서 발생하는 장애포인트를 예방할 수 있습니다.

 

Prometheus Federation을 사용하다가 부하량이 감당이 안되면 Thanos나 Cortex같은 솔루션을 사용하여 대규모 분산 및 집계 중앙화 등 많은 방법을 통해 해소할 수 있습니다.

 

출1, 출2

 

Thanos 사용

프로메테우스 - 타노스(or cortex) 쓰기 (출처)

 

데이터 시각화 , 알림

시각화 툴 1. Grafana

Grafana는 모니터링 등 다양한 지표를 시각화 하는 대시보드 기능에 최적화된 제품입니다.

• 오픈소스 데이터 시각화 솔루션입니다.
• DB를 비롯한 다양한 데이터 소스를 그래프, 차트, 테이블 형식으로 지표 생성
• 리소스 접근 제어 설정가능
• 데이터 소스에대한 암호화 지원
• 다양한 플러그인 지원

Prometheus-Grafana 조합이 많은데 다른 조합 역시 많이 사용합니다.

push 기반 모니터링 서비스는 InfluexDB-Grafana, InfluxDB-Telegraf 조합을 많이 사용합니다.

 

알림

메트릭 값에 대한 임계치를 PromQL로 설정할 수 있습니다.

Prometheus Alert 예시 ) 

 

• 서버가 다운되었다.
• CPU 사용률이 80% 이상이다.

이런 임계값에대해 조건이 부합하면 알림을 보낼 수 있도록 설정할 수 있습니다.

이런 알림 처리는 Alertmanager에서 처리하게 됩니다.

 

alertmanager

Alertmanager 서비스는 Prometheus에서 수신한 경고를 처리합니다. 또한 Alertmanager는 경고를 외부 알림 시스템으로 전송해야 합니다.

이쯤에서 다시보는 아키텍처

 

데이터 로깅

데이터 로깅쪽은 다음 글에서 보완할 예정입니다.

이번 게시글에서는 예시 아키텍처, 많이 쓰이는 기술들을 gpt 로 비교해본 것들을 가져와봤습니다.

 

 

https://sdefinitive.net/antrea-observability-part-2-installing-grafana-prometheus-loki-and-fluent-bit/

 

https://medium.com/@muppedaanvesh/a-hands-on-guide-to-kubernetes-monitoring-metrics-and-logging-with-grafana-loki-️-010c12f0ffb6

 

https://www.persistent.com/blogs/log-aggregation-using-grafana-loki-stack/

 

https://medium.com/@muppedaanvesh/a-hands-on-guide-to-kubernetes-monitoring-metrics-and-logging-with-grafana-loki-️-010c12f0ffb6

 

https://picluster.ricsanfre.com/docs/logging/

https://www.justinpolidori.it/posts/20211121_logging_kubernetes/

 

보다보니 비슷한 기술들이 사용되는것 같아, GPT 에게 차이점을 물어보았습니다. (어떤 조합이 좋을 지)

 

gpt 의 두개 비교 답변

( promtail + loki + grafana ) vs ( fluentbit,fluentd+loki+grafana)

 

1. Promtail + Loki + Grafana 조합 (온프레미스 환경)

• Promtail은 주로 Kubernetes 환경에 최적화되어 있지만, 온프레미스 환경에서도 파일 시스템 로그를 수집하는 데 사용할 수 있습니다. 예를 들어, 서버에서 /var/log 디렉토리 내 로그 파일을 Promtail이 수집하여 Loki로 전송할 수 있습니다.
• 온프레미스 환경에서는 서비스 디스커버리가 Kubernetes처럼 자동으로 이루어지지 않기 때문에, Promtail을 수동으로 설정해야 합니다. 예를 들어, 로그 파일 경로와 라벨링 규칙을 명시적으로 설정해야 합니다.
• Loki는 로그 저장 및 색인화 최소화를 통해 저장 공간 절약과 빠른 검색을 가능하게 해줍니다.
• Grafana는 Loki에 저장된 로그 데이터를 시각화할 수 있습니다. 이 조합은 간단하고 직관적이며, 온프레미스 환경에서 서버 로그를 시각화하는 데 유용합니다.

장점:

• 구성 간단: 로그 파일 경로만 설정하고 Promtail을 적절히 설정하면 되므로 초기 설정이 간단합니다.
• Kubernetes 외의 환경에서도 사용 가능: 수동으로 설정하면 온프레미스 환경에서도 잘 작동합니다.
• 저장소와 시각화의 일관성: Grafana와의 통합으로 실시간 대시보드 구성이 쉽습니다.

단점:

• 서비스 디스커버리 부족: Kubernetes와 달리 온프레미스 환경에서는 자동으로 서버나 노드를 인식할 수 없으므로 수동으로 설정해야 합니다.
• 로그 변환 및 처리 기능 제한: 기본적으로 로그를 수집하고 전송하는 데 중점을 두고 있어, 복잡한 로그 처리나 변환에는 제한이 있을 수 있습니다.

---

2. Fluent Bit + Fluentd + Loki + Grafana 조합 (온프레미스 환경)

• Fluent Bit와 Fluentd는 온프레미스 환경에서 로그 수집 및 처리에 매우 유용한 도구입니다. Fluent Bit는 경량화된 수집기로, 서버에서 발생하는 로그를 수집하여 Fluentd나 Loki로 전송할 수 있습니다.
• Fluentd는 로그의 필터링, 변환, 집합적 처리에 강력한 기능을 제공하며, 온프레미스 환경에서도 로그를 수집하고 처리하는 데 매우 유용합니다. 예를 들어, 로그 데이터의 형식 변환, 마스킹, 필터링 등을 Fluentd를 통해 처리할 수 있습니다.
• Loki는 Fluentd로부터 전송된 로그 데이터를 효율적으로 저장하고, Grafana와의 통합을 통해 시각화할 수 있습니다.

장점:

• 고급 로그 처리 가능: Fluentd는 로그를 변환, 필터링, 형식 변경 등을 할 수 있기 때문에, 복잡한 로그 파이프라인을 처리하는 데 매우 유용합니다.
• 대규모 환경에서 유연성: 여러 서버에서 발생하는 로그를 집합적으로 처리하고, 다양한 소스에서 수집된 로그를 중앙 집중적으로 처리할 수 있습니다.
• 확장성: 대규모 온프레미스 환경에서 다양한 로그 수집, 처리, 변환 요구 사항을 지원합니다.
• 다양한 출력 지원: Fluentd는 여러 출력 플러그인을 통해 로그를 다양한 시스템으로 보낼 수 있기 때문에, 여러 시스템과의 통합에 유리합니다.

단점:

• 설정 복잡성: Fluent Bit과 Fluentd는 설정이 더 복잡하고, 유지보수가 어려울 수 있습니다. 많은 플러그인과 옵션을 관리해야 하므로, 작은 환경에서는 과할 수 있습니다.
• 리소스 사용량: Fluentd는 상대적으로 리소스를 더 많이 소비할 수 있습니다. 특히 고용량의 로그를 처리할 때 리소스 관리가 중요합니다.

---

온프레미스 환경에서의 선택 기준

• 온프레미스 환경에서 서버 로그, 시스템 로그(CPU, 메모리 등)를 단순히 수집하고 시각화하려는 경우, Promtail + Loki + Grafana 조합이 더 적합합니다. 설정이 간단하고, 로그를 빠르게 수집하고 시각화할 수 있습니다. 이 경우, 로그 처리나 변환이 복잡하지 않다면 Promtail을 사용하는 것이 더 효율적입니다.

2. 복잡한 로그 처리, 변환 및 확장성

• Fluent Bit + Fluentd + Loki + Grafana 조합은 복잡한 로그 처리가 필요한 경우에 유리합니다. 예를 들어, 로그 포맷 변경, 로그 집합 처리, 외부 시스템으로의 로그 전송 등이 필요한 경우, Fluentd를 사용하면 유연하고 강력하게 로그 파이프라인을 관리할 수 있습니다. 또한, 대규모 시스템에서 여러 로그 소스를 수집하고 처리할 때도 확장성과 유연성을 제공합니다.

결론:

• 간단한 로깅 및 시각화를 원한다면 Promtail + Loki + Grafana 조합이 적합합니다. 이 조합은 설정이 간단하고 온프레미스 환경에서도 효과적으로 작동할 수 있습니다.
• 복잡한 로그 처리 및 대규모 환경을 위한 확장성 있는 시스템을 원한다면 Fluent Bit + Fluentd + Loki + Grafana 조합이 적합합니다.

 

https://peterica.tistory.com/221

 

FluentD 와 Fluent Bit 의 조합

 

https://somaz.tistory.com/292

 

 

음.. 이어질 글 들에서는 로그 수집, 시각화, 최종 아키텍처 등을 게시해볼 예정입니다.

더 명확하게 알아보며 작성하겠습니다.