이 주제에서는 Cloud 운영 대시보드에서 Apigee Hybrid 측정항목을 보는 방법을 설명합니다.
Cloud 운영 정보
측정항목, 대시보드, Cloud 운영에 대한 자세한 내용은 다음을 참조하세요.
하이브리드 측정항목 사용 설정
Hybrid 측정항목을 Cloud 운영으로 전송하려면 먼저 측정항목 수집을 사용 설정해야 합니다. 이 절차의 측정항목 수집 구성을 참조하세요.
하이브리드 측정항목 이름 및 라벨 정보
사용 설정하면 Hybird에서 Cloud 운영 측정항목을 자동으로 채웁니다. 하이브리드에서 생성된 측정항목의 도메인 이름 프리픽스는 다음과 같습니다.
apigee.googleapis.com/
예를 들어 /proxy/request_count 측정항목에는 API 프록시가 수신한 요청 총수가 포함됩니다. 따라서 Cloud 운영의 측정항목 이름은 다음과 같습니다.
apigee.googleapis.com/proxy/request_count
Cloud 운영을 사용하면 라벨을 기준으로 측정항목 데이터를 필터링하고 그룹화할 수 있습니다. 일부 라벨은 사전 정의되며 다른 라벨은 하이브리드에 의해 명시적으로 추가됩니다. 아래의 사용 가능한 측정항목 섹션에는 사용 가능한 모든 하이브리드 측정항목과 필터링 및 그룹화에 사용할 수 있도록 측정항목에 특별히 추가된 라벨이 나열됩니다.
측정항목 보기
다음 예시에서는 Cloud 운영의 측정항목을 보는 방법을 보여줍니다.- 브라우저에서 측정 항목 탐색기 모니터링을 엽니다. 또는 이미 Cloud 운영 콘솔에 있으면 측정항목 탐색기를 선택합니다.
리소스 유형 및 측정항목 찾기에서 살펴볼 측정항목을 찾아 선택합니다. 사용 가능한 측정항목에 나열된 특정 측정항목을 선택하거나 측정항목을 검색합니다.
- 원하는 측정항목을 선택합니다.
- 필터를 적용합니다. 각 측정항목의 필터 선택사항은 사용 가능한 측정항목에 나열되어 있습니다.
- Cloud 운영에서 선택한 측정항목의 차트를 표시합니다.
- 저장을 클릭합니다.
대시보드 만들기
대시보드는 중요한 측정항목 데이터를 보고 분석할 수 있는 한 가지 방법입니다. Cloud 운영은 사용하는 리소스와 서비스의 사전 정의된 대시보드를 제공하며 커스텀 대시보드도 만들 수 있습니다.
차트를 사용하여 커스텀 대시보드에 Apigee 측정항목을 표시합니다. 커스텀 대시보드를 사용하면 표시된 차트와 구성을 완벽하게 제어할 수 있습니다. 차트 만들기에 대한 자세한 내용은 차트 만들기를 참조하세요.
다음 예시에서는 Cloud 운영에 대시보드를 만든 후 차트를 추가하여 측정항목 데이터를 보는 방법을 보여줍니다.
- 브라우저에서 Monitoring 측정항목 탐색기를 열고 대시보드를 선택합니다.
- +대시보드 만들기를 선택합니다.
- 대시보드 이름을 지정하십시오. 예시: 하이브리드 프록시 요청 트래픽
- 확인을 클릭합니다.
대시보드에 추가하려는 각 차트에 대해 다음 단계를 따르세요.
- 대시보드에서 차트 추가를 선택합니다.
- 측정항목 보기에 설명된 대로 원하는 측정항목을 선택합니다.
- 대화상자를 완성해 차트를 정의합니다.
- 저장을 클릭합니다. Cloud 운영에서 선택한 측정항목의 데이터를 표시합니다.
사용 가능한 측정항목
다음 표에는 프록시 트래픽 분석용 측정항목이 나열되어 있습니다. 각 Apigee 측정항목에 대한 자세한 내용은 Google Cloud 측정항목을 참고하세요.
프록시, 대상 서버 트래픽 측정항목
Open Telemetry는 측정항목 수집에 설명된 대로 프록시, 대상, 서버 트래픽의 측정항목을 수집하고 처리합니다.
다음 표에서는 OpenTelemetry 수집기에서 사용하는 측정항목을 설명합니다.
| 측정항목 이름 | 사용 |
|---|---|
/proxy/request_count |
마지막 샘플이 기록된 이후 Apigee 프록시에 대한 요청 수입니다. |
/proxy/response_count |
Apigee API 프록시에서 전송한 응답 수입니다. |
/proxy/latencies |
Apigee 프록시에서 요청을 수신한 시간부터 Apigee 프록시에서 클라이언트로 응답을 전송한 시간까지 계산되는 지연 시간의 분포입니다. |
/proxyv2/request_count |
수신된 API 프록시 요청의 총 개수입니다. |
/proxyv2/response_count |
수신된 API 프록시 응답의 총 개수입니다. |
/proxyv2/latencies_percentile |
요청에 대한 모든 API 정책 응답의 백분위수입니다. |
/target/request_count |
마지막 샘플이 기록된 이후 Apigee 대상으로 전송된 요청 수입니다. |
/target/response_count |
마지막 샘플이 기록된 이후 Apigee 대상에서 수신된 응답 수입니다. |
/target/latencies |
요청이 Apigee 대상으로 전송된 시간부터 Apigee 프록시에서 응답을 수신한 시간까지 계산되는 지연 시간의 분포입니다. 시간에는 Apigee API 프록시 오버헤드가 포함되지 않습니다. |
/targetv2/request_count |
프록시의 대상으로 전송된 요청의 총 개수입니다. |
/targetv2/response_count |
프록시 대상에서 수신된 응답의 총 개수입니다. |
/server/fault_count |
서버 애플리케이션 오류의 총 개수입니다. 예를 들어 애플리케이션은 |
/server/nio |
이 측정항목은 state 라벨로 필터링하여 다양한 라벨의 세부정보를 가져올 수 있는 게이지 측정항목입니다. 값은 다양한 시스템 및 I/O 작업을 나타냅니다. accepted, accepted_total, close_failed, close_success, conn_pending, connected, connected_total, max_conn, timeouts와 같은 라벨은 소켓 및 연결 작업과 관련이 있습니다. 나머지 라벨은 다른 시스템 작업과 관련이 있습니다. |
/server/num_threads |
서버의 활성 비데몬 스레드 수입니다. |
/server/request_count |
서버 애플리케이션에서 수신한 요청의 총 개수입니다. 예를 들어 애플리케이션은 |
/server/response_count |
서버 애플리케이션에서 보낸 응답의 총 개수입니다. 예를 들어 애플리케이션은 |
/server/latencies |
지연 시간은 서버 애플리케이션으로 인한 지연 시간(밀리초)입니다. 예를 들어 애플리케이션은 |
/upstream/request_count |
서버 애플리케이션에서 업스트림 애플리케이션으로 전송한 요청 수입니다. 예를 들어 |
/upstream/response_count |
서버 애플리케이션이 업스트림 애플리케이션에서 수신한 응답 수입니다. 예를 들어 |
/upstream/latencies |
업스트림 서버 애플리케이션에서 발생하는 지연 시간(밀리초)입니다. 예를 들어 |
UDCA 측정항목
Open Telemetry는 다른 하이브리드 서비스와 마찬가지로 UDCA 서비스에 대한 측정항목을 측정항목 수집에 설명된 대로 수집하고 처리합니다.
다음 표에서는 OpenTelemetry 수집기가 UDCA 측정항목 데이터에 사용하는 측정항목을 설명합니다.
state
state
| 측정항목 이름 | 사용 |
|---|---|
/udca/server/local_file_oldest_ts |
데이터 세트에서 가장 오래된 파일에 대한 Unix Epoch의 시작 이후의 타임스탬프(밀리초)입니다. 이 값은 60초마다 계산되며 실시간으로 상태를 반영하지는 않습니다. UDCA가 최신 상태이며 이 측정항목을 계산할 때 업로드 대기 중인 파일이 없는 경우 이 값은 0입니다. 이 값이 계속 증가하면 기존 파일은 여전히 디스크에 있습니다. |
/udca/server/local_file_latest_ts |
디스크의 최신 파일에 대한 Unix Epoch의 시작 이후의 타임스탬프(밀리초)입니다. 이 값은 60초마다 계산되며 실시간으로 상태를 반영하지는 않습니다. UDCA가 최신 상태이며 이 측정항목을 계산할 때 업로드 대기 중인 파일이 없는 경우 이 값은 0입니다. |
/udca/server/local_file_count |
데이터 수집 포드에 있는 디스크의 파일 수입니다. 이상적으로 값은 0에 가깝습니다. 값이 지속적으로 높으면 파일이 업로드되고 있지 않거나 UDCA에서 충분히 빠르게 업로드할 수 없음을 나타냅니다. 이 값은 60초마다 계산되며 UDCA의 상태를 실시간으로 반영하지는 않습니다. |
/udca/server/total_latencies |
생성 중인 데이터 파일과 업로드된 데이터 파일 사이의 시간 간격(초)입니다. 버킷은 100밀리초, 250밀리초, 500밀리초, 1초, 2초, 4초, 8초, 16초, 32초, 64초입니다. 파일 생성 시간에서 성공적인 업로드 시간까지의 총 지연 시간에 대한 히스토그램입니다. |
/udca/server/upload_latencies |
UDCA가 데이터 파일 업로드에 소비한 총 시간(초)입니다. 버킷은 100밀리초, 250밀리초, 500밀리초, 1초, 2초, 4초, 8초, 16초, 32초, 64초입니다. 측정항목은 모든 업스트림 호출을 포함한 총 업로드 지연 시간에 대한 히스토그램을 표시합니다. |
/udca/upstream/http_error_count |
UDCA에 발생한 HTTP 오류의 총 개수입니다. 이 측정항목은 UDCA 외부 종속 항목의 어떤 부분이 실패했는지와 그 이유를 확인하는 데 유용합니다. 이러한 오류는 다양한 서비스(
|
/udca/upstream/http_latencies |
서비스의 업스트림 지연 시간(초)입니다. 버킷은 100밀리초, 250밀리초, 500밀리초, 1초, 2초, 4초, 8초, 16초, 32초, 64초입니다. 업스트림 서비스의 지연 시간 히스토그램입니다. |
/udca/upstream/uploaded_file_sizes |
Apigee 서비스에 업로드되는 파일 크기(단위: 바이트)입니다. 버킷은 1KB, 10KB, 100KB, 1MB, 10MB, 100MB, 1GB가 됩니다. 데이터 세트, 조직, 환경별 파일 크기 히스토그램입니다. |
/udca/upstream/uploaded_file_count |
UDCA가 Apigee 서비스에 업로드한 파일 수입니다. 다음 사항을 참고하세요.
|
/udca/disk/used_bytes |
데이터 수집 포드의 디스크에 있는 데이터 파일이 바이트 단위로 차지하는 공간입니다. 시간 경과에 따른 이 값의 증가:
|
/udca/server/pruned_file_count |
TTL(Time To Life)이 설정된 기준점을 초과하여 삭제된 파일 수입니다.
데이터 세트에는 API, trace 등이 포함될 수 있으며 상태는 UPLOADED, FAILED, DISCARDED일 수 있습니다.
|
/udca/server/retry_cache_size |
UDCA가 업로드를 다시 시도하는 데이터 세트별 파일 수입니다. UDCA는 파일마다 3번씩 다시 시도한 후 파일을 |
Cassandra 측정항목
Open Telemetry는 다른 하이브리드 서비스와 마찬가지로 Cassandra의 측정항목을 측정항목 수집에 설명된 대로 수집하고 처리합니다.
다음 표에서는 OpenTelemetry 수집기가 Cassandra 측정항목 데이터에 사용하는 측정항목을 설명합니다.
| 측정항목 이름(도메인 제외) | 사용 |
|---|---|
/cassandra/process_max_fds |
열린 파일 설명자의 최대 개수입니다. |
/cassandra/process_open_fds |
열린 파일 설명자입니다. |
/cassandra/jvm_memory_pool_bytes_max |
풀의 JVM 최대 메모리 사용량입니다. |
/cassandra/jvm_memory_pool_bytes_init |
풀의 JVM 초기 메모리 사용량입니다. |
/cassandra/jvm_memory_bytes_max |
JVM 힙 최대 메모리 사용량입니다. |
/cassandra/process_cpu_seconds_total |
사용자 및 시스템 CPU 시간(초)입니다. |
/cassandra/jvm_memory_bytes_used |
JVM 힙 메모리 사용량입니다. |
/cassandra/compaction_pendingtasks |
Cassandra sstables를 위한 뛰어난 압축 자세한 내용은 압축을 참조하세요. |
/cassandra/jvm_memory_bytes_init |
JVM 힙 초기 메모리 사용량입니다. |
/cassandra/jvm_memory_pool_bytes_used |
하드웨어 풀 메모리 사용량입니다. |
/cassandra/jvm_memory_pool_bytes_committed |
JVM 풀 약정 메모리 사용량입니다. |
/cassandra/clientrequest_latency |
75번째 백분위수 범위의 읽기 요청 지연 시간(마이크로초)입니다. |
/cassandra/jvm_memory_bytes_committed |
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 on Google Cloud)
kubernetes.io/anthos/container/cpu/request_utilization (Google Distributed Cloud)리소스 라벨: project_id,location,cluster_name,namespace_name,pod_name,container_name이러한 라벨을 사용하여 특정 리소스를 필터링하거나 그룹화합니다.
- Cassandra 데이터 볼륨 사용률
측정항목: kubernetes.io/pod/volume/utilization (GKE on Google Cloud)
kubernetes.io/anthos/pod/volume/utilization (Google Distributed Cloud)리소스 라벨: project_id,location,cluster_name,namespace_name,pod_name측정항목 라벨: volume_name이러한 라벨을 사용하여 특정 리소스를 필터링하거나 그룹화합니다.
Cassandra 클러스터 확장 권장사항
다음 가이드라인은 Cassandra 클러스터 확장 결정을 위해 권장되는 클러스터 역할을 수행할 수 있습니다. 일반적으로 읽기 또는 쓰기 요청에 99번째 백분위수 지연 시간이 일관되게 표시되거나, 지연 시간이 지속적으로 증가하는 추세이고, CPU 요청 사용량 급증에서 해당 급증이 확인되고 읽기 또는 쓰기 요청 비율이 표시되면 Cassandra 클러스터의 사용량이 높은 것으로 간주될 수 있습니다. 이 경우에는 클러스터를 확장하는 것이 좋습니다. 자세한 내용은 Cassandra 확장을 참조하세요.
| 측정항목 | 기준 | 트리거 기간 |
|---|---|---|
kubernetes.io/pod/volume/utilization | 85% | 5분 |
kubernetes.io/container/cpu/request_utilization | 85% | 3분 |
Read request Latency 99thPercentile | 5초 | 3분 |
Write request Latency 99thPercentile | 5초 | 3분 |