측정항목 보기

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

Cloud 운영 정보

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

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

Hybrid 측정항목을 Cloud 운영으로 전송하려면 먼저 측정항목 수집을 사용 설정해야 합니다. 이 절차의 측정항목 수집 구성을 참조하세요.

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

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

apigee.googleapis.com/

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

apigee.googleapis.com/proxyv2/request_count

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

측정항목 보기

다음 예시에서는 Cloud 운영의 측정항목을 보는 방법을 보여줍니다.
  1. 브라우저에서 측정 항목 탐색기 모니터링을 엽니다. 또는 이미 Cloud 운영 콘솔에 있으면 측정항목 탐색기를 선택합니다.
  2. 리소스 유형 및 측정항목 찾기에서 살펴볼 측정항목을 찾아 선택합니다. 사용 가능한 측정항목에 나열된 특정 측정항목을 선택하거나 측정항목을 검색합니다.

  3. 원하는 측정항목을 선택합니다.
  4. 필터를 적용합니다. 각 측정항목의 필터 선택사항은 사용 가능한 측정항목에 나열되어 있습니다.
  5. Cloud 운영에서 선택한 측정항목의 차트를 표시합니다.
  6. 저장을 클릭합니다.

대시보드 만들기

대시보드는 중요한 측정항목 데이터를 보고 분석할 수 있는 한 가지 방법입니다. Cloud 운영은 사용하는 리소스와 서비스의 사전 정의된 대시보드를 제공하며 커스텀 대시보드도 만들 수 있습니다.

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

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

  1. 브라우저에서 Monitoring 측정항목 탐색기를 열고 대시보드를 선택합니다.
  2. +대시보드 만들기를 선택합니다.
  3. 대시보드 이름을 지정하십시오. 예시: 하이브리드 프록시 요청 트래픽
  4. 확인을 클릭합니다.
  5. 대시보드에 추가하려는 각 차트에 대해 다음 단계를 따르세요.

    1. 대시보드에서 차트 추가를 선택합니다.
    2. 측정항목 보기에 설명된 대로 원하는 측정항목을 선택합니다.
    3. 대화상자를 완성해 차트를 정의합니다.
    4. 저장을 클릭합니다. Cloud 운영에서 선택한 측정항목의 데이터를 표시합니다.

사용 가능한 측정항목

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

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

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

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

측정항목 이름 라벨 사용
/proxyv2/request_count method 수신된 API 프록시 요청의 총 개수입니다.
/proxyv2/response_count method response_code 수신된 API 프록시 응답의 총 개수입니다.
/proxyv2/latencies_percentile method 요청에 대한 모든 API 정책 응답의 백분위수입니다.
/targetv2/request_count method

target_type

target_endpoint

프록시의 대상으로 전송된 요청의 총 개수입니다.
/targetv2/response_count method

response_code

target_type

target_endpoint

프록시 대상에서 수신된 응답의 총 개수입니다.
/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-synchronizerupstream/request_count는 컨트롤 플레인에 대해 apigee-synchronizer가 수행한 요청을 나타내는 측정항목입니다.

/upstream/response_count method

response_code

type

서버 애플리케이션이 업스트림 애플리케이션에서 수신한 응답 수입니다.

예를 들어 apigee-synchronizer의 컨트롤 플레인은 업스트림입니다. 따라서 apigee-synchronizerupstream/response_countapigee-synchronizer가 컨트롤 플레인에서 수신한 요청을 나타내는 측정항목입니다.

/upstream/latencies method

response_code
type

업스트림 서버 애플리케이션에서 발생하는 지연 시간(밀리초)입니다.

예를 들어 apigee-synchronizer의 컨트롤 플레인은 업스트림입니다. 따라서 apigee-synchronizerupstream/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) 및 다양한 응답 코드가 있는 다양한 데이터 세트(예: apitrace)에서 발생할 수 있습니다.

/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 도구를 사용하여 요청을 디버깅하거나 검사하면 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 힙 약정 메모리 사용량입니다.

Cassandra 측정항목 작업

Apigee는 다음 측정항목을 Cassandra 데이터베이스를 모니터링하는 데 중요한 측정항목으로 사용합니다.

  • Cassandra 요청 비율: Cassandra 읽기 및 쓰기 요청 비율을 모니터링하려면 이 측정항목을 사용합니다.
    측정항목: apigee.googleapis.com/cassandra/clientrequest_latency
    리소스 라벨: project_id, location, cluster_name, namespace_name, pod_name, container_name
    측정항목 라벨: scope, unit

    이러한 라벨을 사용하여 특정 리소스를 필터링하거나 그룹화합니다.

    cassandra 읽기 요청 비율을 모니터링하려면 다음 필터를 적용합니다.

    필터: metric.scope == 'Read'
    metric.unit == 'OneMinuteRate'

    cassandra 쓰기 요청 비율을 모니터링하려면 다음 필터를 적용합니다.

    필터: metric.scope == 'Write'
    metric.unit == 'OneMinuteRate'
  • Cassandra 요청 지연 시간: Cassandra 읽기 및 쓰기 요청 지연 시간을 모니터링하려면 이 측정항목을 사용합니다. 이 측정항목은 요청 비율과 동일한 측정항목이며, 다른 필터가 적용된 apigee.googleapis.com/cassandra/clientrequest_latency입니다.

    cassandra 읽기 요청 지연 시간을 모니터링하려면 다음 필터를 적용합니다.

    필터: metric.scope == 'Read'
    metric.unit == '99thPercentile' 또는 '95thPercentile' 또는 '75thPercentile'

    Cassandra 쓰기 요청 지연 시간을 모니터링하려면 다음 필터를 적용합니다.

    필터: metric.scope == 'Write'
    metric.unit == '99thPercentile' 또는 '95thPercentile' 또는 '75thPercentile'
  • Cassandra 포드 CPU 요청 사용률
    측정항목: kubernetes.io/container/cpu/request_utilization (GKE)
    kubernetes.io/anthos/container/cpu/request_utilization (Anthos)
    리소스 라벨: project_id, location, cluster_name, namespace_name, pod_name, container_name

    이러한 라벨을 사용하여 특정 리소스를 필터링하거나 그룹화합니다.

  • Cassandra 데이터 볼륨 사용률
    측정항목: kubernetes.io/pod/volume/utilization (GKE)
    kubernetes.io/anthos/pod/volume/utilization (Anthos)
    리소스 라벨: project_id, location, cluster_name, namespace_name, pod_name
    측정항목 라벨: volume_name

    이러한 라벨을 사용하여 특정 리소스를 필터링하거나 그룹화합니다.

Cassandra 클러스터 확장 권장사항

다음 가이드라인은 Cassandra 클러스터 확장 결정을 위해 권장되는 클러스터 역할을 수행할 수 있습니다. 일반적으로 읽기 또는 쓰기 요청에 99번째 백분위수 지연 시간이 일관되게 표시되거나, 지연 시간이 지속적으로 증가하는 추세이고, CPU 요청 사용량 급증에서 해당 급증이 확인되고 읽기 또는 쓰기 요청 비율이 표시되면 Cassandra 클러스터의 사용량이 높은 것으로 간주될 수 있습니다. 이 경우에는 클러스터를 확장하는 것이 좋습니다. 자세한 내용은 Cassandra 확장을 참조하세요.

측정항목기준트리거 기간
kubernetes.io/pod/volume/utilization85%5분
kubernetes.io/container/cpu/request_utilization85%3분
Read request Latency 99thPercentile5초3분
Write request Latency 99thPercentile5초3분