시리즈 중 첫 번째인 이 블로그 게시물에서는 Prometheus 서버를 설정하고 이를 Couchbase Capella 데이터베이스에 연결하여 메트릭을 수집하는 방법을 보여드리겠습니다.
프로메테우스란 무엇인가요?
프로메테우스 는 매우 인기 있는 오픈 소스 시스템 모니터링 및 알림 툴킷으로, 개발자 및 사용자 커뮤니티가 매우 활발하게 활동하고 있습니다. 원래는 SoundCloud의 일부였지만 이제는 어떤 회사로부터도 독립적으로 유지되는 독립형 오픈소스 프로젝트이며, 현재 클라우드 네이티브 컴퓨팅 재단 에 이어 2016년 두 번째 호스팅 프로젝트로서 Kubernetes.
카우치베이스 카펠라란 무엇인가요?
카우치베이스 카펠라 는 완전히 관리되는 서비스형 데이터베이스(DBaaS) 제품으로, Couchbase를 시작하고 지속적인 데이터베이스 관리 노력을 없애는 가장 쉽고 빠른 방법입니다. Capella 데이터베이스에는 기본 Prometheus 스크랩 대상이 포함되어 있어 Prometheus(또는 Prometheus와 호환되는) 모니터링 시스템을 연결하여 메트릭을 수집할 수 있습니다.
전제 조건
이 가이드의 단계를 따르려면 작동하는 Docker 설치(Prometheus 배포에 사용), Capella 데이터베이스 및 몇 가지 일반적인 셸 유틸리티가 필요합니다.
참고: 설치 및 구성 방법을 설명하는 것은 이 게시물의 범위를 벗어납니다. Docker. Docker 자체 튜토리얼을 포함하여 많은 튜토리얼이 있습니다. Docker 시작하기. 이 시점에서는 설치 및 테스트를 성공적으로 완료했다고 가정합니다(예 안녕하세요, 세상!).
이 글을 작성할 당시 Prometheus의 최신 버전은 2.46이었습니다. 여기서는 컨테이너 엔진이 dockerd(moby)로 설정된 Rancher Desktop 1.9.1을 사용하고 제공된 docker CLI를 사용하여 단계를 수행했습니다. 이 단계는 현재 Docker 설치 또는 nerdctl CLI를 사용하는 컨테이너와 같은 동등한 스택에서 그대로 작동할 것으로 예상됩니다.
마지막으로, 여기서 공유한 명령은 단기간의 독립형 개발 환경에 적합하며, 물론 적절한 경우 네트워킹 및 보안에 대한 현지 모범 사례를 따라야 합니다.
Docker에서 Prometheus 서버 실행하기
바로 들어가서 최신 Prometheus 컨테이너를 실행해 보겠습니다(프롬/프로메테우스)를 기본 설정으로 사용합니다.
그리고 도커 실행 명령에는 많은 옵션이 있지만 이 예제에서는 그냥 -p / -게시 를 사용하여 Prometheus 포트를 노출합니다(기본값은 9090)를 사용하여 로컬 브라우저에서 액세스할 수 있도록 하고, 그리고 -rm 를 사용하여 컨테이너가 종료될 때 청소가 완료되었는지 확인합니다.
기본적으로 실행 중인 컨테이너는 "연결된" 상태로 유지되어 표준 출력(이 경우 터미널)으로 로그를 스트리밍합니다. 처음 실행할 때 이 작업을 수행하여 올바르게 시작되는지 확인해 보겠습니다:
|
1 |
도커 실행 --rm --게시 9090:9090 무도회/프로메테우스 |
콘솔 출력에 오류가 표시되지 않는 한, 이제 Prometheus 서버가 다음 위치에서 실행 중이어야 합니다. http://localhost:9090/. 브라우저 창에서 열면 다음과 같은 내용이 표시됩니다:
이제 터미널 창으로 돌아가서 Ctrl+C 를 사용하여 실행 중인 컨테이너를 종료한 다음 다시 시작하지만 이번에는 -d / -분리 를 백그라운드로 설정하여 터미널을 비워두세요:
|
1 |
도커 실행 --분리 --rm --게시 9090:9090 무도회/프로메테우스 |
성공하면 Docker가 컨테이너 ID를 출력하며, 다음을 통해서도 컨테이너 ID를 찾을 수 있습니다. 도커 PS. 어차피 이후 단계 중 일부에 필요하므로 필터링( -f / -필터)의 출력을 도커 PS 를 사용하여 사용 중인 네트워크 포트에 따라 원하는 컨테이너 ID만 표시하도록 설정합니다(이 경우 포트 9090):
|
1 |
도커 ps --필터 게시=9090 |
추가할 수 있습니다. -q / -조용한 에 만 를 사용하여 컨테이너 ID를 출력하고 그 결과를 다른 명령에 사용합니다. 예를 들어 방금 시작한 Prometheus 컨테이너의 로그를 보려면 다음과 같이 하세요:
|
1 |
도커 로그 $(도커 ps --조용한 --필터 게시=9090) |
이 명령은 컨테이너가 아직 터미널에 연결되어 있을 때 Prometheus 서버를 처음 시작할 때와 비슷한 내용을 출력합니다. 예를 들어 다음과 같은 경우에도 동일한 기법을 사용할 수 있습니다. 도커 실행 (실행 중인 컨테이너에서 셸을 시작하려는 경우) 또는 도커 킬 (컨테이너에 신호를 보내기 위해).
현재 실행 중인 Prometheus 서버에 대해 자세히 살펴보겠습니다. http://localhost:9090/. 로 이동하면 상태 -> 대상를 클릭하면 이미 실행 중인 작업이 있음을 확인할 수 있습니다:
이 Prometheus 서버는 다음과 같이 스크래핑하도록 구성되었습니다. 자체 를 대상으로 설정하면 해당 설정을 확인하여 확인할 수 있습니다(상태 -> 구성):
위 그림에서 다음과 같은 이름의 작업이 있는 것을 볼 수 있습니다. 프로메테우스를 타겟팅하는 localhost:9090/metrics (대상 + 메트릭_경로). 참조 자체 모니터링을 위한 Prometheus 구성 를 클릭해 샘플 구성을 확인하세요.
터미널로 돌아가기 전에 위의 작업에서 스크랩되는 메트릭에 대해 간단히 살펴보겠습니다. 그래프를 클릭하면 아래와 같이 표현식 브라우저를 사용하여 PromQL 식을 입력할 수 있습니다( 프로메테우스 쿼리하기 )을 클릭하고 결과를 확인합니다.
참고 표현식 브라우저 는 임시 용도로만 사용해야 하며, 권장 사항은 Grafana 를 본격적인 그래프 솔루션으로 도입할 계획이며, 이에 대해서는 다음 포스트에서 살펴보도록 하겠습니다. 그 동안 간단한 예로 현재 자체 데이터베이스에 저장되어 있는 시계열의 수(프로메테우스_TSDB_헤드_시리즈):
Prometheus 서버에 Capella 데이터베이스를 스크랩 작업으로 추가하려면 위에서 본 구성을 변경해야 하지만 구성은 컨테이너 이미지에 구워져 있습니다. 최종 구성이 완료되면 이미지를 다시 빌드할 수 있지만, 지금은 그렇게 많은 노력을 들이지 않고도 새로운 구성 옵션을 적용하고 테스트할 수 있다면 훨씬 더 편리할 것입니다.
Docker의 -v / -볼륨 옵션을 사용하면 컨테이너에 로컬 파일이나 디렉터리를 마운트할 수 있습니다. 컨테이너의 Prometheus 구성 파일은 다음과 같습니다. /etc/prometheus/prometheus.yml - 파일만 필요하다면 파일을 직접 마운트하면 되지만, 그보다 몇 개 더 필요하므로 대신 디렉터리를 마운트하겠습니다.
작업 디렉터리에서 구성을 유지하는 데 사용할 하위 디렉터리를 만듭니다(prometheus.yml) 및 기타 관련 파일.
|
1 |
mkdir 프로메테우스 |
이제 작업할 수 있는 구성 파일의 사본이 필요합니다. 항상 그렇듯이 이 작업을 수행하는 방법은 여러 가지가 있지만 가장 간단한 방법은 도커 cp 명령을 복사하려면 /etc/prometheus/prometheus.yml 를 실행 중인 컨테이너에서 로컬 파일로 내보냅니다:
|
1 |
도커 cp $(도커 ps --조용한 --필터 게시=9090):/등/프로메테우스/프로메테우스.yml 프로메테우스/ |
이제 현재 실행 중인 컨테이너를 종료합니다:
|
1 |
도커 kill $(도커 ps --조용한 --필터 게시=9090) |
그런 다음 새 컨테이너를 시작하고 이번에는 로컬 컨테이너를 마운트합니다. 프로메테우스 디렉토리를 /etc/prometheus/ 를 컨테이너에 넣습니다:
|
1 |
도커 실행 --분리 --rm --게시 9090:9090 --볼륨 $(pwd)/프로메테우스/:/등/프로메테우스/ 무도회/프로메테우스 |
작성자처럼 Prometheus 서버가 실제로 내 복사본을 사용하고 있는지 확인하는 방법이 궁금하다면 prometheus.yml 여부는 컨테이너 내부의 마운트를 확인하여 확인할 수 있습니다. /etc/prometheus/ 가 특별히 탑재되어 있습니다:
|
1 |
도커 exec $(도커 ps --조용한 --필터 게시=9090) 마운트 | grep '/etc/prometheus' |
구성(예: 기존 스크랩 작업의 이름)을 약간 변경할 수도 있으며, 이 변경 사항은 콘솔에 반영되어야 합니다( http://localhost:9090/config).
마지막으로 이 섹션에서는 구성 파일을 몇 가지 변경할 예정이므로 변경 사항을 적용하기 위해 컨테이너를 다시 만들 필요가 없다면 좋을 것입니다. Prometheus에는 이를 위한 API 메서드가 내장되어 있습니다. 구성하지만 -web.enable-lifecycle 옵션은 공식 컨테이너에서 기본적으로 활성화되어 있지 않습니다. 다행히도 (적어도 MacOS 및 Linux 사용자의 경우) 다음과 같이 SIGHUP을 보낼 수 있는 옵션이 있습니다. 도커 킬 (로그에 "구성 파일 로드 중" 메시지가 표시됨):
|
1 |
도커 kill --신호 SIGHUP $(도커 ps --조용한 --필터 게시=9090) |
지금까지의 내용을 요약하면, 이제 Prometheus 서버가 실행 중이고, 로그를 확인하고, 스크랩 중인 메트릭을 탐색하고, 구성을 업데이트하고 다시 로드하는 방법을 알게 되었으며, Capella 데이터베이스를 스크랩 대상으로 쉽게 추가할 수 있게 되었습니다.
Prometheus 서버에 아카펠라 데이터베이스 추가하기
이제 Prometheus 서버가 생겼으니 Couchbase Capella 데이터베이스를 추가하는 방법을 살펴보겠습니다.
전제 조건
메트릭을 수집하려는 각 데이터베이스에 대해 다음이 필요합니다:
-
- 연결 호스트 이름
- 적절한 데이터베이스 액세스 권한이 있는 사용자 자격 증명
- 보안 인증서
- 하나 이상의 허용된 IP 주소
연결 호스트 이름
연결 문자열의 호스트 이름입니다. 연결 문자열의 연결 탭을 클릭하고 아카펠라 UI에서 데이터베이스의 카우치베이스:// 스키마 접두사를 추가합니다. 이 예제에서 사용하는 것은 다음과 같습니다: cb.plmvshfqolmyxvpt.cloud.couchbase.com.
사용자 자격 증명
자격 증명 집합(사용자 이름/비밀번호) 읽기 액세스 에 모든 버킷 그리고 모든 범위 데이터베이스에서 ( 참고필수 외부_통계_리더 역할은 다음과 같은 경우에만 부여됩니다. 데이터베이스 자격 증명에 읽기 액세스 권한이 부여됩니다. 모두 데이터베이스의 버킷). 없는 경우 다음에서 만들 수 있습니다. 설정 -> 데이터베이스 액세스 -> 데이터베이스 액세스 만들기 (참조 데이터베이스 자격 증명 구성). 이 예에서는 다음을 사용합니다. metrics_user / metrics_Passw0rd.
보안 인증서
데이터베이스의 보안 인증서입니다. 데이터베이스에서 다음 항목으로 이동합니다. 설정 -> 보안 인증서를 클릭하고 다운로드를 클릭합니다. 그러면 클러스터의 이름을 딴 PEM 형식의 텍스트 파일이 제공됩니다(이 경우 bravetimbernerslee-root-certificate.txt). 실제로 모든 카펠라 데이터베이스에 동일한 서명 인증서가 사용되므로 한 번만 다운로드하면 되고, 동일한 루트 인증서를 사용하여 모든 카펠라 데이터베이스를 확인할 수 있습니다. 이를 위해 로컬 인증서 파일의 이름을 다음과 같이 변경했습니다. couchbase-cloud-root-certificate.pem 에 복사하여 명확성을 위해 프로메테우스 디렉토리(하위 디렉토리의 certs)에 저장하여 나중에 Prometheus가 액세스할 수 있도록 합니다.
허용된 IP 주소
클라이언트가 아카펠라 데이터베이스에 연결하려면 먼저 클라이언트의 IP 주소를 데이터베이스의 허용된 IP 목록. 여기 단계를 따르기 위한 목적으로 현재 IP 주소를 추가하고 싶을 가능성이 높으며, 이 경우 다음을 사용할 수 있습니다. 내 IP 추가 버튼을 클릭합니다. 프로덕션 배포의 경우 Prometheus 서버의 공용 IP 주소가 필요합니다.
새 스크랩 구성 정의하기
먼저 프로메테우스에게 스스로 긁어내라고 지시하는 기존 작업을 살펴봅시다.
전역 설정과 기본값을 무시하면 다음과 같이 됩니다:
|
1 2 3 4 5 |
스크랩_컨피그: - job_name: "프로메테우스" static_configs: - 대상: ["localhost:9090"] |
에 대한 문서를 보면 스크랩_구성 를 보면 이것이 본질적으로 가능한 가장 작은 작업 정의라는 것을 알 수 있습니다. TLS도 없고 인증도 없으며 이름과 단일 대상만 있습니다(기본값을 추가하면 다음과 같이 됩니다. http://localhost:9090/metrics).
여담이지만, 관심이 있다면 브라우저에서 해당 URL을 불러오거나 다음을 사용하여 테스트해 볼 수 있습니다. curl 를 입력합니다. 결과 출력은 Prometheus의 텍스트 기반 박람회 형식.
새 작업에는 이름이 필요합니다. 이 이름은 모든 스크랩 정의에서 고유해야 하며, 여러 개의 아카펠라 데이터베이스를 추가할 계획이라면 이 점을 염두에 두어야 합니다. 이 예에서는 연결 호스트 이름의 고유한 구성 요소를 사용하여 구분하겠습니다:
|
1 |
- job_name: "CAPELLA-PLMVSHFQOLMYXVPT" |
위의 자격 증명을 사용하여 메트릭 엔드포인트에 액세스하려면 인증이 필요하다는 것을 알고 있습니다:
|
1 2 3 |
기본_인증: 사용자 이름: "metrics_user" 비밀번호: "metrics_Passw0rd" |
모든 아카펠라 통신은 TLS로 암호화되어 있으므로 tls_config 매개변수에 앞서 다운로드한 인증서를 사용하여 설정합니다:
|
1 2 |
tls_config: ca_file: "certs/couchbase-cloud-root-certificate.pem" |
그리고 관련해서, scheme 기본값은 http가 필요합니다:
|
1 |
scheme: https |
마지막으로 해야 할 일은 데이터베이스에 연결하는 데 사용할 호스트 이름/주소를 Prometheus에 알려주는 것입니다. 대상.
에서 프로메테우스 작업에서 단일 호스트 이름을 사용하는 경우 static_config 매개변수를 사용할 수 있습니다. 이름에서 알 수 있듯이 하나 이상의 매개 변수를 정적으로 정의하는 방법입니다. 대상로 설정되어 있으며, Prometheus 서버를 다시 시작하거나 구성 파일을 다시 로드하지 않는 한 업데이트되거나 새로 고쳐지지 않습니다.
이 경우 호스트 이름(localhost)는 절대 변경되지 않습니다. 가끔씩 변경되는 호스트 이름이 있고 통제된 상황(예: 예정된 유지 관리 기간에 Prometheus 구성을 동시에 업데이트할 수 있는 경우)에서만 업데이트되는 경우에도 관리가 가능할 수 있습니다.
하지만 호스트 이름이 자주 변경되고 그 변경 시기가 사용자가 통제할 수 없는 경우라면 어떻게 해야 할까요? 모니터링하는 애플리케이션이 온디맨드 확장, 장애 시 서버 교체, 자동 업그레이드가 있는 모든 종류의 클라우드 환경에서 호스팅되는 경우, 훨씬 더 유연한 방법으로 호스트 이름을 지정해야 합니다. 대상.
이것이 바로 서비스 검색이 필요한 이유입니다.
서비스 검색
Prometheus 서비스 검색(SD)은 특정 애플리케이션 또는 서비스를 모니터링할 대상 목록을 동적으로 검색(및 업데이트)할 수 있는 메커니즘입니다. 이 글을 쓰는 시점에서 다음과 같은 일반 옵션을 포함하여 28개의 서로 다른 메커니즘이 있습니다. 파일- 그리고 HTTP 기반 서비스 검색은 물론 수많은 클라우드 플랫폼 및 애플리케이션에 대한 구체적인 구현을 제공합니다(Prometheus 구성 문서 를 참조하세요.)
이 두 가지 일반적인 옵션을 카우치베이스 아카펠라 데이터베이스와 관련하여 살펴보겠습니다.
파일 기반 서비스 검색 (file_sd_configs)는 하나 이상의 파일 이름이 Prometheus에 제공되고 각 파일에 0개 이상의 static_config 항목. 프로메테우스는 잘 구성된 모든 항목에 대상 를 사용하여 해당 파일에서 찾은 변경 사항을 자동으로 로드하고, 파일이 업데이트되면 변경 사항을 자동으로 로드합니다.
이 메커니즘은 호스트 세부 정보를 올바른 형식의 파일로 가져올 수만 있다면(수동 또는 적절한 자동화를 통해) 어떤 임의의 시스템에도 연결할 수 있다는 점에서 유용합니다. 하지만 파일을 업데이트하는 자동화가 신뢰할 수 있는지 확인해야 합니다.
HTTP 기반 서비스 검색 (HTTP_SD_CONFIGS)는 0개 이상의 페이로드가 포함된 일반 인터페이스를 제공한다는 점에서 파일 기반과 유사합니다. static_config 항목과 비슷하지만 로컬 파일을 읽는 대신 HTTP 연결을 사용하여 페이로드를 가져옵니다. 이렇게 하면 자동화나 사람의 개입에 대한 종속성이 제거되며, 대상 애플리케이션이 관련 API를 제공하는 한 파일 기반 옵션보다 선호될 수 있습니다.
이 글을 쓰는 시점에, 저희는 Capella 자산을 Couchbase Server 7.1에서 7.2로 업그레이드하는 작업을 진행 중입니다( 데이터베이스 업그레이드 를 참조하세요.) Server 7.1에서는 기본적인 파일 기반 서비스 검색 API만 제공했지만, Server 7.2에서는 HTTP 기반 SD와 개선된 파일 기반 SD를 추가했습니다.
먼저 Server 7.1의 파일 기반 서비스 검색 방법을 살펴보겠습니다. 이미 Server 7.2를 실행 중인 경우 한 섹션을 건너뛰셔도 됩니다.
카우치베이스 서버 7.1의 파일 기반 서비스 검색
엔드포인트는 다음과 같습니다. prometheus_sd_config.yaml를 실행하려면 위와 동일한 자격 증명으로 인증하고 앞서 다운로드한 카펠라 루트 인증서를 제공해야 합니다.
먼저 curl 를 클릭하고 결과를 터미널로 스트리밍합니다:
|
1 |
curl --cacert /경로/에/카우치베이스-클라우드-root-인증서.pem -u 'metrics_user:metrics_password' https://cb.plmvshfqolmyxvpt.cloud.couchbase.com:18091/프로메테우스_sd_config.yaml |
우리 클러스터의 경우 이렇게 합니다:
|
1 2 3 4 5 6 |
- 대상: - 'svc-d-node-001.plmvshfqolmyxvpt.cloud.couchbase.com:8091' - 'svc-d-node-002.plmvshfqolmyxvpt.cloud.couchbase.com:8091' - 'svc-d-node-003.plmvshfqolmyxvpt.cloud.couchbase.com:8091' - 'svc-qi-node-004.plmvshfqolmyxvpt.cloud.couchbase.com:8091' - 'svc-qi-node-005.plmvshfqolmyxvpt.cloud.couchbase.com:8091' |
여기서 현재 서비스 검색 API의 한계를 확인할 수 있습니다. 모든 통신이 보안 포트(18091)를 통해 이루어지기 때문에 항상 비보안 포트(8091)를 반환하며, 이는 Capella에서는 아무런 소용이 없습니다. 이 문제는 Server 7.2의 개선 사항으로 해결되지만, 개선 사항이 적용될 때까지는 포트 번호를 업데이트하기 위한 추가 단계를 추가해야 합니다.
이 데모를 위해 다음과 같이 파이프를 연결하겠습니다. sed로 설정할 수 있지만, 사용자 환경에 가장 적합한 방법을 사용할 수 있습니다:
|
1 |
curl --cacert /경로/에/카우치베이스-클라우드-root-인증서.pem -u 'metrics_user:metrics_password' https://cb.plmvshfqolmyxvpt.cloud.couchbase.com:18091/프로메테우스_sd_config.yaml | sed 's/:8091/:18091/' |
우리 클러스터의 경우 이제 이렇게 됩니다:
|
1 2 3 4 5 6 |
- 대상: - 'svc-d-node-001.plmvshfqolmyxvpt.cloud.couchbase.com:18091' - 'svc-d-node-002.plmvshfqolmyxvpt.cloud.couchbase.com:18091' - 'svc-d-node-003.plmvshfqolmyxvpt.cloud.couchbase.com:18091' - 'svc-qi-node-004.plmvshfqolmyxvpt.cloud.couchbase.com:18091' - 'svc-qi-node-005.plmvshfqolmyxvpt.cloud.couchbase.com:18091' |
이제 올바른 출력을 얻었으니 나중에 작업 정의에서 사용할 파일로 리디렉션할 수 있습니다.
작업 디렉터리에서 하위 디렉터리를 사용하여 대상을 함께 보관하고 작업 이름 뒤에 파일 이름을 지정합니다(이 예제의 경우 CAPELLA-PLMVSHFQOLMYXVPT):
|
1 |
curl --cacert /경로/에/카우치베이스-클라우드-root-인증서.pem -u 'metrics_user:metrics_password' https://cb.plmvshfqolmyxvpt.cloud.couchbase.com:18091/프로메테우스_sd_config.yaml | sed 's/:8091/:18091/' > $(pwd)/프로메테우스/대상/아카펠라-plmvshfqolmyxvpt.yml |
데모에서는 이 정도면 충분하지만, 여러분의 환경에 맞게 적절하게 오류 처리를 추가하여 강력하고 적합한지 확인해야 할 것입니다. 그리고 결정적으로, 토폴로지 변경이 발생할 때마다 대상 목록이 업데이트되도록 정기적으로 실행되도록 예약해야 합니다( cron 로 충분할 것입니다).
이제 위에 있는 모든 것을 가져와서 우리의 file_sd_configs새 작업은 다음과 같습니다:
|
1 2 3 4 5 6 7 8 9 10 |
- job_name: "CAPELLA-PLMVSHFQOLMYXVPT" 기본_인증: 사용자 이름: "metrics_user" 비밀번호: "metrics_Passw0rd" tls_config: ca_file: "certs/couchbase-cloud-root-certificate.pem" scheme: https file_sd_configs: - 파일: - "targets/capella-plmvshfqolmyxvpt.yml" |
카우치베이스 서버 7.2의 HTTP 기반 서비스 검색
Server 7.2에서는 새로운 엔드포인트(프로메테우스_sd_config), 위와 유사하게 생성한 자격 증명으로 인증하고 앞서 다운로드한 Capella 루트 인증서를 제공해야 합니다.
먼저 curl 를 호출하여 결과를 터미널로 스트리밍합니다. 새 API의 기본 출력은 JSON이므로 다음 주소로 파이핑합니다. jq 를 입력하세요:
|
1 |
curl --cacert /경로/에/카우치베이스-클라우드-root-인증서.pem -u 'metrics_user:metrics_password' https://cb.plmvshfqolmyxvpt.cloud.couchbase.com:18091/프로메테우스_sd_config | jq |
업그레이드된 클러스터(업그레이드 프로세스 중에 호스트 이름이 변경된 경우)의 경우 이렇게 됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 |
[ { "대상": [ "svc-d-node-006.plmvshfqolmyxvpt.cloud.couchbase.com:18091", "svc-d-node-007.plmvshfqolmyxvpt.cloud.couchbase.com:18091", "svc-d-node-008.plmvshfqolmyxvpt.cloud.couchbase.com:18091", "svc-qi-node-009.plmvshfqolmyxvpt.cloud.couchbase.com:18091", "svc-qi-node-010.plmvshfqolmyxvpt.cloud.couchbase.com:18091" ] } ] |
이 출력은 프로메테우스가 기대하는 것과 정확히 일치하므로, 우리가 사용한 인수를 curl 명령을 사용하여 HTTP_SD_CONFIGS 스크랩 구성으로 변경합니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
- job_name: "CAPELLA-PLMVSHFQOLMYXVPT" 기본_인증: 사용자 이름: "metrics_user" 비밀번호: "metrics_Passw0rd" tls_config: ca_file: "certs/couchbase-cloud-root-certificate.pem" scheme: https HTTP_SD_CONFIGS: - URL: https//cb.plmvshfqolmyxvpt.cloud.couchbase.com:18091/prometheus_sd_config 기본_인증: 사용자 이름: "metrics_user" 비밀번호: "metrics_Passw0rd" tls_config: ca_file: "certs/couchbase-cloud-root-certificate.pem" |
새 작업 실행
이 시점에서 Prometheus 서버에 새 스크랩 작업을 추가하는 데 필요한 모든 것이 갖추어져 있을 것입니다. 아직 Couchbase Server 7.1을 사용 중인 경우, 이 서버는 file_sd_configs 기반 하나(필요한 단계에 따라 대상 파일), Server 7.2를 실행 중인 경우 HTTP_SD_CONFIGS 기반 버전입니다.
새 작업을 prometheus.yml을 클릭한 다음 kill 명령어를 사용했습니다:
|
1 |
도커 kill --신호 SIGHUP $(도커 ps --조용한 --필터 게시=9090) |
그런 다음 로그를 확인하여 구성이 깨끗하게 로드되었는지 확인할 수 있습니다:
|
1 |
도커 로그 $(도커 ps --조용한 --필터 게시=9090) |
여러분이 찾고 있는 것은 구성 파일 로드 로그 메시지를 확인하면 구성이 유효한 한 구성 파일 로딩 완료 메시지가 즉시 표시됩니다. 다시 로드에 성공하지 못하면 문제를 해결하고 다시 시도해야 합니다. 로드가 완료되면 다시 돌아가서 Prometheus 콘솔의 http://localhost:9090/.
먼저 새로운 구성을 살펴보겠습니다(상태 -> 구성)를 클릭하면 방금 추가한 작업이 표시됩니다.
다음은 파일 기반 서비스 검색을 사용한 전체 구성입니다:
다음은 HTTP 기반 스크랩을 대신 보여주는 스니펫입니다:
이제 다음을 살펴보면 상태 -> 대상를 클릭하면 Capella 데이터베이스의 모든 노드가 표시되어야 합니다. 예를 들어, 이것은 Server 7.2로 업그레이드하기 전의 클러스터입니다:
이와 관련하여 목표가 예상과 다른 경우, 상태 -> 서비스 검색 는 각 엔드포인트의 출처를 보여줍니다. 다음은 HTTP SD를 사용하는 업그레이드된 클러스터의 서비스 검색 상태입니다(처음 몇 개의 노드만 표시하도록 잘라낸 것임):
이제 아카펠라 데이터베이스를 추가했으니 실제로 유용한 정보를 얻고 있는지 어떻게 확인할 수 있을까요?
먼저, 앞서의 그래프를 다시 살펴보면 저장되는 시계열의 수(프로메테우스_TSDB_헤드_시리즈)는 상당히 성장했습니다:
그러면 실제로 일부 Couchbase Server 메트릭이 캡처되었음을 확인할 수 있습니다. 우리는 여행 샘플 데이터베이스에 로드된 데이터 세트에는 63,000개가 조금 넘는 항목이 포함되어 있습니다. 다음과 같이 쿼리하면 KV_CURR_ITEMS 세 개의 데이터 서비스 노드에 각각 약 21,000개의 항목이 있음을 알 수 있습니다:
결론
이 글에서는 로컬 개발 환경에서 간단한 Prometheus 서버를 실행하는 방법과 이를 모니터링할 수 있도록 Couchbase Capella 데이터베이스를 추가하는 방법을 보여드렸습니다. 이 시리즈의 다음 글에서는 이제 메트릭이 생겼으니 이 메트릭으로 무엇을 할 수 있는지 보여드리겠습니다.
언제나 그렇듯이 모든 피드백에 감사드리며, 여기에 댓글을 남겨 주시면 언제든지 문의해 주시거나 포럼또는 불화.










Capella로 VPC 피어링을 사용할 때 cb.plmvshfqolmyxvpt.cloud.couchbase.com에 연결할 수 없습니다.
VPC 피어링에서 서비스 검색을 수행하려면 어떻게 해야 하나요?
연결 페이지에 언급된 호스트에 연결할 수 없는 경우 VPC 피어링과 함께 Capella를 사용합니다.
VPC에서 카펠라로 서비스 검색을 할 수 있나요?