이 문서에는 이 서비스에 대한 모든 모니터링 참조 정보가 포함되어 있습니다.
지표
이 섹션에는 이 서비스에 대해 자동으로 모은 플랫폼 메트릭이 모두 나열되어 있습니다. 이러한 메트릭은 Azure Monitor에서 지원되는 모든 플랫폼 메트릭의 전역 목록의 일부이기도 합니다.
메트릭 보존에 관한 자세한 내용은 Azure Monitor 메트릭 개요를 참조하세요.
Microsoft.Cache/redisEnterprise에 대해 지원되는 메트릭에 대한 자세한 내용 및 정보는 다음 섹션을 참조하세요.
Microsoft.Cache/redisEnterprise에 대해 지원되는 메트릭
다음 표에서는 Microsoft.Cache/redisEnterprise 리소스 종류에 사용할 수 있는 메트릭을 나열합니다.
- 모든 테이블에 모든 열이 있는 것은 아닙니다.
- 일부 열은 페이지의 보기 영역 밖에 있을 수 있습니다. 사용 가능한 모든 열을 보려면 테이블 확장을 선택합니다.
테이블 제목
- 범주 - 메트릭 그룹 또는 분류입니다.
- 메트릭 - Azure Portal에 표시되는 메트릭 표시 이름입니다.
- REST API의 이름 - REST API에서 참조되는 메트릭 이름입니다.
- 단위 - 측정 단위입니다.
- 집계 - 기본 집계 형식입니다. 유효한 값은 평균(Avg), 최소(Min), 최대(Max), 합계(Sum), 개수입니다.
- 크기 - 해당 메트릭에 사용할 수 있는 크기입니다.
-
시간 조직 - 메트릭이 샘플링되는 간격입니다. 예를 들어,
PT1M은 메트릭이 1분마다,PT30M은 30분마다,PT1H는 1시간마다 샘플링됨을 나타냅니다. - DS 내보내기- 진단 설정을 통해 메트릭을 Azure Monitor 로그로 내보낼 수 있는지 여부를 나타냅니다. 메트릭 내보내기에 대한 자세한 내용은 Azure Monitor의 진단 설정 생성을 참조하세요.
| 측정단위 | REST API의 이름 | 고급 플랫폼 메트릭 | 단위 | 집계 | 치수 | 시간 입자 | DS 데이터 내보내기 |
|---|---|---|---|---|---|---|---|
|
캐시 적중 수 성공한 키 조회의 수. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
cachehits |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
캐시 대기 시간 마이크로초(미리 보기) 캐시 대기 시간(마이크로초)입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
cacheLatency |
아니오 | 수량 | 평균 | InstanceId |
PT1M | 예 |
|
캐시 누락 실패한 키 조회의 수. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
cachemisses |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
캐시 읽기 캐시에서 읽은 초당 메가바이트(MB/s) 단위의 데이터 양. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
cacheRead |
아니오 | 초당 바이트 | 최대 | InstanceId |
PT1M | 예 |
|
캐시 쓰기 캐시에 기록된 데이터의 양(초당 메가바이트)(MB/s)입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
cacheWrite |
아니오 | 초당 바이트 | 최대 | InstanceId |
PT1M | 예 |
|
연결된 클라이언트 캐시에 대한 클라이언트 연결 수입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
connectedclients |
아니오 | 수량 | 최대 | InstanceId |
PT1M | 예 |
|
제거된 키 캐시에서 제거된 항목 수입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
evictedkeys |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
만료된 키 캐시에서 만료된 항목 수. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
expiredkeys |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
지리적 복제 상태 양호 활성 지역 복제 그룹의 지역 복제 상태입니다. 0은 비정상이고 1은 정상을 나타냅니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
geoReplicationHealthy |
아니오 | 수량 | 최대 | <없음> | PT1M | 예 |
|
가져오기 캐시에서의 가져오기 작업 수. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
getcommands |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
초당 작업 캐시에서 실행되는 초당 즉각적인 작업 수입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
operationsPerSecond |
아니오 | 수량 | 최대 | <없음> | PT1M | 예 |
|
중앙 처리 장치(CPU) Azure Redis Cache 서버의 CPU 사용률(백분율)입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
percentProcessorTime |
아니오 | 백분율 | 최대 | InstanceId |
PT1M | 예 |
|
서버 부하 Redis 서버가 메시지를 유휴 상태로 기다리지 않고 처리 중인 주기의 비율을 나타냅니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
serverLoad |
아니오 | 백분율 | 최대 | <없음> | PT1M | 예 |
|
설정 캐시에 대한 설정 작업의 수입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
setcommands |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
총 작업 캐시 서버에서 처리한 총 명령 수입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
totalcommandsprocessed |
아니오 | 수량 | 합계(총합) | <없음> | PT1M | 예 |
|
총 키 캐시의 총 항목 수입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
totalkeys |
아니오 | 수량 | 최대 | <없음> | PT1M | 예 |
|
사용된 메모리 캐시의 키/값 쌍에 사용되는 캐시 메모리 양(MB)입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
usedmemory |
아니오 | 바이트 | 최대 | <없음> | PT1M | 예 |
|
사용된 메모리 비율 키/값 쌍에 사용되는 캐시 메모리의 백분율입니다. 자세한 내용은 https://aka.ms/redis/enterprise/metrics를 참조하세요. |
usedmemorypercentage |
아니오 | 백분율 | 최대 | <없음> | PT1M | 예 |
Azure Managed Redis 메트릭에 대한 세부 정보
다음 섹션에서는 Microsoft에서 지원되는 Azure Monitor 지표에 대한 추가 정보와 해석 지침을 제공합니다. 캐시/레디스엔터프라이즈. 단위 및 집계 유형의 전체 메트릭 목록은 지원 메트릭 표를 참조하세요.
클러스터 수준 지표에 대한 세부 정보
다음 표는 각 클러스터 수준 지표에 대한 기본 Redis V1 Prometheus 소스 지표와 추가 해석 지침을 제공합니다. 소스 메트릭 정의는 Redis Enterprise Prometheus v1 메트릭 참고 자료를 참조하세요.
| 측정단위 | 출처 및 주석 |
|---|---|
| 캐시 지연 | 지정된 보고 간격 동안 캐시 노드의 엔드포인트에서 처리되는 요청의 평균 대기 시간입니다. 이 지표는 밀리초 단위로 측정되며 V1 프로메테우스 지표에서 node_avg_latency 가져옵니다. 이 메트릭은 캐시에 활성 트래픽이 있는 경우에만 보고됩니다. |
| 캐시 적수 | 성공한 키 조회 비율은 초당 히트로 표현됩니다. V1 프로메테우스 지표에서 출처 bdb_read_hits . 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. |
| 캐시 누락 | 실패한 키 조회 비율은 초당 미스로 표현됩니다. V1 프로메테우스 지표에서 출처 bdb_read_misses_max . 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. 캐시 누락이 반드시 캐시에 문제가 있음을 의미하는 것은 아닙니다. 예를 들어 캐시 배제 프로그래밍 패턴을 사용하는 경우 애플리케이션은 먼저 캐시에서 항목을 찾습니다. 항목이 캐시에 없으면(캐시 누락) 데이터베이스에서 항목을 검색하고 다음 검색을 위해 캐시에 항목을 추가합니다. 캐시 누락은 캐시 배제 프로그래밍 패턴의 일반적인 동작입니다. 캐시 누락 수가 예상보다 높은 경우 캐시를 채우고 캐시에서 읽는 애플리케이션 논리를 검사합니다. 메모리 압력으로 인해 캐시에서 항목이 제거되는 경우 일부 캐시 누락이 있을 수 있지만 메모리 압력을 모니터링하는 더 나은 메트릭이 될 수 있습니다 Used Memory or Evicted Keys. |
| 캐시 읽기 | 캐시 노드로 들어오는 네트워크 트래픽의 바이트 속도를 초당 바이트로 나타냅니다. 이 값은 V1 프로메테우스 지표에서 node_ingress_bytes_max 얻은 것입니다. 서버 쪽 네트워크 대역폭 제한에 대한 경고를 설정하려면 이 캐시 읽기 카운터를 사용하여 만듭니다. 다양한 캐시 가격 책정 계층 및 크기에 대해 관찰된 대역폭 제한은 이 테이블을 참조하세요. 이는 비트당 바이트 단위로 표현되는 속도 지표입니다. |
| 캐시 쓰기 | 캐시 노드에서 나가는 네트워크 트래픽의 바이트 단위 속도를 나타냅니다. 이 값은 V1 프로메테우스 지표에서 node_egress_bytes_max 얻은 것입니다. 이는 비트당 바이트 단위로 표현되는 속도 지표입니다. |
| 연결된 클라이언트 | 노드 내 엔드포인트에 연결된 클라이언트 수를 세는 V1 Prometheus 메트릭에서 node_conns 가져온 것입니다. 연결 제한에 도달하면 나중에 캐시에 연결하려고 시도하면 실패합니다. 활성 클라이언트 애플리케이션이 없는 경우에도 내부 프로세스 및 연결로 인해 연결된 클라이언트 인스턴스가 여전히 몇 개 있을 수 있습니다. |
| CPU (중앙 처리 장치) | V1 Prometheus 지표에서 파 node_cpu_idle 생되었으며, 이는 구간 동안 평균 CPU 유휴 시간 구간(0에서 1의 값에 100을 곱해 백분율을 표현)을 나타내며, CPU 바쁜 시간을 반영하기 위해 역전됩니다. CPU 메트릭에는 엄격하게 Redis 서버 프로세스가 아닌 맬웨어 방지와 같은 백그라운드 프로세스가 포함되어 있으므로 Redis 워크로드와 독립적으로 급증할 수 있습니다. 모니터링을 위해 서버 부하 를 통해 이 메트릭을 사용하는 것이 좋습니다. 인스턴스 ID로 분할하여 인스턴스 수준 드릴다운을 지원하므로 어떤 노드가 압력을 받고 있는지 보다 세분화할 수 있습니다. |
| 제거된 키 | 초당 이퇴 횟수로 표현한 핵심 퇴거 속도입니다. V1 프로메테우스 지표에서 출처 bdb_evicted_objects . 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. |
| 만료된 키 | 키 만료율은 초당 만료 횟수로 표현됩니다. V1 프로메테우스 지표에서 출처 bdb_expired_objects . 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. |
| 지리적 복제 정상 | Active Geo-Replication 그룹의 캐시 간에 지역 복제 링크의 상태를 나타냅니다. 메트릭은 다음 두 값 중 하나를 보고합니다. 0 - 단절/건강하지 못한 상태 1 - 건강 메트릭은 지역에서 복제를 사용하도록 설정된 메모리 최적화, 분산 및 컴퓨팅 최적화 계층 캐시에서 사용할 수 있습니다. 0 값은 지역 복제의 데이터가 손실되었음을 의미하지 않습니다. 지역 기본과 지역 보조 간의 연결이 비정상임을 의미합니다. 이 메트릭은 월별 패치, 호스트 OS 업데이트, 네트워크 잘못된 구성 또는 실패한 지역 복제 링크 프로비저닝을 비롯한 여러 가지 이유로 연결이 끊어지거나 비정상 복제 상태를 나타낼 수 있습니다. Azure Managed Redis 서비스는 최신 플랫폼 기능 및 향상된 기능으로 캐시를 주기적으로 패치합니다. 이러한 업데이트 중에는 각 캐시 노드가 오프라인으로 전환되어 지역 복제 링크를 일시적으로 사용하지 않도록 설정합니다. 지역 복제 링크가 비정상인 경우 포털의 리소스 메뉴에서 진단 및 해결 문제를 사용하여 지역 주 또는 지역 보조 캐시의 패치 이벤트로 인해 발생했는지 확인합니다. 캐시의 데이터 양에 따라 패칭으로 인한 가동 중지 시간은 몇 분에서 1시간까지 걸릴 수 있습니다. 지역 복제 링크가 1시간 넘게 비정상 상태이면 지원 요청을 제출합니다. |
| 가져오기 | 읽기 연산 속도는 초당 연산으로 표현됩니다. 이 지표는 V1 Prometheus 메트릭에서 가져 bdb_read_req 왔으며, 이는 데이터베이스 내 모든 읽기 요청의 비율을 나타내며, 캐시 히트와 미스의 합과 같습니다. 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. |
| 초당 작업 | 지정된 보고 간격 동안 캐시의 모든 분할된 데이터베이스에서 초당 처리되는 총 요청 수입니다. 이 값은 V1 프로메테우스 지표에서 bdb_instantaneous_ops_per_sec 얻은 것입니다. 이는 초당 작업으로 표현되는 속도 지표입니다. |
| 서버 부하 |
서버 부하 지표는 Redis 서버가 전체 부하에 대해 자체 평가한 것입니다.
CPU 메트릭과 마찬가지로, V1 Prometheus 메트릭에서 파 node_cpu_idle 생된 것으로, 서버 사용 시간을 반영하기 위해 역전된 것입니다. 차이점은 서버 부하가 클러스터 수준에서 측정되는 반면, CPU 는 노드(인스턴스) 수준에서 측정된다는 점입니다.서버 부하가 100에 도달한다고 해서 반드시 CPU가 캐시 전체에 소진된다는 의미는 아닙니다; 이는 노드 중 하나의 CPU가 포화 상태에 가까워지고 있음을 나타낼 수 있습니다. 따라서 성능 관련 결정을 내리기 전에 서버 부하 와 노드별 CPU 지표를 모두 평가하여 여러 캐시에 데이터를 분산시키거나 확장해야 합니다. 지속적인 높은 서버 부하 는 서버 측 지연 증가와 타임아웃 예외 등 여러 부작용을 초래할 수 있습니다. 주의: Azure 관리 Redis 캐시의 경우 서버 부하가 때때로 100을 초과하는 값을 반영합니다. 성능 기반 결정을 내리기 전에 CPU 지표를 사용하거나 두 지표를 함께 평가하는 것을 권장합니다. |
| 설정 | 쓰기 연산 속도는 초당 연산으로 표현됩니다. 이 지표는 데이터베이스 내 모든 쓰기 요청 비율을 나타내는 V1 Prometheus 지표에서 bdb_write_req 가져왔습니다. 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. |
| 총 키 | V1 프로메테우스 지표에서 출처 bdb_no_of_keys .중요: 클러스터링이 활성화된 캐시의 기본 메트릭 시스템 한계로 인해, 총 키는 보고 기간 동안 최대 키의 수를 가진 샤드의 최대 키를 반환합니다. 클러스터 캐시에서 샤드 단위 키 수를 정확히 확인하려면, 차원별로 Slots (Range) 슬라이스한 샤드 레벨 샤드 키 카운트 메트릭을 사용하세요. |
| 총 작업 | 모든 연산의 속도는 초당 연산으로 표현됩니다. V1 프로메테우스 지표에서 출처 bdb_total_req . 이것은 요금 지표입니다; Azure Monitor 단위는 Count로 표시되지만, 값은 초당 속도입니다. |
| 사용된 메모리 | V1 프로메테우스 지표에서 출처 bdb_used_memory . 플래시 최적화 계층 캐시에서 이 값에는 RAM 및 플래시 메모리 사용량이 모두 포함됩니다. 이 값은 조각화를 포함하지 않습니다.고가용성을 사용하도록 설정하면 사용된 메모리 값에 주 노드와 복제본 노드의 메모리가 모두 포함됩니다. 이렇게 하면 메트릭이 예상보다 두 배 더 크게 표시될 수 있습니다. |
| 사용된 메모리 비율 | Redis Enterprise V1 Prometheus 지표에서 가져온 비율 bdb_memory_limit 로 bdb_used_memory 계산되었습니다. 이 값은 조각화를 포함하지 않습니다. |
샤드 레벨 메트릭
Azure Managed Redis는 이제 샤드 단위 지표를 제공하여 캐시 동작을 샤드별로 볼 수 있게 합니다. 이 메트릭들은 Redis V2 Prometheus 엔드포인트(redis_server_* 메트릭)에서 가져옵니다.
치수
각 샤드 레벨 메트릭은 다음과 같은 차원을 지원합니다:
| Dimension | REST API의 이름 | 설명 |
|---|---|---|
Instance ID |
InstanceId |
클러스터 내 특정 Redis 노드(VM 인스턴스)를 식별합니다. 이 차원을 사용하여 노드별 동작을 분리하고 노드 간 부하 불균형을 식별할 수 있습니다. |
Slots (Range) |
Slots |
샤드를 해시 슬롯 범위로 식별합니다. 이 차원을 이용해 샤드 간 메모리 불균형이나 키 분포 불균형을 감지하세요. |
Shard ID |
Shard |
Redis 샤드 UID를 사용한 고유 샤드 식별자. 이 차원을 함께 Slots (Range) 사용하여 Azure Monitor 데이터와 Redis 수준의 샤드 식별자를 연관시키세요. |
Shard Role |
Role |
노드의 역할: primary 또는 replica. 이 차원을 사용하여 동일한 샤드 내 주요 노드와 복제 노드 간의 메트릭을 비교하세요. |
Note
Azure Monitor REST API에서 차원별로 분할하거나 필터링할 때, 포털 표시 이름 대신 REST API 이름에 있는 값을 사용하세요. Azure Monitor REST API의 메트릭 이름과 차원 이름은 대문자 구분이 없습니다. 예를 들어, 쿼리 percentProcessorTime, PercentProcessorTime, 또는 PERCENTPROCESSORTIME 모두 동일한 결과를 반환합니다. 차원 필터 값도 마찬가지로, instanceId eq '*' 와 INSTANCEID eq '*' 는 동등하다. 이 글에서 사용한 케이싱은 가독성을 위한 관습입니다.
Important
이 지표들은 샤드 수준에서 공개됩니다. 차원별로 분할하지 않고 쿼리하면, Azure Monitor는 기본 집계 유형을 사용하여 모든 샤드에 값을 집계합니다. 대부분의 지표에서 이 교차 샤드 집계는 의미 있는 클러스터 전체 총합을 생성하지 못합니다. 정확한 샤드 분석을 위해 항상 차원별로 Slots (Range) 나누어 주세요.
샤드 레벨 메트릭에 대한 세부 정보
다음 표는 각 샤드 레벨 메트릭에 대한 Redis V2 Prometheus 소스 메트릭과 추가 해석 지침을 제공합니다. 소스 메트릭 정의는 Redis Enterprise Prometheus v2 메트릭 참고 자료를 참조하세요.
| 측정단위 | 세부 정보 |
|---|---|
| 샤드 메모리 사용 (바이트) (미리보기) | 이 샤드가 사용하는 메모리는 바이트 단위입니다. 플래시 지원 SKU에서는 DRAM과 플래시 사용 모두를 포함합니다. Redis V2 Prometheus 지표에서 redis_server_used_memory 출처를 얻었습니다. |
| 샤드 메모리 클라이언트 일반 (바이트) (미리보기) | 비복제 클라이언트의 입출력 버퍼에 사용되는 현재 메모리. Redis V2 Prometheus 지표에서 redis_server_mem_clients_normal 출처를 얻었습니다. |
| 샤드 메모리 클라이언트 복제본(바이트) (미리보기) | 복제본 클라이언트의 입출력 버퍼에 사용되는 현재 메모리. Redis V2 Prometheus 지표에서 redis_server_mem_clients_slaves 출처를 얻었습니다. |
| 샤드 키 카운트 (미리보기) | 총 키 수. Redis V2 Prometheus 지표에서 redis_server_db_keys 출처를 얻었습니다. |
| 샤드 복제 링크 업 (미리보기) | 복제본이 기본 객체와 연결되어 있는지 여부를 나타냅니다. 이 지표는 레디스 V2 프로메테우스 메트릭에서 가져 redis_server_master_link_status 온 것으로, 이는 복제 샤드에서만 출력되며, 복제본만이 주 복제 링크로 돌아가 보고할 수 있기 때문입니다. |
빅 키 지표
다음 지표들은 샤드 간 키 크기 분포를 추적하여 성능 문제를 일으키기 전에 큰 키를 식별하는 데 도움을 줍니다.
Note
빅키 메트릭은 아직 활성 지리 복제 캐시에서 지원되지 않습니다. 지오리복제 캐시에 대한 이러한 지표 지원은 추후에 제공될 예정입니다.
문자열 키(메모리 크기 기준)
| 측정단위 | 세부 정보 |
|---|---|
| 샤드 문자열 크기 128MB 미만 (미리보기) | 이 샤드에 메모리 크기가 128MB 미만인 문자열 키 수. |
Set key(요소 개수별)
| 측정단위 | 세부 정보 |
|---|---|
| 샤드가 항목을 100만 요소로 설정함 (미리보기) | 이 샤드에 100만 개 미만의 요소 세트 키 수. |
| 샤드가 아이템 1M에서 8M 요소로 설정함 (미리보기) | 이 샤드에는 100만에서 800만 요소 사이의 세트 키 수. |
| 샤드가 800만 요소 이상으로 아이템을 설정하다 (미리보기) | 이 조각에는 800만 개가 넘는 요소의 세트 키가 있습니다. |
정렬된 집합 키(요소 개수에 따라)
| 측정단위 | 세부 정보 |
|---|---|
| 샤드 정렬 항목이 100만 요소 미만으로 설정함 (미리보기) | 이 샤드에 정렬된 열쇠 수가 100만 개 미만으로 구성되어 있습니다. |
| 샤드 정렬 세트 항목 1M에서 8M 요소 (미리보기) | 이 샤드에는 100만에서 800만 요소 사이의 정렬된 세트 키의 수. |
| 샤드 정렬 세트 항목 800만 요소 (미리보기) | 이 조각에는 800만 개가 넘는 요소로 정렬된 세트 키의 수가 있습니다. |
해시 키 (필드 개수별)
| 측정단위 | 세부 정보 |
|---|---|
| 샤드가 1M 요소 미만의 항목을 해시함 (미리보기) | 이 샤드에서 필드가 100만 개 미만인 해시 키 수. |
| 샤드는 1M에서 8M 요소까지 아이템을 해시합니다 (미리보기) | 이 샤드에 있는 해시 키 수, 필드는 100만에서 800만 개 사이입니다. |
| 샤드가 800만 요소 이상의 항목을 해시합니다 (미리보기) | 이 샤드에 800만 필드가 넘는 해시 키 수. |
리스트 키(요소 수별)
| 측정단위 | 세부 정보 |
|---|---|
| 샤드가 100만 요소 이하의 항목을 나열합니다 (미리보기) | 이 샤드에 100만 개 미만의 요소만 있는 리스트 키 수. |
| 샤드가 1M에서 8M까지 항목을 나열합니다 (미리보기) | 이 샤드에 있는 리스트 키 수는 100만에서 800만 요소 사이입니다. |
| 샤드가 800만 개 이상의 요소 항목을 나열함 (미리보기) | 이 샤드에는 800만 개가 넘는 요소의 리스트 키가 있습니다. |
샤드 레벨 메트릭을 이용한 문제 해결
다음 섹션에서는 일반적인 샤드 레벨 시나리오와 이를 진단하는 방법을 설명합니다:
복제 링크 실패 식별
복제 링크 실패는 주 샤드가 연결된 복제 샤드와 복제 연결을 구축하지 못해 복제본이 더 이상 주 샤드와 동기화할 수 없을 때 발생합니다. 이 메트릭은 복제 샤드에서만 출력되는데, 이는 복제본만이 주 복제 링크로 돌아가 보고할 수 있고, 그 복제본이 현재 주 복제와 연결되어 있는지 여부를 보고하기 때문입니다. 지속적인 실패는 영향을 받는 샤드의 고가용성 보호를 제거하고, 링크가 복구되기 전에 장애 조치가 발생할 경우 데이터 손실 위험이 증가합니다. 다만, 복제 링크는 장애 조치, 샤드 마이그레이션, 확장, 유지보수 이벤트 중에 일시적으로 건강하지 못해질 수 있어 이 지표는 잡음이 클 수 있습니다. 이 때문에 이 지표에 알림을 설정할 때는 건강 저하를 나타내는 여러 데이터 포인트를 포함하는 지속적인 기간 동안만 경고하는 것이 중요합니다.
탐지 접근법:
-
샤드 복제 링크를 .로
Slots (Range)분할합니다. 어떤 샤드에서 값이 0이라면, 샤드의 복제 링크가 다운되었음을 의미합니다; 1은 올라갔다는 뜻이야. - 0 상태를 오랜 시간(예: 120분 이상) 유지하는 링크를 일시적 재연결이 아닌 지속적인 장애로 간주하세요. 일반적인 유지보수나 장애 조치 중에 짧은 하락이 발생할 수 있습니다.
- 동일한 샤드 내 샤드 메모리 사용량 과 샤 드 메모리 클라이언트 복제 본을 상관관계 분석하여 주 샤드에 대한 자원 부담이 실패와 함께 있는지 확인한다.
일반적인 원인:
- 큰 키가 큰 원인입니다. 큰 키와 컬렉션은 동기화를 느리고 비용이 많이 들게 하여 복제본을 정체시키고 결국 복제 링크를 건강하지 못한 상태로 만들 수 있습니다.
- 주 노드와 복제 노드 간의 네트워크 중단이나 높은 지연 시간.
- 주 샤드가 과부하(높은 쓰기 처리량 또는 CPU 포화 상태)로 인해 복제를 처리할 수 없습니다.
- 기본 장치에 대한 메모리 압력이 복제본을 동기화하는 데 필요한 백그라운드 작업을 방해합니다.
- 복제 백로그보다 늦어지는 느린 복제본으로 인해 반복되는 완전한 동기화 사이클이 반복됩니다.
수정:
- 지속적인 쓰기 처리량을 줄이거나 캐시를 확장하여 용량을 늘려 주 샤드가 덜 포화되도록 하세요.
- 큰 키를 식별하고 분할하는데, 이는 영향을 받은 샤드에서 복제 및 재동기화 비용이 더 많이 드는 문제를 만듭니다.
- 부하가 줄어든 후에도 연결이 계속 다운된다면, 지원 요청을 열어 플랫폼 팀이 노드 건강 상태와 내부 복제 적체를 조사할 수 있도록 하세요.
기억 불균형 식별
메모리 불균형은 일부 샤드가 다른 샤드보다 훨씬 더 많은 메모리를 사용할 때 발생하며, 이는 특정 샤드에서 퇴출되는 결과를 초래할 수 있으며, 다른 샤드는 충분한 빈 메모리를 가질 수 있습니다.
탐지 접근법:
-
분할 샤드 메모리(바이트) 사용.
Slots (Range)최대/최소 비율이 2배를 초과하면 의미 있는 불균형을 의미합니다. - 샤 드 키 수
Slots (Range)와 상관관계를 분석하여 불균형이 키가 더 많아서 인지, 특정 샤드의 더 큰 값 때문인지 판단합니다.
일반적인 원인:
- 해시태그 오용으로 많은 수의 키를 같은 샤드에 집중시키는 현상.
- 큰 키: 특정 샤드에 매우 큰 소수의 데이터 구조를 할당하는 경우입니다.
- 일관되지 않은 TTL 정책으로 인해 시간이 지남에 따라 메모리 사용량의 차이가 발생합니다.
수정:
- 해시태그 사용을 검토하고 변화시켜 키를 재분배하세요.
- Big Keys 지표를 사용해 큰 키를 식별하고 분할하여 영향을 받은 샤드를 찾으세요.
- 고메모리 샤드에 있는 키에 대한 TTL 정책을 검토하세요.
복제 버퍼 성장 진단
각 기본 샤드는 복제본에 대한 출력 버퍼를 유지하며, 복제본이 아직 적용하지 않은 큐 쓰기 버퍼를 관리합니다. 복제본이 따라가지 못하면 이 버퍼가 커지면서 샤드의 메모리를 소모합니다. 만약 복제본이 제한 없이 성장하면 복제본이 분리되어 완전한 재동기화를 강제로 해야 할 수 있는데, 이는 비용이 많이 들고 반복적인 재동기화 사이클로 이어지거나 복제 동기화가 건강하지 못해질 수 있습니다. 각 샤드는 자체 복제 완충 장치를 가지고 있기 때문에, 성장은 종종 특정 샤드에만 국한됩니다.
탐지 접근법:
-
샤드 메모리 클라이언트 복제본(바이트)
Slots (Range)을 분할하여 15분 이상 지속되는 샤드에서 단일 높은 측정값이 아닌 지속적인 상승 추세를 관찰하세요. 꾸준한 성장이 신호이지, 일시적인 급증이 아닙니다. - 같은 샤 드 내 샤드 복제 링크 업 과 연관됩니다. 링크가 0으로 떨어지는 버퍼 성장은 복제본이 연결이 끊겼음을 나타내며, 재동기화가 있을 가능성이 높습니다.
- 쓰기 중심 활동(클러스터 레벨의 세트 와 전체 연산 )과 연관하여 쓰기 버스트가 성장을 이끄는지 확인하세요.
일반적인 원인:
- 지속적인 쓰기 버스트는 복제본이 적용할 수 있는 속도보다 빠르게 변경을 생성합니다.
- 자원 경쟁 중인 느린 복제품으로, 주 무기에 뒤처지고 있습니다.
- 버퍼를 반복적으로 채우는 완전한 재동기화 루프.
- 개별 반복 작업을 크고 전송 속도를 느리게 만드는 큰 키들.
수정:
- 가능한 한 쓰기 폭발을 부드럽게 하거나 줄이거나, 용량을 늘리기 위해 캐시를 확장하세요.
- 개별 복제 작업의 크기를 줄이기 위해 큰 키를 식별하고 분할하세요.
- 버퍼가 계속 증가하고 복제본이 반복적으로 연결이 끊기면, 지원 요청을 열어 플랫폼 팀이 복제본 건강 상태와 버퍼 크기 상태를 검토할 수 있도록 하세요. 이 부분은 서비스가 관리합니다.
큰 키 관리
큰 키와 대규모 컬렉션은 개별 샤드에 대한 메모리 부담을 증가시키고 복제 비용을 증가시킵니다. 최상의 데이터 경로 성능을 위해 개별 키/값 크기를 512 KB 이하로 유지하세요. 이는 강제 제한이 아니라 성능 권장입니다.
큰 키 메트릭 버킷은 경계만 모니터링하며, 권장되거나 승인된 키 크기가 아닙니다. 예를 들어, Shard Strings Ssize Under 128 MB 버킷은 128MB 미만의 문자열 키를 단순히 집계하여 성장 여부를 관찰할 수 있습니다; Azure가 키를 128MB 근처에 저장할 것을 권장한다는 뜻은 아닙니다. 마찬가지로, 요소 수 버킷(1M, 8M)은 과도한 크기의 컬렉션을 식별하는 임계값이지, 목표 크기를 정하는 것이 아닙니다. 항상 실용적으로 가장 작은 키 크기(이상적으로는 512 KB 이하)를 목표로 하고, 더 높은 양동이로 올라가는 키는 모두 조사할 대상으로 삼으세요.
Big Keys는 크기 범위에 따라 버튼을 측정해서 성장이 문제가 생기기 전에 감지할 수 있습니다. 컬렉션의 경우, 첫 번째 버킷은 정상 범위 내의 키를 나타내므로, 두 번째나 세 번째 버킷에 나타나는 키는 모두 조사할 가치가 있다고 간주하세요. 문자열 키의 경우 128MB 미만의 버킷만 노출되므로 128MB에 근접하거나 초과하는 문자열 값은 주의사항으로 간주하세요.
큰 키가 중요한 이유:
- 복제 비용: 큰 키는 고가용성 복제와 능동 지리 복제(CRDB) 모두 더 비싸게 만듭니다. 그 효과는 즉각적이지 않다; 보통 이후에 고장이나 재연결이 발생하면서 완전한 재동기화가 발생할 때 나타납니다.
- 플래시 최적화 캐시 영향: 플래시 최적화 SKU에서는 키가 크면 RAM에 남아 플래시로 오버로드되지 않아, 플래시 디스크 공간이 남아 있어도 메모리(OOM) 오류가 발생할 수 있습니다. 키 이름에 비해 매우 작은 가치도 오프로드가 잘 되지 않습니다.
탐지 접근법:
- 각 큰 키 메트릭을
Slots (Range)나누어 어떤 조각에 큰 키를 담고 있는지 확인하세요. - 수집의 경우, 두 번째와 세 번째 요소 수 버킷(1M에서 8M, 오버 8M)에 집중하세요. 세 번째 버킷은 가장 극단적인 조를 나타냅니다. 문자열의 경우, 128 MB 미만의 샤드 문자열 크기 버킷만 노출되므로 128 MB 이상의 문자열 값은 주의사항으로 간주하세요.
- 샤 드 메모리 와 상관관계 대
Slots (Range)큰 키가 특정 샤드의 메모리 불균형을 유발하는지 확인하는 데 사용됩니다.
수정:
- 모범 사례로 첫 번째 버킷 또는 512 KB에 가까운 값 크기를 줄이는 것이 좋습니다. 일반적인 전략으로는 큰 값들을 여러 키에 걸쳐 분할하거나 청킹하거나, 직렬화된 값을 압축하거나 재포맷하는 방법이 있습니다.
- 시간이 지남에 따라 무한하게 성장하는 컬렉션(리스트, 세트, 정렬 세트, 해시)의 경우, 컬렉션을 여러 키로 나누거나 주기적으로 트리밍하세요.
- 목표는 개별 키와 컬렉션 크기를 줄이는 것입니다. 가장 좋은 방법은 애플리케이션 설계와 데이터 타입에 따라 다릅니다.
샤드 레벨 메트릭에 대한 알림 추천
| 시나리오 | 측정단위 | Condition | 평가 창 | Severity |
|---|---|---|---|---|
| 복제 링크 실패 | 샤드 복제 링크 업, 분할 Slots (Range) |
어떤 샤드에서든 최소 = 0 | 120+ 분 | 높음 |
| 기억 불균형 | 샤드 메모리(바이트 단위)는 다음과 같이 분할됩니다 Slots (Range) |
슬롯 > 간 최대/최소 비율 2배 | 5분 | Medium |
| 복제 버퍼 성장 | 샤드 메모리 클라이언트 복제본(바이트), 분할 Slots (Range) |
15분 동안 지속 증가 | 15분 | Medium |
| 매우 큰 컬렉션(세 번째 버킷) | "8M 이상 요소" 수집 버킷 지표를 나누어 Slots (Range) |
어떤 샤드든 값 0이 있어야 > 합니다 | 10분 이상 | 높음 |
| 대규모 컬렉션 (두 번째 버킷) | "1M에서 8M Elements" 수집 버킷 메트릭은 다음과 같은 분할 Slots (Range) |
해당 유형의 총 키에서 차지하는 버킷 수는 10%를 초과합니다 | 10분 이상 | Medium |
| 큰 줄 키 | 샤드 문자열 크기 128MB 미만 (유일하게 노출된 문자열 버킷) | 128MB 이상의 문자열 값은 주의해야 하며; 임계값으로 성장하는 키의 128MB 미만 수를 주의 깊게 관찰하세요 | 10분 이상 | 정보용 |
Note
복제 링크 실패 경고는 Azure Monitor 메트릭 알림으로 직접 작성할 수 있는데, 메트릭이 최소 등급으로 집계되기 때문에 창 값이 0이면 링크가 언젠가 다운된 상태임을 의미합니다. 매우 큰 컬렉션(세 번째 버킷) 알림도 네이티브로 작성할 수 있는데, 이는 단일 지표를 고정된 임계값(값 0보다 큰)에 대해 테스트하기 때문입니다. 나머지 시나리오는 Azure Monitor 메트릭 알림으로 네이티브로 평가할 수 없습니다: 메트릭 알림은 차원 값 간 값을 비교할 수 없고(예: 최대/최소 비율Slots (Range)), 두 메트릭 간 비율(예: 해당 유형의 총 키에서 차지하는 두 번째 버킷 카운트)을 계산할 수 없으며, 지속적인 상승 추세를 감지할 수 없습니다. 이들은 단지 특정 시점에서 값이 고정된 임계값을 넘는지 여부를 테스트합니다. 내보내진 지표에 대해 로그 검색 알림으로 작성하세요: 진단 설정을 사용해 Log Analytics 작업 공간에 지표를 보내고, Kusto(KQL) 쿼리에서 최대/최소 비율, 버킷 공유율, 추세를 계산하세요. 첫 번째 버킷 지표는 알림이 필요하지 않습니다; 시간이 지남에 따라 그들의 추세를 모니터링하세요.
리소스 로그
이 섹션에는 이 서비스에 대해 모을 수 있는 리소스 로그 유형이 나열되어 있습니다. 이 섹션은 Azure Monitor에서 지원되는 모든 리소스 로그 범주 유형 목록에서 가져옵니다.
Microsoft.Cache/redisEnterprise/데이터베이스에 대해 지원되는 리소스 로그
| 카테고리 | 내보낼 비용 | 로그 테이블 | 기본 로그 계획을 지원합니다 | 인제션 시 변환 지원 | 예제 쿼리 |
|---|---|---|---|---|---|
| 연결 이벤트(새 연결/인증/연결 끊기) | 예 |
REDConnectionEvents 클라이언트가 Redis 엔터프라이즈 데이터베이스에 연결할 때 연결 이벤트를 기록합니다. |
예 | 예 | 쿼리 |
Azure Monitor 로그 테이블
이 섹션은 이 서비스와 관련이 있고 Kusto 쿼리를 사용하는 Log Analytics의 쿼리에 사용할 수 있는 Azure Monitor 로그 테이블을 나열합니다. 테이블에는 리소스 로그 데이터가 포함되며 수집 및 라우팅되는 항목에 따라 더 많은 데이터가 포함될 수 있습니다.
Azure 관리형 Redis
Microsoft.Cache/redisEnterprise
활동 로그
연결된 테이블에는 이 서비스의 활동 로그에 기록할 수 있는 작업이 나열되어 있습니다. 이 작업은 활동 로그에서 가능한 모든 리소스 공급자 작업의 하위 집합입니다.
활동 로그 항목의 스키마에 대한 자세한 내용은 활동 로그 스키마를 참조하세요.
관련 콘텐츠
- Azure 리소스 모니터링에 대한 자세한 내용은 Azure Monitor를 사용한 Azure 리소스 모니터링을 참조하세요.