9 컨테이너 모니터링 - Prometheus

자율화 앱은 입력되는 트래픽을 처리하기 위해 자체적으로 확장 및 축소되며 간헐적인 오류가 발생하면 스스로 복구합니다. 컨테이너 플랫폼은 상태 확인으로 이미지를 빌드하는 경우 많은 작업을 수행할 수 있지만 상황이 심각하게 잘못되었을 때 사람이 개입하도록 지속적인 모니터링 및 경고가 필요합니다.

모니터링은 앱이 수행하는 작업과 성능을 알려주고 문제의 원인을 정확히 찾아내는 데 도움이 됩니다. 이 장에서는 모니터링에 대한 잘 정립된 방법을 배웁니다. 이러한 도구는 앱과 함께 컨테이너에서 실행됩니다. 개발에서 프로덕션에 이르기까지 모든 환경에서 앱 성능에 대해 통찰력을 얻을 수 있습니다.

9.1 컨테이너 앱을 위한 모니터링 스택

앱이 컨테이너에서 실행되는 경우 모니터링이 다릅니다. 기존 환경에서는 서버 목록과 현재 사용률(디스크 공간, 메모리, CPU)을 표시하는 모니터링 대시보드와 과로되어 응답을 중지할 가능성이 있는 서버가 있는지 알려주는 경고가 있을 수 있습니다. 컨테이너화된 앱은 수명이 짧고 컨테이너 플랫폼에 의해 생성되거나 제거되는 수십 또는 수백 개의 컨테이너에서 실행될 수 있습니다.

검색을 위해 컨테이너 플랫폼에 연결할 수 있고 컨테이너 IP 주소의 정적 목록 없이 실행 중인 모든 앱을 찾을 수 있는 도구를 사용하여 컨테이너를 인식하는 모니터링 접근 방식이 필요합니다. Prometheus는 CNCF(Kubernetes 및 컨테이너식 컨테이너 런타임의 동일한 기반)에서 감독하는 성숙한 제품입니다. 컨테이너에서 실행되므로 앱에 모니터링 스택을 쉽게 추가할 수 있습니다. 그림 9.1은 스택이 어떻게 생겼는지 보여줍니다.

그림 9.1 컨테이너에서 Prometheus를 실행하여 다른 컨테이너와 도커 자체 모니터링

Prometheus는 모니터링에서 모든 앱에 대해 동일한 유형의 메트릭을 내보낼 수 있으므로 모니터링하는 표준 방법이 있습니다. 학습할 쿼리 언어는 하나뿐이며 전체 앱 스택에 적용할 수 있습니다.

또한 도커 엔진이 해당 형식으로 메트릭을 내보낼 수도 있기 때문에 컨테이너 플랫폼에서 일어나는 일에 대한 이해도 얻을 수 있습니다. 도커 엔진 구성에서 Prometheus 메트릭을 명시적으로 활성화해야 합니다. 구성을 업데이트하는 방법은 5장에서 확인했습니다. daemon.json 파일은 /etc/에서 직접 편집할 수 있습니다. 도커 Desktop에서 고래 아이콘을 마우스 오른쪽 버튼으로 클릭하고 설정을 선택한 다음 데몬 섹션에서 구성을 편집할 수 있습니다.

TRY 구성 설정을 열고 두 개의 새 값을 추가하십시오.

     "metrics-addr" : "0.0.0.0:9323",
     "experimental": true

이는 모니터링을 활성화하고 포트를 노출합니다.

그림 9.2 Prometheus 형식으로 메트릭을 내보내도록 도커 엔진 구성

도커 Engine 메트릭은 현재 실험적인 기능이므로 제공하는 세부 정보가 변경될 수 있습니다. 하지만 오랫동안 실험적인 기능이었고 안정적이었습니다. 시스템의 전반적인 상태에 또 다른 세부 사항을 추가하기 때문에 대시보드에 포함할 가치가 있습니다. 이제 메트릭을 활성화했으므로 http:// /localhost:9323/metrics로 이동하여 Docker가 제공하는 모든 정보를 볼 수 있습니다. 그림 9.3은 Docker가 실행 중인 머신과 Docker가 관리하는 컨테이너에 대한 정보를 포함하는 지표를 보여줍니다.

이 출력은 Prometheus 형식입니다. 각 메트릭이 이름과 값과 함께 표시되는 간단한 텍스트 기반 표현이며, 메트릭이 무엇인지와 데이터 유형을 설명하는 도움말 텍스트가 메트릭 앞에 옵니다. 이러한 기본 텍스트 줄은 컨테이너 모니터링 솔루션의 핵심입니다. 각 구성 요소는 현재 메트릭을 제공하는 이와 같은 끝점을 노출합니다. Prometheus는 데이터를 수집할 때 데이터에 타임스탬프를 추가하고 모든 이전 컬렉션과 함께 저장하므로 집계로 데이터를 쿼리하거나 시간 경과에 따른 변경 사항을 추적할 수 있습니다.

TRY 컨테이너에서 Prometheus를 실행하여 도커 시스템에서 메트릭을 읽을 수 있지만 먼저 시스템의 IP 주소를 가져와야 합니다. 컨테이너는 실행 중인 서버의 IP 주소를 모르기 때문에 먼저 찾아서 컨테이너에 환경 변수로 전달해야 합니다.

 # load your machine's IP address into a variable - Linux
 hostIP=$(ip route get 1 | awk '{print $NF;exit}')
      
 # and on Mac:
 hostIP=$(ifconfig en0 | grep -e 'inet\s' | awk '{print $2}')
      
 # pass your IP address as an environment variable for the container:
 docker container run -e DOCKER_HOST=$hostIP -d -p 9090:9090 diamol/prometheus:2.13.1

diamol/prometheus Prometheus 이미지의 구성은 DOCKER_ HOST IP 주소를 사용하여 호스트 시스템과 통신하고 도커 엔진에서 구성한 메트릭을 수집합니다. 컨테이너 내부에서 호스트의 서비스에 액세스해야 하는 경우는 드뭅니다. 그렇게 하는 경우 일반적으로 서버 이름을 사용하고 Docker는 IP 주소를 찾습니다. 작동하지 않을 수 있는 개발 환경에서는 IP 주소 접근 방식이 적합해야 합니다.

현재 Prometheus가 실행 중입니다. 도커 호스트에서 메트릭을 가져오기 위해 예약된 작업을 실행하고, 자체 데이터베이스의 타임스탬프와 함께 해당 메트릭 값을 저장하고, 메트릭을 탐색하는 데 사용할 수 있는 기본 웹 UI가 있습니다. Prometheus UI는 Docker의 /metrics 엔드포인트의 모든 정보를 표시하며, 메트릭을 필터링하여 테이블이나 그래프에 표시할 수 있습니다.

TRY http:// /localhost:9090으로 이동하면 Prometheus 웹 인터페이스가 표시됩니다. 상태 > 대상 메뉴 옵션으로 이동하여 Prometheus가 메트릭에 액세스할 수 있는지 확인할 수 있습니다. DOCKER_HOST 상태는 녹색이어야 합니다. 이는 Prometheus가 이를 찾았음을 의미합니다.

그런 다음 그래프 메뉴로 전환하면 Prometheus가 Docker에서 수집한 사용 가능한 모든 메트릭을 보여주는 드롭다운 목록이 표시됩니다. 그 중 하나는 서로 다른 컨테이너 작업에 소요된 시간에 대한 기록인 engine_daemon_container_actions_seconds_sum입니다. 해당 메트릭을 선택하고 Execute를 클릭하면 출력이 그림 9.4의 내 것과 유사하여 컨테이너를 생성, 삭제 및 시작하는 데 걸린 시간을 보여줍니다.

Prometheus UI는 무엇을 수집하고 있는지 확인하고 일부 쿼리를 실행하는 간단한 방법입니다. 메트릭을 살펴보면 Docker가 많은 정보 포인트를 기록한다는 것을 알 수 있습니다. 일부는 각 상태의 컨테이너 수 및 실패한 상태 확인 수와 같은 상위 수준 판독값입니다. 나머지는 도커 엔진이 할당한 메모리 양과 같은 낮은 수준의 세부 정보를 제공합니다. 일부는 Docker에서 사용할 수 있는 CPU 수와 같은 정적 정보입니다. 이는 인프라 수준 메트릭으로 상태 대시보드에 포함할 수 있는 모든 유용한 항목입니다.

앱은 자체 메트릭을 노출하고 다른 수준의 세부 정보도 기록합니다. 목표는 각 컨테이너에 메트릭 엔드포인트를 갖고 Prometheus가 정기적인 일정에 따라 모든 컨테이너에서 메트릭을 수집하도록 하는 것입니다. Prometheus는 전체 시스템의 전반적인 상태를 보여주는 대시보드를 구축하기에 충분한 정보를 저장합니다.

9.2 앱에서 메트릭 노출

도커 엔진이 노출하는 메트릭이 아니라 각 앱 컨테이너에서 필요한 메트릭 세트를 노출하려면 메트릭을 캡처하고 Prometheus가 호출할 HTTP 엔드포인트를 제공하는 코드가 필요합니다. 주요 프로그래밍 언어를 위한 Prometheus 클라이언트 라이브러리가 있기 때문에 생각보다 많은 작업이 필요하지 않습니다.

이 장의 코드에서 NASA의 image-gallery 앱을 다시 방문하여 각 구성 요소에 Prometheus 메트릭을 추가했습니다. Java 및 Go용 공식 Prometheus 클라이언트와 Node.js용 커뮤니티 클라이언트 라이브러리를 사용하고 있습니다. 그림 9.5는 각 앱 컨테이너가 메트릭을 수집하고 노출하는 Prometheus 클라이언트와 함께 패키징되는 방법을 보여줍니다.

그림 9.5 앱의 Prometheus 클라이언트 라이브러리는 측정용 엔드포인트를 컨테이너에서 사용할 수 있도록 합니다.

Prometheus 클라이언트 라이브러리에서 수집된 정보 포인트는 런타임 수준 메트릭입니다. 앱 런타임과 관련하여 컨테이너가 수행하는 작업과 작업 강도에 대한 주요 정보를 제공합니다. Go 앱의 메트릭에는 활성 goroutine 수가 포함됩니다. Java 앱에 대한 메트릭에는 JVM에서 사용되는 메모리가 포함됩니다. 각 런타임에는 고유한 메트릭이 있으며 클라이언트 라이브러리는 이를 수집하고 내보내는 작업을 훌륭하게 수행합니다.

TRY 이 장의 연습에는 각 컨테이너에 메트릭이 있는 새 버전의 이미지 갤러리 앱을 실행하는 Compose 파일이 있습니다. 앱을 사용한 다음 메트릭 엔드포인트 중 하나로 이동합니다.

 cd ./ch09/exercises
      
 # clear down existing containers:
 docker container rm -f $(docker container ls -aq)
      
 # create the nat network - if you've already created it
 # you'll get a warning which you can ignore:
 docker network create nat
      
 # start the project
 docker-compose up -d

browse to http://localhost:8010 to use the app then browse to http://localhost:8010/metrics

결과는 아래와 같은 Go 프론트엔드 앱으로부터의 메트릭입니다. 이 데이터를 만드는데 필요한 커스텀 코드는 없습니다.

# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 2.9167e-05
go_gc_duration_seconds{quantile="0.25"} 2.9167e-05
go_gc_duration_seconds{quantile="0.5"} 2.9167e-05
go_gc_duration_seconds{quantile="0.75"} 2.9167e-05
go_gc_duration_seconds{quantile="1"} 2.9167e-05
go_gc_duration_seconds_sum 2.9167e-05
go_gc_duration_seconds_count 1
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 10

http://localhost:8011/actuator/prometheus에서 Java REST API에 대한 메트릭을 확인할 수 있습니다. 메트릭 엔드포인트는 엄청난 텍스트지만 주요 데이터 포인트는 컨테이너가 CPU 시간, 메모리, 프로세서 쓰레드와 같은 리소스를 많이 사용하는 경우 "hot" 실행 중인지 여부를 보여주는 대시보드를 구축하기 위해 있습니다.

이들 런타임 메트릭은 도커의 인프라 메트릭 다음으로 원하는 세부 수준이지만 이 두 수준이 전체 내용을 말해주지는 않습니다. 최종 데이터 포인트는 앱에 대한 주요 정보를 기록하기 위해 명시적으로 캡처하는 앱 메트릭입니다. 이러한 메트릭은 구성 요소가 처리한 이벤트 수 또는 응답을 처리하는 평균 시간을 보여주는 작업 중심이거나 현재 활성 사용자 수 또는 새 서비스에 가입하는 사람들의 수를 보여주는 비즈니스 중심일 수 있습니다.

Prometheus 클라이언트 라이브러리를 사용하면 이러한 종류의 메트릭도 기록할 수 있지만 앱에서 정보를 캡처하려면 코드를 명시적으로 작성해야 합니다. 목록 9.1은 image-gallery 앱의 액세스 로그 구성 요소에 대한 코드에 있는 Node.js 라이브러리를 사용하는 예를 보여줍니다. server.js 파일의 이 스니펫은 몇 가지 핵심 사항을 보여줍니다.

목록 9.1 Node.js에서 사용자 정의 Prometheus 메트릭 값 선언 및 사용

 //declare custom metrics:
 const accessCounter = new prom.Counter({
   name: "access_log_total",
   help: "Access Log - total log requests"
 });
      
 const clientIpGauge = new prom.Gauge({
 	name: "access_client_ip_current",
	help: "Access Log - current unique IP addresses"
 });
      
 //and later, update the metrics values:
 accessCounter.inc();
 clientIpGauge.set(countOfIpAddresses);

소스 코드에서 Go로 작성된 image-gallery 앱과 Java로 작성된 image-of-the-day REST API에 메트릭을 추가한 방법을 볼 수 있습니다. 각 Prometheus 라이브러리는 다른 방식으로 작동합니다. main.go 소스 파일에서 Node.js 앱과 유사한 방식으로 카운터와 게이지를 초기화하지만 메트릭은 클라이언트 라이브러리의 계측 처리기를 사용합니다. Java 앱은 ImageController.java에서 @Timed 속성을 사용하고 소스에서 registry.counter 객체를 증가시킵니다. 각 클라이언트 라이브러리는 언어에 대해 가장 논리적인 방식으로 작동합니다.

Prometheus에는 다양한 유형의 메트릭이 있습니다. 앱에서는 가장 간단한 메트릭인 카운터와 게이지를 사용했습니다. 카운터는 증가하거나 동일하게 유지되는 값을 보유하고 게이지는 증가하거나 감소할 수 있는 값을 보유합니다. 메트릭 유형을 선택하고 정확한 시간에 값을 설정하는 것은 앱 개발자에게 달려 있습니다. 나머지는 Prometheus와 라이브러리에서 처리합니다.

TRY 마지막 연습에서 실행 중인 image-gallery 앱이 있으므로 이러한 메트릭이 이미 수집되고 있습니다. 앱에 로드를 실행한 다음 Node.js 앱의 메트릭 엔드포인트로 이동합니다.

 # loop to make 5 HTTP GET request on Linux:
 for i in {1..5}; do curl http://localhost:8010 > /dev/null; done

브라우저에서 http://localhost:8012/metrics

트래픽을 보내기 위해 몇 가지 루프를 더 실행했습니다. 처음 두 레코드는 수신된 액세스 요청 수와 서비스를 사용하는 총 IP 주소 수를 기록하는 내 사용자 지정 메트릭을 보여줍니다. 이들은 단순한 데이터 포인트(그리고 IP 수는 실제로 가짜임)이지만 메트릭을 수집하고 표시하는 목적으로 사용됩니다. Prometheus를 사용하면 더 복잡한 유형의 메트릭을 기록할 수 있지만 간단한 카운터와 게이지로도 앱에서 자세한 계측을 캡처할 수 있습니다.

동일한 메트릭 엔드포인트는 커스텀 값과 표준 node.js 데이터를 제공합니다.

# HELP access_log_total Access Log - total log requests
# TYPE access_log_total counter
access_log_total{hostname="44b8b3ed68e5"} 11

# HELP access_client_ip_current Access Log - current unique IP addresses
# TYPE access_client_ip_current gauge
access_client_ip_current{hostname="44b8b3ed68e5"} 8

클라이언트 라이브러리가 nodejs 런타임 메트릭을 제공됩니다. CPU 사용량을 보여줍니다.

# HELP process_cpu_system_seconds_total Total system CPU time spent in seconds.
# TYPE process_cpu_system_seconds_total counter
process_cpu_system_seconds_total{hostname="44b8b3ed68e5"} 3.4223400000000006 1647332972141

캡처하는 항목에 대해 몇 가지 유용한 지침을 제공합니다.

• 외부 시스템과 대화할 때 호출에 걸린 시간과 응답 성공 여부를 기록하세요. 다른 시스템이 속도를 늦추거나 방해하는지 빠르게 확인할 수 있습니다.

• 로깅할 가치가 있는 것은 잠재적으로 메트릭으로 기록할 가치가 있습니다. 로그 항목을 작성하는 것보다 카운터를 증가시키는 것이 메모리, 디스크 및 CPU에서 더 저렴할 수 있으며 일이 얼마나 자주 발생하는지 시각화하는 것이 좋습니다.

• 비즈니스 팀이 보고하려는 앱이나 사용자 액션 정보는 메트릭으로 기록되어야 합니다. 이렇게 하면 기록 보고서를 보내는 대신 실시간 대시보드를 구축할 수 있습니다.

9.3 Prometheus 컨테이너를 실행하여 메트릭 수집

Prometheus는 풀 모델을 사용하여 메트릭을 수집합니다. 다른 시스템에서 데이터를 보내도록 하는 대신 해당 시스템에서 데이터를 가져옵니다. 이를 스크래핑이라고 하며 Prometheus를 배포할 때 스크래핑할 엔드포인트를 구성합니다. 프로덕션 컨테이너 플랫폼에서 클러스터에서 모든 컨테이너를 자동으로 찾도록 Prometheus를 구성할 수 있습니다. 단일 서버의 Compose에서는 간단한 서비스 이름 목록을 사용하고 Prometheus는 도커의 DNS를 통해 컨테이너를 찾습니다.

Listing 9.2는 Prometheus가 image-gallery 앱에서 두 개의 구성 요소를 스크래핑하는데 사용한 구성을 보여줍니다. 스크랩 사이에 기본 10초 간격을 사용하는 전역 설정이 있으며 각 구성 요소에 대한 작업이 있습니다. 작업에는 이름이 있고 구성은 메트릭 끝점에 대한 URL 경로와 Prometheus가 쿼리할 대상 목록을 지정합니다. 여기서는 두 가지 유형을 사용합니다. 먼저 static_configs는 단일 컨테이너에 적합한 대상 호스트 이름을 지정합니다. 또한 dns_sd_configs를 사용합니다. 즉, Prometheus가 DNS 서비스 검색을 사용합니다. 즉, 서비스에 대해 여러 컨테이너를 찾고 대규모 실행을 지원합니다.

Listing 9.2 앱 메트릭을 수집하기 위한 구성

global:
  scrape_interval: 10s

scrape_configs:
  - job_name: "image-gallery"
    metrics_path: /metrics
    static_configs:
      - targets: ["image-gallery"]

  - job_name: "iotd-api"
    metrics_path: /actuator/prometheus
    static_configs:
      - targets: ["iotd"]

  - job_name: "access-log"
    metrics_path: /metrics
    scrape_interval: 3s
    dns_sd_configs:
      - names:
          - accesslog
        type: A
        port: 80
        
  - job_name: "docker"
    metrics_path: /metrics
    static_configs:
      - targets: ["DOCKER_HOST:9323"]

10초마다 모든 컨테이너를 폴링하도록 설정합니다. DNS를 사용하여 컨테이너 IP 주소를 가져오지만 image-gallery의 경우 단일 컨테이너만 찾을 것으로 예상하므로 해당 구성 요소를 확장하면 예기치 않은 동작이 발생합니다. Prometheus는 DNS 응답에 여러 개의 IP 주소가 포함된 경우 항상 목록의 첫 번째 IP 주소를 사용하므로 도커가 메트릭 엔드포인트에 대한 요청을 로드 밸런싱할 때 다른 컨테이너에서 메트릭을 가져옵니다. accesslog 구성 요소는 여러 IP 주소를 지원하도록 구성되어 있으므로 Prometheus는 모든 컨테이너 IP 주소 목록을 작성하고 동일한 일정에 모두 폴링합니다. 그림 9.8은 스크래핑 프로세스가 실행되는 방법을 보여줍니다.

그림 9.8 앱 컨테이너에서 메트릭을 스크랩하도록 구성되어 컨테이너에서 실행 중인 Prometheus

이미지 갤러리 앱을 위한 사용자 지정 Prometheus 도커 이미지를 구축했습니다. Prometheus 팀이 도커 Hub에 게시한 공식 이미지를 기반으로 하며 내 구성 파일에 복사합니다(이 장의 소스 코드에서 Dockerfile을 찾을 수 있음). 이 접근 방식은 추가 구성 없이 실행할 수 있는 사전 구성된 Prometheus 이미지를 제공하지만 필요한 경우 다른 환경에서 구성 파일을 항상 재정의할 수 있습니다.

메트릭은 많은 컨테이너가 실행 중일 때 더 흥미롭습니다. 이미지 갤러리 앱의 Node.js 구성 요소를 확장하여 여러 컨테이너에서 실행할 수 있으며 Prometheus는 모든 컨테이너에서 메트릭을 수집하고 수집합니다.

Try exercise 폴더에 acess-log 서비스에 대한 임의의 포트를 게시하는 또 다른 docker-compose.yml 파일이 있으므로 해당 서비스를 대규모로 실행할 수 있습니다. 3개의 인스턴스로 실행하고 웹사이트에 부하를 더 보냅니다.

docker-compose -f docker-compose-scale.yml up -d --scale accesslog=3
      
# loop to make 10 HTTP GET request - on Linux:
for i in {1..10}; do curl http://localhost:8010 > /dev/null; done

웹 사이트는 요청을 처리할 때마다 access-log 서비스를 호출합니다. 해당 서비스를 실행하는 컨테이너가 3개 있으므로 호출은 모두에서 로드 밸런싱되어야 합니다. 로드 밸런싱이 효과적으로 작동하는지 어떻게 확인할 수 있습니까? 해당 구성 요소의 메트릭에는 메트릭을 보내는 시스템의 호스트 이름을 캡처하는 레이블이 포함됩니다. 이 경우에는 컨테이너 ID입니다. Prometheus UI를 열고 access-log 메트릭을 확인하십시오. 세 가지 데이터 세트가 표시되어야 합니다.

TRY http://localhost:9090/graph로 이동합니다. 메트릭 드롭다운에서 access_log_total을 선택하고 실행을 클릭합니다.

그림 9.9에서 내 출력과 유사한 것을 볼 수 있습니다. 각 컨테이너에 대해 하나의 메트릭 값이 있고 레이블에는 호스트 이름이 포함됩니다. 각 컨테이너의 실제 값은 로드 밸런싱이 얼마나 고르게 분산되어 있는지 보여줍니다. 이상적인 시나리오에서는 수치가 같을 것이지만 많은 네트워크 요소(DNS 캐싱 및 HTTP 연결 유지 연결)가 작동하고 있습니다.

access_log_total{hostname="a",instance="172.31.0.7:80",job="access-log"}	4
access_log_total{hostname="b",instance="172.31.0.2:80",job="access-log"}	2
access_log_total{hostname="c",instance="172.31.0.6:80",job="access-log"}	3

레이블로 추가 정보를 기록하는 것은 Prometheus의 가장 강력한 기능 중 하나입니다. 다양한 세부 수준에서 단일 메트릭으로 작업할 수 있습니다. 지금 당신은 가장 최근의 메트릭 값을 보여주는 각 컨테이너에 대한 테이블의 한 행과 함께 메트릭에 대한 원시 데이터를 보고 있습니다. sum() 쿼리를 사용하여 모든 컨테이너에 걸쳐 집계하여 개별 레이블을 무시하고 결합된 합계를 표시할 수 있으며 이를 그래프에 표시하여 시간이 지남에 따라 증가하는 사용량을 볼 수 있습니다.

TRY Prometheus UI에서 그래프 추가 버튼을 클릭하여 새 쿼리를 추가하십시오. 표현식 텍스트 상자에 다음 쿼리를 붙여넣습니다.

sum(access_log_total) without(hostname, instance)

그림 9.10 모든 컨테이너의 값을 합산하기 위한 메트릭 집계 및 결과 그래프 표시

sum() 쿼리는 PromQL이라는 Prometheus의 자체 쿼리 언어로 작성되었습니다. 시간과 변화율에 따른 변경 사항을 쿼리할 수 있는 통계 기능이 있으며 하위 쿼리를 추가하여 다양한 메트릭을 연관시킬 수 있습니다. Prometheus 형식은 간단한 쿼리로 주요 메트릭을 시각화할 수 있을 정도로 잘 구성되어 있습니다. 레이블을 사용하여 값을 필터링하고 결과를 합산하여 집계할 수 있으며 이러한 기능만으로도 유용한 대시보드를 제공할 수 있습니다.

Prometheus UI는 구성을 확인하고 모든 스크래핑 대상에 도달할 수 있는지 확인하고 쿼리를 처리하는 데 적합합니다.

9.4 grafana 컨테이너를 실행하여 메트릭 시각화

모니터링은 컨테이너의 핵심 주제이기 때문에 이 장에서 많은 내용을 다루지만 더 자세한 세부 사항은 모두 앱에 매우 의존하기 때문에 빠르게 진행합니다. 캡처해야 하는 메트릭은 비즈니스 및 운영 요구 사항에 따라 다르며 캡처 방법은 사용 중인 앱 런타임과 해당 런타임에 대한 Prometheus 라이브러리의 메커니즘에 따라 다릅니다.

Prometheus에 데이터가 있으면 일이 더 간단해집니다. Prometheus UI를 사용하여 기록 중인 메트릭을 탐색하고 보고 싶은 데이터를 얻기 위한 쿼리 작업을 수행합니다. 그런 다음 Grafana를 실행하고 해당 쿼리를 대시보드에 연결합니다. 각 데이터 포인트는 사용자에게 친숙한 시각화로 표시되며 대시보드는 전체적으로 앱에서 어떤 일이 일어나고 있는지 보여줍니다.

이 챕터 내내 image-gallery 앱을 위한 grafana 대시보드를 만들기 위해 노력했으며 그림 9.12는 최종 결과를 보여줍니다. 모든 앱 구성 요소와 도커 런타임의 핵심 정보를 표시하는 매우 깔끔한 방법입니다. 이러한 쿼리는 규모를 지원하도록 구축되어 있으므로 프로덕션 클러스터에서 동일한 대시보드를 사용할 수 있습니다.

그림 9.12 Grafana 대시보드

grafana 대시보드는 다양한 수준으로 정보를 전달합니다. 각 시각화는 PromQL 쿼리로 구동되며 어떤 쿼리도 필터링 및 집계보다 더 복잡한 작업을 수행하지 않습니다. 그림 9.12의 축소된 보기는 전체 그림을 제공하지 않지만 컨테이너에서 직접 실행하고 탐색할 수 있도록 대시보드를 사용자 지정 Grafana 이미지로 패키징했습니다.

TRY 이번에는 docker-compose 파일이 찾아서 Prometheus 컨테이너에 주입하는 환경 변수로 컴퓨터의 IP 주소를 다시 캡처해야 합니다. 그런 다음 docker-compose로 앱을 실행하고 약간의 부하를 생성합니다.

# load your machine's IP address into an environment variable - on Linux:
export HOST_IP=$(ip route get 1 | awk '{print $NF;exit}')

# or on Mac:
hostIP=$(ifconfig en0 | grep -e 'inet\s' | awk '{print $2}')

# run the app with a Compose file
docker-compose -f ./docker-compose-with-grafana.yml up -d --scale accesslog=3
      
# now send in some load to prime the metrics - on Linux:
for i in {1..20}; do curl http://localhost:8010 > /dev/null; done

browse to http://localhost:3000

sum(image_gallery_requests_total{code="200"}) without(instance)

go_memstats_stack_inuse_bytes{job="image-gallery"}

sum(go_goroutines{job=\"image-gallery\"}) without(instance)

sum(image_gallery_requests_total{code="500"}) without(instance)

FROM diamol/grafana:6.4.3
      
COPY datasource-prometheus.yaml ${GF_PATHS_PROVISIONING}/datasources/
COPY dashboard-provider.yaml ${GF_PATHS_PROVISIONING}/dashboards/
COPY dashboard.json /var/lib/grafana/dashboards/