측정항목 보기

이 주제에서는 Stackdriver 대시보드에서 Apigee Hybrid 측정항목을 보는 방법을 설명합니다.

Stackdriver 정보

측정항목, 대시보드, Stackdriver에 대한 자세한 내용은 다음을 참조하세요.

하이브리드 측정항목 사용 설정

하이브리드 측정항목을 Stackdriver로 보내려면 먼저 측정항목 수집을 사용 설정해야 합니다. 이 절차의 측정항목 수집 구성을 참조하세요.

하이브리드 측정항목 이름 및 라벨 정보

사용 설정된 경우 하이브리드가 Stackdriver 측정항목을 자동으로 채웁니다. 하이브리드에서 생성된 측정항목의 도메인 이름 프리픽스는 다음과 같습니다.

apigee.googleapis.com/

예를 들어 /proxy/request_count 측정항목에는 API 프록시가 수신한 요청 총수가 포함됩니다. 따라서 Stackdriver의 측정항목 이름은 다음과 같습니다.

apigee.googleapis.com/proxy/request_count

Stackdriver를 사용하면 라벨을 기반으로 측정항목 데이터를 필터링하고 그룹화할 수 있습니다. 일부 라벨은 사전 정의되며 다른 라벨은 하이브리드에 의해 명시적으로 추가됩니다. 아래의 사용 가능한 측정항목 섹션에는 사용 가능한 모든 하이브리드 측정항목과 필터링 및 그룹화에 사용할 수 있도록 측정항목에 특별히 추가된 라벨이 나열됩니다.

측정항목 보기

다음 예시는 Stackdriver에서 측정항목을 보는 방법을 보여줍니다.

브라우저에서 측정 항목 탐색기 모니터링을 엽니다. 또는 이미 Stackdriver 콘솔에 있는 경우 측정항목 탐색기를 선택합니다.
리소스 유형 및 측정항목 찾기에서 살펴볼 측정항목을 찾아 선택합니다. 사용 가능한 측정항목에 나열된 특정 측정항목을 선택하거나 측정항목을 검색합니다. 예를 들어 proxy/latencies를 검색합니다.
원하는 측정항목을 선택합니다.
필터를 적용합니다. 각 측정항목의 필터 선택사항은 사용 가능한 측정항목에 나열되어 있습니다. 예를 들어 proxy_latencies 측정항목의 경우 필터 선택사항은 org=org_name입니다.
Stackdriver에서 선택한 측정항목의 차트를 표시합니다.
저장을 클릭합니다.

대시보드 만들기

대시보드는 중요한 측정항목 데이터를 보고 분석할 수 있는 한 가지 방법입니다. Stackdriver에서 사용자가 사용하는 리소스 및 서비스에 대해 제공하는 사전 정의된 대시보드를 사용하거나 커스텀 대시보드를 만들 수도 있습니다.

차트를 사용하여 커스텀 대시보드에 Apigee 측정항목을 표시합니다. 커스텀 대시보드를 사용하면 표시된 차트와 구성을 완벽하게 제어할 수 있습니다. 차트 만들기에 대한 자세한 내용은 차트 만들기를 참조하세요.

다음 예는 Stackdriver에서 대시보드를 만든 다음 차트를 추가하여 측정항목 데이터를 보는 방법을 보여줍니다.

브라우저에서 Monitoring 측정항목 탐색기를 열고 대시보드를 선택합니다.
+대시보드 만들기를 선택합니다.
대시보드 이름을 지정하십시오. 예시: 하이브리드 프록시 요청 트래픽
확인을 클릭합니다.
대시보드에 추가하려는 각 차트에 대해 다음 단계를 따르세요.
1. 대시보드에서 차트 추가를 선택합니다.
2. 측정항목 보기에 설명된 대로 원하는 측정항목을 선택합니다.
3. 대화상자를 완성해 차트를 정의합니다.
4. 저장을 클릭합니다. Stackdriver는 선택한 측정항목에 대한 데이터를 표시합니다.

사용 가능한 측정항목

다음 표에는 프록시 트래픽 분석용 측정항목이 나열되어 있습니다.

프록시, 대상 서버 트래픽 측정항목

Prometheus 서비스는 측정항목 수집에 설명된 대로 프록시, 대상, 서버 트래픽의 측정항목을 수집하고 처리합니다.

다음 표에서는 Prometheus에서 사용하는 측정항목과 라벨을 설명합니다. 이러한 라벨은 측정항목 로그 항목에 사용됩니다.

측정항목 이름	라벨	사용
`/proxy/request_count`	`method`	수신된 API 프록시 요청의 총 개수입니다.
`/proxy/response_count`	`method` `response_code`	수신된 API 프록시 응답의 총 개수입니다.
`/proxy/latencies`	`method`	호출에 응답하는 데 걸린 총 시간(밀리초)입니다. 이 시간에는 Apigee API 프록시 오버헤드와 대상 서버 시간이 포함됩니다.
`/target/request_count`	`method` `target_type` `target_endpoint`	프록시의 대상으로 전송된 요청의 총 개수입니다.
`/target/response_count`	`method` `response_code` `target_type` `target_endpoint`	프록시 대상에서 수신된 응답의 총 개수입니다.
`/target/latencies`	`method` `response_code` `target_type` `target_endpoint`	호출에 응답하는 데 걸린 총 시간(밀리초)입니다. 이 시간에는 Apigee API 프록시 오버헤드가 포함되지 않습니다.
`/policy/latencies`	`policy_name`	이 이름이 지정된 정책을 실행하는 데 걸린 총시간(밀리초)입니다.
`/server/fault_count`	`source`	서버 애플리케이션 오류의 총 개수입니다. 예를 들어 애플리케이션은 `apigee-runtime`, `apigee-synchronizer` 또는 `apigee-udca`일 수 있습니다. `pod_name` 라벨을 사용하여 애플리케이션별로 결과를 필터링하세요.
`/server/nio`	`state`	열려 있는 소켓의 수입니다.
`/server/num_threads`		서버의 활성 비데몬 스레드 수입니다.
`/server/request_count`	`method` `type`	서버 애플리케이션에서 수신한 요청의 총 개수입니다. 예를 들어 애플리케이션은 `apigee-runtime`, `apigee-synchronizer` 또는 `apigee-udca`일 수 있습니다. `pod_name` 라벨을 사용하여 애플리케이션별로 결과를 필터링하세요.
`/server/response_count`	`method` `response_code type`	서버 애플리케이션에서 보낸 응답의 총 개수입니다. 예를 들어 애플리케이션은 `apigee-runtime`, `apigee-synchronizer` 또는 `apigee-udca`일 수 있습니다. `pod_name` 라벨을 사용하여 애플리케이션별로 결과를 필터링하세요.
`/server/latencies`	`method` `response_code type`	지연 시간은 서버 애플리케이션으로 인한 지연 시간(밀리초)입니다. 예를 들어 애플리케이션은 `apigee-runtime`, `apigee-synchronizer` 또는 `apigee-udca`일 수 있습니다. `pod_name` 라벨을 사용하여 애플리케이션별로 결과를 필터링하세요.
`/upstream/request_count`	`method` `type`	서버 애플리케이션에서 업스트림 애플리케이션으로 전송한 요청 수입니다. 예를 들어 `apigee-synchronizer`의 경우 컨트롤 플레인은 업스트림입니다. 따라서 `apigee-synchronizer`의 `upstream/request_count`는 컨트롤 플레인에 대해 `apigee-synchronizer`가 수행한 요청을 나타내는 측정항목입니다.
`/upstream/response_count`	`method` `response_code` `type`	서버 애플리케이션이 업스트림 애플리케이션에서 수신한 응답 수입니다. 예를 들어 `apigee-synchronizer`의 컨트롤 플레인은 업스트림입니다. 따라서 `apigee-synchronizer`의 `upstream/response_count`는 `apigee-synchronizer`가 컨트롤 플레인에서 수신한 요청을 나타내는 측정항목입니다.
`/upstream/latencies`	`method` `response_code type`	업스트림 서버 애플리케이션에서 발생하는 지연 시간(밀리초)입니다. 예를 들어 `apigee-synchronizer`의 컨트롤 플레인은 업스트림입니다. 따라서 `apigee-synchronizer`의 `upstream/latencies`는 컨트롤 플레인의 지연 시간을 나타내는 측정항목입니다.

UDCA 측정항목

Prometheus 서비스는 다른 하이브리드 서비스와 마찬가지로 UDCA 서비스에 대한 측정항목을 측정항목 수집에 설명된 대로 수집하고 처리합니다.

다음 표에서는 Prometheus가 UDCA 측정항목 데이터에 사용하는 측정항목과 라벨을 설명합니다. 이러한 라벨은 측정항목 로그 항목에 사용됩니다.

측정항목 이름	라벨	사용
`/udca/server/local_file_oldest_ts`	`dataset` `state`	데이터 세트에서 가장 오래된 파일에 대한 Unix Epoch의 시작 이후의 타임스탬프(밀리초)입니다. 이 값은 60초마다 계산되며 실시간으로 상태를 반영하지는 않습니다. UDCA가 최신 상태이며 이 측정항목을 계산할 때 업로드 대기 중인 파일이 없는 경우 이 값은 0입니다. 이 값이 계속 증가하면 기존 파일은 여전히 디스크에 있습니다.
`/udca/server/local_file_latest_ts`	`dataset` `state`	디스크의 최신 파일에 대한 Unix Epoch의 시작 이후의 타임스탬프(밀리초)입니다. 이 값은 60초마다 계산되며 실시간으로 상태를 반영하지는 않습니다. UDCA가 최신 상태이며 이 측정항목을 계산할 때 업로드 대기 중인 파일이 없는 경우 이 값은 0입니다.
`/udca/server/local_file_count`	`dataset` `state`	데이터 수집 포드에 있는 디스크의 파일 수입니다. 이상적으로 값은 0에 가깝습니다. 값이 지속적으로 높으면 파일이 업로드되고 있지 않거나 UDCA에서 충분히 빠르게 업로드할 수 없음을 나타냅니다. 이 값은 60초마다 계산되며 UDCA의 상태를 실시간으로 반영하지는 않습니다.
`/udca/server/total_latencies`	`dataset`	생성 중인 데이터 파일과 업로드된 데이터 파일 사이의 시간 간격(초)입니다. 버킷은 100밀리초, 250밀리초, 500밀리초, 1초, 2초, 4초, 8초, 16초, 32초, 64초입니다. 파일 생성 시간에서 성공적인 업로드 시간까지의 총 지연 시간에 대한 히스토그램입니다.
`/udca/server/upload_latencies`	`dataset`	UDCA가 데이터 파일 업로드에 소비한 총 시간(초)입니다. 버킷은 100밀리초, 250밀리초, 500밀리초, 1초, 2초, 4초, 8초, 16초, 32초, 64초입니다. 측정항목은 모든 업스트림 호출을 포함한 총 업로드 지연 시간에 대한 히스토그램을 표시합니다.
`/udca/upstream/http_error_count`	`service` `dataset` `response_code`	UDCA에 발생한 HTTP 오류의 총 개수입니다. 이 측정항목은 UDCA 외부 종속 항목의 어떤 부분이 실패했는지와 그 이유를 확인하는 데 유용합니다. 이러한 오류는 다양한 서비스(`getDataLocation`, `Cloud storage`, `Token generator`) 및 다양한 응답 코드가 있는 다양한 데이터 세트(예: `api` 및 `trace`)에서 발생할 수 있습니다.
`/udca/upstream/http_latencies`	`service` `dataset`	서비스의 업스트림 지연 시간(초)입니다. 버킷은 100밀리초, 250밀리초, 500밀리초, 1초, 2초, 4초, 8초, 16초, 32초, 64초입니다. 업스트림 서비스의 지연 시간 히스토그램입니다.
`/udca/upstream/uploaded_file_sizes`	`dataset`	Apigee 서비스에 업로드되는 파일 크기(단위: 바이트)입니다. 버킷은 1KB, 10KB, 100KB, 1MB, 10MB, 100MB, 1GB가 됩니다. 데이터 세트, 조직, 환경별 파일 크기 히스토그램입니다.
`/udca/upstream/uploaded_file_count`	`dataset`	UDCA가 Apigee 서비스에 업로드한 파일 수입니다. 다음 사항을 참고하세요. `event` 데이터 세트 값은 계속 증가해야 합니다. 조직/환경에 지속적인 트래픽이 있으면 `api` 데이터 세트 값은 계속 증가해야 합니다. Apigee 추적 도구를 사용하여 요청을 디버깅하거나 검사하면 `trace` 데이터 세트 값은 증가해야 합니다.
`/udca/disk/used_bytes`	`dataset` `state`	데이터 수집 포드의 디스크에 있는 데이터 파일이 바이트 단위로 차지하는 공간입니다. 시간 경과에 따른 이 값의 증가: `ready_to_upload`는 에이전트가 뒤쳐진 것을 의미합니다. `failed`는 파일이 디스크에 쌓이면서 업로드되지 않음을 의미합니다. 이 값은 60초마다 계산됩니다.
`/udca/server/pruned_file_count`	`dataset` `state`	TTL(Time To Life)이 설정된 기준점을 초과하여 삭제된 파일 수입니다. 데이터 세트에는 API, trace 등이 포함될 수 있으며 상태는 `UPLOADED`, `FAILED`, `DISCARDED`일 수 있습니다.
`/udca/server/retry_cache_size`	`dataset`	UDCA가 업로드를 다시 시도하는 데이터 세트별 파일 수입니다. UDCA는 파일마다 3번씩 다시 시도한 후 파일을 `/failed` 하위 디렉터리로 이동하고 이 캐시에서 삭제합니다. 3회 재시도 후 파일이 `/failed` 하위 디렉터리로 이동될 때 시간이 지남에 따라 이 값이 증가하면 캐시가 삭제되지 않습니다.

Cassandra 측정항목

Prometheus 서비스는 다른 하이브리드 서비스와 마찬가지로 Cassandra의 측정항목을 측정항목 수집에 설명된 대로 수집하고 처리합니다.

다음 표에서는 Prometheus가 Cassandra 측정항목 데이터에 사용하는 측정항목과 라벨을 설명합니다. 이러한 라벨은 측정항목 로그 항목에 사용됩니다.

측정항목 이름(도메인 제외)	라벨	사용
`/cassandra/process_max_fds`		열린 파일 설명자의 최대 개수입니다.
`/cassandra/process_open_fds`		열린 파일 설명자입니다.
`/cassandra/jvm_memory_pool_bytes_max`	`pool`	풀의 JVM 최대 메모리 사용량입니다.
`/cassandra/jvm_memory_pool_bytes_init`	`pol`	풀의 JVM 초기 메모리 사용량입니다.
`/cassandra/jvm_memory_bytes_max`	`area`	JVM 힙 최대 메모리 사용량입니다.
`/cassandra/process_cpu_seconds_total`		사용자 및 시스템 CPU 시간(초)입니다.
`/cassandra/jvm_memory_bytes_used`	`area`	JVM 힙 메모리 사용량입니다.
`/cassandra/compaction_pendingtasks`	`unit`	Cassandra sstables를 위한 뛰어난 압축 자세한 내용은 압축을 참조하세요.
`/cassandra/jvm_memory_bytes_init`	`area`	JVM 힙 초기 메모리 사용량입니다.
`/cassandra/jvm_memory_pool_bytes_used`	`pool`	하드웨어 풀 메모리 사용량입니다.
`/cassandra/jvm_memory_pool_bytes_committed`	`pool`	JVM 풀 약정 메모리 사용량입니다.
`/cassandra/clientrequest_latency`	`scope` `unit`	75번째 백분위수 범위의 읽기 요청 지연 시간(마이크로초)입니다.
`/cassandra/jvm_memory_bytes_committed`	`area`	JVM 힙 약정 메모리 사용량입니다.