Prometheus를 사용한 GKE용 화이트박스 앱 모니터링

이 문서에서는 PrometheusCloud Monitoring을 사용하여 다수의 Google Kubernetes Engine(GKE) 네임스페이스, 클러스터, Google Cloud 프로젝트의 크고 복잡한 앱에서 화이트박스 모니터링을 수행하는 방법을 설명합니다.

대규모 프로덕션을 많은 마이크로서비스와 함께 운영하기란 어려운 일입니다. 이 문제를 해결하기 위해 사이트 안정성 엔지니어(SRE)는 다양한 세부 수준으로 여러 소스의 데이터를 사용합니다. 이 데이터를 사용하면 서비스를 개선하여 보다 나은 사용자 환경을 제공할 수 있습니다. 이 데이터를 사용하여 서비스에서 발생할 수 있는 문제(예: 코드 배포 디버깅)를 진단할 수도 있습니다. GKE가 마이크로서비스 아키텍처를 배포하는 데 도움이 될 수 있지만 마이크로서비스를 효율적이고 안정적으로 운영하려면 확장 가능한 동적 모니터링 시스템이 필요합니다.

GKE용 클라우드 작업을 통해 동일한 도구를 사용하여 블랙박스 및 화이트박스 모니터링을 모두 수행할 수 있습니다. 앱의 화이트박스 모니터링을 수행하려면 현재 메모리 사용 정보나 요청 지연 시간과 같은 앱 내부의 측정항목 및 신호를 사용하여 문제를 감지하고 예측하는 과정이 필요합니다. 블랙박스 모니터링은 페이지 로드 시간과 같이 외부에서 확인할 수 있는 동작을 신호로 사용합니다.

State of DevOps 보고서에는 소프트웨어 제공 성능을 향상시키는 기능이 나와 있습니다. 이 문서에서는 다음 기능을 설명합니다.

Prometheus

Prometheus는 Google 내부 모니터링 시스템인 Borgmon을 토대로 하는 오픈소스 모니터링 및 알림 도구입니다. Borg는 Kubernetes 오픈소스 프로젝트에 영향을 주었고 Borgmon은 Prometheus에 영향을 주었습니다. 이 도구들은 서로 잘 연동됩니다.

Prometheus를 사용하면 구성 가능한 간격으로 쿼리(또는 스크레이핑)되는 스크레이핑 대상을 구성하여 여러 머신에서 측정항목을 검색하고 가져올 수 있습니다. 스크레이핑 대상은 일반적으로 앱에서 노출된 HTTP 엔드포인트이며 측정항목이 줄마다 하나씩 있는 잘 정의된 노출 형식을 사용합니다. HTTP를 스크레이핑 대상의 기본 전송 메커니즘으로 사용하면 다양한 언어 및 엔드포인트의 측정항목을 노출할 수 있습니다.

널리 사용되는 프로그래밍 언어용 클라이언트 라이브러리를 사용할 수 있으므로 측정항목 엔드포인트를 기존 앱에 빠르게 추가할 수 있습니다. Istioetcd와 같은 다양한 클라우드 기반 도구는 Prometheus 측정항목을 노출합니다. 또한 Consul, MySQL, Redis와 같이 널리 사용되는 앱 및 프레임워크에 대한 Prometheus 측정항목을 노출하는 다양한 Prometheus 내보내기 도구가 있습니다.

스크레이핑 대상에서 수집된 측정항목은 다음 아키텍처 다이어그램에서 Prometheus의 시계열 데이터베이스에 저장됩니다.

시계열 데이터베이스에 측정항목 저장

이 데이터베이스는 대규모 시스템에서 흔히 발생하는 카디널리티 및 처리량이 많은 측정항목 사용 사례에 최적화되었습니다. 측정항목이 저장되면 다양한 쿼리 언어를 사용하여 사용자에게 편리한 형식으로 측정항목을 조작할 수 있습니다. 언어 구문을 사용하면 기본 연산자더 복잡한 함수를 기본 방식으로 사용할 수 있습니다.

Prometheus로 GKE 모니터링

GKE에서 앱은 Pod라고 하는 컨테이너 그룹에 배포됩니다. 각 pod는 여러 포트를 노출할 수 있으며 Kubernetes 서비스를 통해 부하 분산을 처리하기 위해 pod를 그룹화할 수 있습니다.

앱에서 Prometheus 호환 라이브러리를 사용하는 경우 라이브러리는 추가 포트 및 엔드포인트(기본적으로 9090/metrics)를 노출합니다. Kubernetes SD 스크레이핑 구성을 설정하여 Prometheus가 GKE에서 앱을 자동으로 감지하도록 구성할 수 있습니다. 이 구성을 사용하면 Prometheus가 Kubernetes API를 쿼리하여 추가 구성 없이 새로운 스크레이핑 대상을 검색할 수 있습니다. 하지만 여러 스크레이핑 대상 검색 메커니즘을 구성할 수도 있습니다.

  • Pod: 각 Pod의 대상입니다.
  • 서비스: 각 서비스 IP 및 포트 조합의 대상입니다.
  • 엔드포인트: 각 엔드포인트 리소스의 대상입니다.
  • 노드: 각 GKE 노드의 대상입니다.
  • 인그레스: 인그레스 사양에 포함된 각 호스트의 대상입니다.

Prometheus가 대상을 발견하면 이 대상을 스크레이핑하여 원시 측정항목 데이터를 가져옵니다. Prometheus는 데이터를 저장하기 전에 GKE API에서 수신한 정보를 바탕으로 측정항목에 라벨을 추가합니다. 예를 들어 Prometheus는 pod가 실행되는 네임스페이스를 저장하는 라벨, pod의 이름, pod에 추가한 라벨을 추가하여 pod에서 스크레이핑한 측정항목을 보강할 수 있습니다.

GKE 클러스터 정보로 Prometheus를 구성한 후에는 Prometheus가 서비스, Pod 또는 인그레스를 스크레이핑할 수 있도록 Kubernetes 리소스 정의에 주석을 추가해야 합니다. 서비스에 이 주석이 있으면 Prometheus가 스크레이핑 대상(엔드포인트, pod)을 검색할 수 있습니다. 일반적으로 prometheus.io/scrape: "true"가 사용되지만 다른 키도 구성할 수 있습니다.

예를 들어 다음은 기본 포트(9090)를 스크레이핑하는 서비스이지만 커스텀 경로(/stats)를 스크레이핑합니다.

apiVersion: v1
kind: Service
metadata:
 annotations:
   prometheus.io/scrape: 'true'
   prometheus.io/path: '/stats'
 labels:
   app: demo
 name: demo
spec:
 ports:
 - port: 8080
   protocol: TCP
   targetPort: 8080
 - port: 9090
   protocol: TCP
   targetPort: 9090
 selector:
   app: demo

GKE를 스크레이핑하도록 구성된 Prometheus의 다른 예시를 참조하세요.

다음 다이어그램에서는 Prometheus가 Pod와 서비스를 모두 스크레이핑하도록 구성되어 있습니다.

Pod 및 서비스를 스크레이핑하도록 구성된 Prometheus

OpenCensus를 사용하여 앱 계측

앞에서 설명한 것처럼 Prometheus를 사용하여 앱을 모니터링하려면 앱이 HTTP 엔드포인트의 데이터를 올바른 형식으로 노출해야 합니다. Prometheus 도우미 라이브러리를 사용하면 이러한 엔드포인트를 효율적이고 관용적으로 추가할 수 있습니다.

OpenCensus는 측정항목과 trace를 앱에서 내보내는 데 사용할 수 있는 라이브러리 세트로, 공급업체와 상관없이 사용할 수 있습니다. OpenCensus는 자바, Go, Node.js, Python의 라이브러리를 제공하므로 사용자는 앱을 계측하여 Prometheus를 비롯한 다양한 백엔드로 측정항목과 trace를 제공할 수 있습니다. OpenCensus로 앱을 계측하면 zPages를 노출하여 사용된 내보내기와 상관없이 서버에서 직접 서버 프로세스에 대한 측정항목을 한눈에 확인할 수 있습니다. zPages는 개발 또는 프로덕션 중 문제가 발생한 경우 특정 프로세스를 분석하는 데 유용합니다.

측정항목 노출에만 집중하려는 경우 Prometheus 클라이언트 라이브러리의 기능을 사용하면 됩니다.

GKE용 클라우드 작업을 Prometheus와 결합

Prometheus 서버를 클러스터에 배포하려면 Prometheus가 지원되는 GKE용 클라우드 작업을 사용하면 됩니다. 이 서버는 Cloud Monitoring에 측정항목을 외부 측정항목의 형태로 전송합니다. 프로젝트에서 측정항목을 집계하는 Monitoring의 기능과 이 기능을 함께 사용하면 여러 클러스터와 프로젝트를 관리할 수 있습니다.

새 앱과 측정항목이 생성되면 Cloud Monitoring으로 자동 전달되고 데이터 보관 정책에 따라 보관됩니다. Monitoring의 기본 제공 기능을 사용하여 중앙에서 알림업타임 체크를 구성하면 모든 클러스터와 리전 전반에서 데이터를 연계하고 문제에 대한 알림을 받을 수 있습니다.

다음 아키텍처 다이어그램에서 Prometheus는 각 클러스터에서 실행되므로 사용자가 Cloud Monitoring에서 집계된 측정항목을 확인할 수 있습니다.

Cloud Monitoring에서 집계된 측정항목을 볼 수 있도록 각 클러스터에서 실행되는 Prometheus를 보여주는 아키텍처

기존 시스템 브리징

대부분의 고객은 실행 중인 시스템 관련 데이터를 저장하는 데 사용하고 있는 모니터링 시스템이 있을 것입니다. 앱 계측을 새 측정항목 형식 또는 시계열 데이터베이스로 이전하는 데 드는 비용은 계측 코드의 양과 앱 개수가 증가할수록 늘어납니다. Cloud Monitoring으로 마이그레이션할 때 복잡성을 줄이기 위해 Graphite 또는 StatsD와 같은 기타 모니터링 시스템용 Prometheus 내보내기를 사용할 수 있습니다. 그러면 이 내보내기를 사용하여 기존 시스템에서 Prometheus가 스크레이핑 후 Monitoring으로 보낼 수 있는 중간 내보내기 프로세스로 측정항목을 전송할 수 있습니다.

다음 다이어그램은 Compute Engine 인스턴스 세트에서 Prometheus를 통해 Monitoring으로 전송된 Graphite 측정항목의 예시를 보여줍니다.

Compute Engine 인스턴스 세트에서 Cloud Monitoring으로 전송된 Graphite 측정항목

다음 단계