Azure Kubernetes Service 모니터링

이 문서에서는 다음을 설명합니다.

  • 이 서비스에 대해 수집할 수 있는 모니터링 데이터의 유형.
  • 해당 데이터를 분석하는 방법.

참고 항목

이 서비스 및/또는 Azure Monitor에 이미 익숙하고 모니터링 데이터를 분석하는 방법만 알고 싶은 경우 이 문서의 끝부분에 있는 분석 섹션을 참조하세요.

Azure 리소스를 사용하는 중요한 애플리케이션 및 비즈니스 프로세스가 있는 경우 시스템을 모니터링하고 시스템에 대한 경고를 받아야 합니다. Azure Monitor 서비스는 시스템의 모든 구성 요소에서 메트릭과 로그를 수집하고 집계합니다. Azure Monitor는 가용성, 성능, 복원력에 대한 보기를 제공하고 문제를 알려 줍니다. Azure Portal, PowerShell, Azure CLI, REST API 또는 클라이언트 라이브러리를 사용하여 모니터링 데이터를 설정하고 볼 수 있습니다.

Important

Kubernetes는 움직이는 부품이 많은 복잡한 분산 시스템입니다. 여러 수준에서 모니터링이 필요합니다. AKS는 관리되는 Kubernetes 서비스이지만 여러 수준에서 모니터링하는 것과 동일한 엄격함이 여전히 필요합니다. 이 문서에서는 AKS 클러스터를 모니터링하기 위한 높은 수준의 정보와 모범 사례를 제공합니다.

  • 전체 Kubernetes 스택에 대한 자세한 모니터링은 Azure 서비스 및 클라우드 네이티브 도구를 사용하여 Kubernetes 클러스터 모니터링을 참조 하세요.
  • Kubernetes 클러스터에서 메트릭 데이터를 수집하려면 Prometheus용 Azure Monitor 관리형 서비스를 참조하세요.
  • Kubernetes 클러스터에서 로그를 수집하려면 Kubernetes 모니터링에 대한 Azure Monitor 기능을 참조 하세요.
  • 데이터 시각화는 Grafana에서 Azure 통합 문서Azure 서비스 모니터링을 참조하세요.

Insights

Azure의 일부 서비스에는 서비스 모니터링을 위한 시작점을 제공하는 모니터링 대시보드가 Azure Portal에 있습니다. 이러한 대시보드를 인사이트라고 하며, Azure Portal에서 Azure Monitor의 Insights Hub에서 찾을 수 있습니다.

Azure Monitor Container Insights는 노드, Pod, 컨테이너 및 영구 볼륨에 대한 사용자 지정 메트릭을 수집합니다. 자세한 내용은 Container Insights에서 수집한 메트릭을 참조 하세요.

데이터 모니터링

AKS는 Azure 리소스에서 데이터 모니터링에 설명된 다른 Azure 리소스와 동일한 종류의 모니터링 데이터를 생성합니다. 모니터링 AKS에서 만든 메트릭 및 로그에 대한 세부 정보는 AKS 데이터 참조 모니터링을 참조하세요. 다른 Azure 서비스 및 기능에서는 다음 다이어그램 및 표와 같이 추가 데이터를 수집하고 다른 분석 옵션을 사용하도록 설정합니다.

AKS에서 모니터링 데이터 수집 다이어그램

Source 설명
플랫폼 메트릭 플랫폼 메트릭은 AKS 클러스터에 대해 무료로 자동 수집됩니다. 메트릭 탐색기를 사용하여 이러한 메트릭을 분석하거나 메트릭 경고에 사용할 수 있습니다.
Prometheus 메트릭 클러스터에 대해 메트릭 스크래핑을 사용하도록 설정하면 Prometheus용 Azure Monitor 관리형 서비스가 Prometheus 메트릭을 수집하고 Azure Monitor 작업 영역에 저장합니다. Azure Managed Grafana미리 빌드된 대시보드Prometheus 경고을 사용하여 분석합니다.
활동 로그 활동 로그는 AKS 클러스터에 대해 무료로 자동 수집됩니다. 이러한 로그는 클러스터가 만들어지거나 구성이 변경된 시기와 같은 정보를 추적합니다. 다른 로그 데이터로 분석하려면 활동 로그를 Log Analytics 작업 영역으로 보냅니다.
리소스 로그 AKS의 컨트롤 플레인 로그는 리소스 로그로 구현됩니다. Log Analytics에서 로그 쿼리를 사용하여 리소스 로그를 분석하고 경고할 수 있는 Log Analytics 작업 영역으로 로그를 보내는 진단 설정 만들기를 수행합니다.
컨테이너 인사이트 컨테이너 인사이트는 stdout/stderr 스트림을 포함하여 클러스터에서 다양한 로그 및 성능 데이터를 수집하고 Log Analytics 작업 영역 및 Azure Monitor 메트릭에 저장합니다. 컨테이너 인사이트에 포함된 보기 및 통합 문서를 사용하거나 또는 Log Analytics메트릭 탐색기를 사용하여 이 데이터를 분석합니다.

리소스 유형

Azure는 리소스 유형 및 ID의 개념을 사용하여 구독의 모든 항목을 식별합니다. 리소스 유형은 Azure에서 실행되는 모든 리소스에 대한 리소스 ID의 일부이기도 합니다. 예를 들어 가상 머신의 리소스 유형 중 하나는 Microsoft.Compute/virtualMachines입니다. 서비스 및 관련 리소스 유형 목록은 리소스 공급자를 참조하세요.

마찬가지로 Azure Monitor는 네임스페이스라고도 하는 리소스 유형에 따라 핵심 모니터링 데이터를 메트릭 및 로그로 구성합니다. 리소스 유형에 따라 다른 메트릭 및 로그를 사용할 수 있습니다. 서비스는 둘 이상의 리소스 유형과 연결될 수 있습니다.

AKS 의 리소스 종류에 대한 자세한 내용은 Azure Kubernetes Service 모니터링 데이터 참조를 참조하세요.

데이터 저장소

Azure Monitor의 경우:

  • 메트릭 데이터는 Azure Monitor 메트릭 데이터베이스에 저장됩니다.
  • 로그 데이터는 Azure Monitor 로그 저장소에 저장됩니다. 로그 분석은 이 저장소를 쿼리할 수 있는 Azure Portal의 도구입니다.
  • Azure 활동 로그는 Azure Portal에 자체 인터페이스가 있는 별도의 저장소입니다.

선택적으로 메트릭 및 활동 로그 데이터를 Azure Monitor 로그 저장소로 라우팅할 수 있습니다. 그런 다음 Log Analytics를 사용하여 데이터를 쿼리하고 다른 로그 데이터와 상호 연결할 수 있습니다.

많은 서비스에서는 진단 설정을 사용하여 메트릭 및 로그 데이터를 Azure Monitor 외부의 다른 스토리지 위치로 보낼 수 있습니다. 예를 들면 Azure Storage, 호스트된 파트너 시스템Event Hubs를 사용하는 비 Azuree 파트너 시스템이 있습니다.

Azure Monitor가 데이터를 저장하는 방법에 대한 자세한 내용은 Azure Monitor 데이터 플랫폼을 참조하세요.

Azure Monitor 플랫폼 메트릭

Azure Monitor는 대부분의 서비스에 대한 플랫폼 메트릭을 제공합니다. 이러한 메트릭은 다음과 같습니다.

  • 각 네임스페이스에 대해 개별적으로 정의됩니다.
  • Azure Monitor 시계열 메트릭 데이터베이스에 저장됩니다.
  • 간단하며 실시간에 가까운 경고를 지원할 수 있습니다.
  • 시간 경과에 따른 리소스의 성능을 추적하는 데 사용됩니다.

수집: Azure Monitor는 플랫폼 메트릭을 자동으로 수집합니다. 구성이 필요하지 않습니다.

라우팅: 일반적으로 플랫폼 메트릭을 Azure Monitor 로그/Log Analytics로 라우팅하여 다른 로그 데이터로 쿼리할 수도 있습니다. 자세한 내용은 메트릭 진단 설정을 참조하세요. 서비스에 대한 진단 설정을 구성하는 방법은 Azure Monitor에서 진단 설정 만들기를 참조하세요.

Azure Monitor의 모든 리소스에 대해 수집할 수 있는 모든 메트릭 목록은 Azure Monitor에서 지원되는 메트릭을 참조하세요.

AKS에 사용 가능한 메트릭 목록은 Azure Kubernetes Service 모니터링 데이터 참조를 참조하세요.

메트릭은 AKS 클러스터의 클러스터 모니터링, 문제 식별 및 성능 최적화에서 중요한 역할을 합니다. 플랫폼 메트릭은 kube-system 네임스페이스에 설치된 기본 제공 메트릭 서버를 사용하여 캡처되며, Kubelet에서 제공하는 모든 Kubernetes 노드에서 메트릭을 주기적으로 스크랩합니다. 또한 Azure Managed Prometheus 메트릭을 사용하도록 설정하여 배포의 개체 상태와 같은 컨테이너 메트릭 및 Kubernetes 개체 메트릭을 수집해야 합니다. 자세한 내용은 AKS 클러스터에서 Prometheus 메트릭 수집을 참조하세요.

또한 AKS는 API 서버, ETCD, Scheduler와 같은 중요한 컨트롤 플레인 구성 요소에서 Azure Managed Prometheus를 통해 메트릭을 노출합니다. 이 기능은 현지 미리 보기로 제공됩니다. 자세한 내용은 AKS(Azure Kubernetes Service) 컨트롤 플레인 메트릭 모니터링(미리 보기)을 참조하세요.

비Azure Monitor 기반 메트릭

이 서비스는 Azure Monitor 메트릭 데이터베이스에 포함되지 않은 다른 메트릭을 제공합니다.

Kubernetes 클러스터의 추가 모니터링에 Azure Monitor의 다음 Azure 서비스 및 기능을 사용할 수 있습니다. Azure Portal, Azure CLI, Terraform, Azure Policy의 통합 탭에서 AKS 클러스터를 만드는 동안 이러한 기능을 사용하도록 설정하거나 나중에 클러스터를 온보딩할 수 있습니다. 이러한 각 기능에는 비용이 발생할 수 있으므로 사용하도록 설정하기 전에 각각에 대한 가격 책정 정보를 참조하세요.

서비스/기능 설명
컨테이너 인사이트 컨테이너화된 버전의 Azure Monitor 에이전트사용하여 클러스터의 각 노드에서 stdout/stderr 로그 및 Kubernetes 이벤트를 수집합니다. 이 기능은 AKS 클러스터에 대한 다양한 모니터링 시나리오를 지원합니다. AZURE CLI, Azure Policy, Azure Portal 또는 Terraform을 사용하여 AKS 클러스터를 만들 때 모니터링을 사용하도록 설정할 수 있습니다. 클러스터를 만들 때 컨테이너 인사이트를 사용하도록 설정하지 않은 경우 이를 사용하도록 설정하는 다른 옵션은 AKS(Azure Kubernetes Service) 클러스터에 대한 컨테이너 인사이트 사용을 참조하세요.

컨테이너 인사이트는 대부분의 데이터를 Log Analytics 작업 영역에 저장하며 일반적으로 클러스터의 리소스 로그와 동일한 로그 분석 작업 영역을 사용합니다. 사용해야 하는 작업 영역 수와 찾을 수 있는 위치에 대한 지침은 Log Analytics 작업 영역 아키텍처 디자인을 참조하세요.
Prometheus용 Azure Monitor 관리 서비스 Prometheus 는 클라우드 네이티브 컴퓨팅 재단의 클라우드 네이티브 메트릭 솔루션입니다. Kubernetes 클러스터에서 메트릭 데이터를 수집하고 분석하는 데 사용되는 가장 일반적인 도구입니다. Prometheus용 Azure Monitor 관리 서비스는 Azure에서 완전 관리형 Prometheus 호환 모니터링 솔루션입니다. 클러스터를 만들 때 관리형 Prometheus를 사용하도록 설정하지 않으면 AKS 클러스터에서 Prometheus 메트릭 수집을 참조하여 다른 옵션을 사용하도록 설정합니다.

Prometheus용 Azure Monitor 관리 서비스는 Azure Monitor 작업 영역에 데이터를 저장합니다. 이 작업 영역은 Grafana 작업 영역에 연결되어 Azure Managed Grafana로 데이터를 분석할 수 있습니다.
Azure Managed Grafana Prometheus 데이터를 표시하는 데 일반적으로 사용되는 오픈 소스 데이터 시각화 플랫폼인 Grafana의 완전 관리형 구현입니다. Kubernetes 모니터링 및 전체 스택 문제 해결을 위해 미리 정의된 여러 Grafana 대시보드를 사용할 수 있습니다. 클러스터를 만들 때 관리되는 Grafana를 사용하도록 설정하지 않으면 Grafana 작업 영역 연결을 참조하세요. 클러스터에 대한 Prometheus 메트릭에 액세스할 수 있도록 Azure Monitor 작업 영역에 연결할 수 있습니다.

AKS 컨트롤 플레인 메트릭 모니터링(미리 보기)

이 섹션에서는 컨트롤 플레인 메트릭(미리 보기) 기능을 사용하는 방법을 보여 줍니다. 컨트롤 플레인에서 메트릭을 수집하고 Azure Monitor에서 원격 분석을 봅니다. 컨트롤 플레인 메트릭 기능은 Prometheus 및 Grafana와 완벽하게 호환됩니다. 이 기능은 API 서버, ETCD, Scheduler, Autoscaler 및 컨트롤러 관리자와 같은 컨트롤 플레인 구성 요소의 가용성 및 성능에 대한 더 많은 가시성을 제공합니다. 이러한 메트릭을 사용하여 전반적인 가시성을 최대화하고 AKS 클러스터에 대한 운영 우수성을 유지할 수 있습니다.

필수 구성 요소 및 제한 사항

aks-preview 확장 설치

Important

AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.

  • az extension add 또는 az extension update 명령을 사용하여 aks-preview Azure CLI 확장을 설치하거나 업데이트합니다.

    # Install the aks-preview extension
    az extension add --name aks-preview
    
    # Update the aks-preview extension
    az extension update --name aks-preview
    

AzureMonitorMetricsControlPlanePreview 플래그 등록

  1. az feature register 명령을 사용하여 AzureMonitorMetricsControlPlanePreview 기능 플래그를 등록합니다.

    az feature register --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"
    

    상태가 Registered로 표시되는 데 몇 분 정도 걸립니다.

  2. 또한 az feature show 명령을 사용하여 등록 상태를 확인합니다.

    az feature show --namespace "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"
    
  3. 상태가 Registered(등록됨)를 반영하면 az provider register 명령을 사용하여 Microsoft.ContainerService 리소스 공급자의 등록을 새로 고칩니다.

    az provider register --namespace "Microsoft.ContainerService"
    

AKS 클러스터에서 컨트롤 플레인 메트릭 사용

새 클러스터를 만들거나 기존 클러스터를 업데이트할 때 Azure Monitor Prometheus용 관리 서비스 추가 기능을 사용하여 컨트롤 플레인 메트릭을 사용하도록 설정할 수 있습니다.

새 AKS 클러스터에서 컨트롤 플레인 메트릭을 사용하도록 설정합니다.

Kubernetes 클러스터에서 Prometheus 메트릭을 수집하려면 AKS 클러스터에 대해 Prometheus 및 Grafana를 사용하도록 설정하고 AKS 클러스터에 대한 CLI 탭의 단계를 따릅니다.

기존 AKS 클러스터에서 컨트롤 플레인 메트릭 사용

  • 클러스터에 이미 Prometheus 추가 기능이 있는 경우 az aks update 명령을 사용하여 컨트롤 플레인 메트릭 수집을 시작하도록 클러스터를 업데이트합니다.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP
    

참고 항목

클러스터 노드에서 수집된 메트릭과 달리, 컨트롤 플레인 메트릭은 ama-metrics 추가 기능의 일부가 아닌 구성 요소에 의해 수집됩니다. AzureMonitorMetricsControlPlanePreview 기능 플래그 및 관리되는 Prometheus 추가 기능을 사용하도록 설정하면 컨트롤 플레인 메트릭이 수집됩니다. 메트릭 수집을 사용하도록 설정한 후 데이터가 작업 영역에 표시되는 데 몇 분 정도 걸릴 수 있습니다.

컨트롤 플레인 메트릭 쿼리

컨트롤 플레인 메트릭은 클러스터 지역의 Azure Monitor 작업 영역에 저장됩니다. 이러한 메트릭은 작업 영역에서 바로 또는 작업 영역에 연결된 Azure Managed Grafana 인스턴스를 통해 쿼리할 수 있습니다.

다음 단계를 사용하여 Azure Monitor 작업 영역에서 컨트롤 플레인 메트릭을 확인합니다.

  1. Azure Portal에서 AKS 클러스터로 이동합니다.

  2. 모니터링에서 인사이트를 선택합니다.

    Azure Monitor 작업 영역의 스크린샷.

참고 항목

AKS는 컨트롤 플레인 원격 분석 데이터를 실시간으로 보고 분석하는 데 도움이 되는 대시보드 템플릿을 제공합니다. Azure Managed Grafana를 사용하여 데이터를 시각화하는 경우 다음 대시보드를 가져올 수 있습니다.

컨트롤 플레인 메트릭 사용자 지정

AKS에는 각 구성 요소에 대해 수집하고 저장할 미리 구성된 메트릭 집합이 포함됩니다. API serveretcd는 기본적으로 사용하도록 설정됩니다. ama-settings-configmap을 통해 이 목록을 사용자 지정할 수 있습니다.

기본 대상에는 다음 값이 포함됩니다.

controlplane-apiserver = true
controlplane-cluster-autoscaler = false
controlplane-kube-scheduler = false
controlplane-kube-controller-manager = false
controlplane-etcd = true

모든 ConfigMaps는 모든 클러스터의 kube-system 네임스페이스에 적용해야 합니다.

minimal-ingestion 프로필 메트릭에 대한 자세한 내용은 관리되는 Prometheus에서 컨트롤 플레인 메트릭의 최소 수집 프로필을 참조하세요.

  • 기본 대상에서 최소 메트릭만 수집

    default-targets-metrics-keep-list.minimalIngestionProfile="true"를 설정할 때 각 기본 대상인 controlplane-apiservercontrolplane-etcd에 대해 최소 메트릭 집합만 수집됩니다.

  • 모든 대상에서 모든 메트릭 수집

    다음 단계를 사용하여 클러스터의 모든 대상에서 모든 메트릭을 수집합니다.

    1. ConfigMap 파일 ama-metrics-settings-configmap.yaml을 다운로드하고 이름을 configmap-controlplane.yaml로 바꿉니다.

    2. minimalingestionprofile = false을 설정합니다.

    3. default-scrape-settings-enabled에서 스크래핑하려는 대상이 true로 설정되었는지 확인합니다. 다음 대상만 지정할 수 있습니다. controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler, controlplane-kube-controller-manager, controlplane-etcd.

    4. kubectl apply 명령을 사용하여 ConfigMap을 적용합니다.

      kubectl apply -f configmap-controlplane.yaml
      

      구성이 적용된 후 컨트롤 플레인에서 스크래핑된 지정된 대상의 메트릭이 Azure Monitor 작업 영역에 표시되기까지 몇 분 정도 걸립니다.

  • 최소 메트릭 외에도 몇 가지 다른 메트릭 수집

    minimal ingestion profile은 기본 대시보드, 기본 기록 규칙 및 기본 경고에서 사용되는 메트릭만 수집되므로 메트릭 수집 볼륨을 줄이는 데 도움이 되는 설정입니다. 이 설정을 사용자 지정하려면 다음 단계를 사용합니다.

    1. ConfigMap 파일 ama-metrics-settings-configmap을 다운로드하고 이름을 configmap-controlplane.yaml로 바꿉니다.

    2. minimalingestionprofile = true을 설정합니다.

    3. default-scrape-settings-enabled에서 스크래핑하려는 대상이 true로 설정되었는지 확인합니다. 다음 대상만 지정할 수 있습니다. controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler, controlplane-kube-controller-manager, controlplane-etcd.

    4. default-targets-metrics-keep-list 아래에서 true 대상에 대한 메트릭 목록을 지정합니다. 예시:

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"
      
    5. kubectl apply 명령을 사용하여 ConfigMap을 적용합니다.

      kubectl apply -f configmap-controlplane.yaml
      

    구성이 적용된 후 컨트롤 플레인에서 스크래핑된 지정된 대상의 메트릭이 Azure Monitor 작업 영역에 표시되기까지 몇 분 정도 걸립니다.

  • 일부 대상에서 특정 메트릭만 수집

    1. ConfigMap 파일 ama-metrics-settings-configmap을 다운로드하고 이름을 configmap-controlplane.yaml로 바꿉니다.

    2. minimalingestionprofile = false을 설정합니다.

    3. default-scrape-settings-enabled에서 스크래핑하려는 대상이 true로 설정되었는지 확인합니다. 다음 대상만 지정할 수 있습니다. controlplane-apiserver, controlplane-cluster-autoscaler, controlplane-kube-scheduler,controlplane-kube-controller-manager, controlplane-etcd.

    4. default-targets-metrics-keep-list 아래에서 true 대상에 대한 메트릭 목록을 지정합니다. 예시:

      controlplane-apiserver= "apiserver_admission_webhook_admission_duration_seconds| apiserver_longrunning_requests"
      
    5. kubectl apply 명령을 사용하여 ConfigMap을 적용합니다.

      kubectl apply -f configmap-controlplane.yaml
      

      구성이 적용된 후 컨트롤 플레인에서 스크래핑된 지정된 대상의 메트릭이 Azure Monitor 작업 영역에 표시되기까지 몇 분 정도 걸립니다.

컨트롤 플레인 메트릭 문제 해결

기능 플래그 AzureMonitorMetricsControlPlanePreview가 사용하도록 설정되어 있고 ama-metrics Pod가 실행 중인지 확인해야 합니다.

참고 항목

Azure 관리되는 서비스 Prometheus에 대한 문제 해결 방법은 여기에서 직접 변환되지 않습니다. 관리되는 Prometheus 추가 기능에 컨트롤 플레인을 스크래핑하는 구성 요소가 없기 때문입니다.

  • ConfigMap 서식 지정

    ConfigMap에서 적절한 서식을 사용하고 있는지, 특히 default-targets-metrics-keep-list, minimal-ingestion-profiledefault-scrape-settings-enabled 필드가 의도한 값으로 올바르게 채워져 있는지 확인합니다.

  • 데이터 평면에서 컨트롤 플레인 격리

    먼저 일부 노드 관련 메트릭true로 설정하여 메트릭이 작업 영역으로 전달되는지 확인합니다. 이렇게 하면 문제가 컨트롤 플레인 메트릭 스크래핑과 관련된 것인지 확인하는 데 도움이 됩니다.

  • 수집되는 이벤트

    변경 내용을 적용한 후에는 Azure Monitor 개요 페이지 또는 선택한 클러스터의 모니터링 섹션에서 메트릭 탐색기를 열고 분당 수집된 이벤트 수가 증가했는지 아니면 감소했는지 확인할 수 있습니다. 이는 특정 메트릭이 없는지 또는 모든 메트릭이 없는지 확인하는 데 도움이 됩니다.

  • 특정 메트릭이 표시되지 않음

    메트릭이 문서화되어 있지만 대상에서 노출되지 않고 Azure Monitor 작업 영역으로 전달되지 않는 경우가 있습니다. 이 경우 다른 메트릭이 작업 영역으로 전달되고 있는지 확인해야 합니다.

  • Azure Monitor 작업 영역에 대한 액세스 권한 없음

    추가 기능을 사용하도록 설정하면 액세스할 수 없는 기존 작업 영역을 지정할 수 있습니다. 이 경우 메트릭이 수집 및 전달되지 않는 것처럼 보일 수 있습니다. 추가 기능을 사용하도록 설정하거나 클러스터를 만드는 동안 새 작업 영역을 만들어야 합니다.

AKS 클러스터에서 컨트롤 플레인 메트릭 사용 안 함

관리되는 Prometheus 추가 기능을 사용하지 않도록 설정하고 AzureMonitorMetricsControlPlanePreview 기능 플래그의 등록을 취소하여 언제든지 컨트롤 플레인 메트릭을 사용하지 않도록 설정할 수 있습니다.

  1. az aks update 명령을 실행하여 Prometheus 메트릭을 스크래핑하는 메트릭 추가 기능을 제거합니다.

    az aks update --disable-azure-monitor-metrics --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP
    
  2. az feature unregister 명령을 사용하여 AzureMonitorMetricsControlPlanePreview 기능 플래그의 등록을 취소하는 방법으로 AKS 클러스터에서 컨트롤 플레인 메트릭의 스크래핑을 사용하지 않도록 설정합니다.

    az feature unregister "Microsoft.ContainerService" --name "AzureMonitorMetricsControlPlanePreview"
    

FAQ

  • 자체 호스팅 Prometheus를 사용하여 컨트롤 플레인 메트릭을 스크래핑할 수 있나요?

    아니요, 현재로서는 자체 호스팅 Prometheus를 사용하여 컨트롤 플레인 메트릭을 스크래핑할 수 없습니다. 자체 호스팅 프로메테우스는 부하 분산 장치에 따라 단일 인스턴스만 스크래핑할 수 있습니다. 관리되는 Prometheus를 통해서만 볼 수 있는 컨트롤 플레인 메트릭의 복제본이 여러 개 있는 경우가 많기 때문에 이러한 메트릭은 신뢰할 수 없습니다.

  • 컨트롤 플레인 메트릭을 통해 사용자 에이전트를 사용할 수 없는 이유는 무엇인가요?

    Kubernetes의 컨트롤 플레인 메트릭에는 사용자 에이전트가 없습니다. 사용자 에이전트는 진단 설정에서 제공되는 컨트롤 플레인 로그를 통해서만 사용할 수 있습니다.

Azure Monitor 리소스 로그

리소스 로그는 Azure 리소스에서 수행한 작업에 대한 인사이트를 제공합니다. 로그는 자동으로 생성되지만 저장하거나 쿼리하려면 로그를 Azure Monitor 로그로 라우팅해야 합니다. 로그는 범주별로 구성됩니다. 지정된 네임스페이스에는 여러 리소스 로그 범주가 있을 수 있습니다.

수집: 리소스 로그는 진단 설정을 만들고 하나 이상의 위치로 라우팅할 때까지 수집 및 저장되지 않습니다. 진단 설정을 만들 때 수집할 로그 범주를 지정합니다. 진단 설정을 만들고 유지 관리하는 방법에는 Azure Portal, 프로그래밍 방식, Azure Policy 사용 등을 포함한 여러 가지 방법이 있습니다.

라우팅: 제안되는 기본값은 리소스 로그를 Azure Monitor 로그로 라우팅하여 다른 로그 데이터로 쿼리할 수 있도록 하는 것입니다. Azure Storage, Azure Event Hubs, 특정 Microsoft 모니터링 파트너와 같은 다른 위치도 사용할 수 있습니다. 자세한 내용은 Azure 리소스 로그리소스 로그 대상을 참조하세요.

리소스 로그 수집, 저장 및 라우팅에 대한 자세한 내용은 Azure Monitor의 진단 설정을 참조하세요.

Azure Monitor에서 사용 가능한 모든 리소스 로그 범주 목록은 Azure Monitor에서 지원되는 리소스 로그를 참조하세요.

Azure Monitor의 모든 리소스 로그에는 동일한 헤더 필드와 서비스별 필드가 있습니다. 공용 스키마는 Azure Monitor 리소스 로그 스키마에서 설명합니다.

사용 가능한 리소스 로그 범주, 연결된 Log Analytics 테이블 및 AKS에 대한 로그 스키마는 Azure Kubernetes Service 모니터링 데이터 참조를 참조하세요.

AKS 컨트롤 플레인/리소스 로그

AKS 클러스터에 대한 컨트롤 플레인 로그는 Azure Monitor에서 리소스 로그로 구현됩니다. 리소스 로그는 진단 설정을 만들고 하나 이상의 위치로 라우팅할 때까지 수집 및 저장되지 않습니다. 일반적으로 컨테이너 인사이트에 대한 대부분의 데이터가 저장되는 Log Analytics 작업 영역으로 보냅니다.

Azure Portal, CLI 또는 PowerShell을 사용한 진단 설정 만들기의 자세한 프로세스는 진단 설정 만들기를 참조하세요. 진단 설정을 만들 때 수집할 로그 범주를 지정합니다. AKS의 범주는 AKS 모니터링 데이터 참조에 나열되어 있습니다.

Important

AKS의 리소스, 특히 kube-audit 로그를 수집할 때 상당한 비용이 들 수 있습니다. 수집되는 데이터의 양을 줄이려면 다음 권장 사항을 고려하세요.

  • 필요하지 않은 경우 kube-audit 로깅을 사용하지 않도록 설정합니다.
  • kube-audit-admin에서 컬렉션을 사용하도록 설정합니다. 이 컬렉션에서는 감사 이벤트 가져오기 및 나열을 제외합니다.
  • 여기에 설명된 대로 리소스별 로그를 사용하도록 설정하고 테이블을 기본 로그로 구성 AKSAudit 합니다.

추가 권장 사항은 Azure 서비스 및 클라우드 네이티브 도구를 사용하여 Kubernetes 클러스터 모니터링을 참조하고, 모니터링 비용을 줄이기 위한 추가 전략은 비용 최적화 및 Azure Monitor를 참조하세요.

AKS는 리소스 로그에 대한 Azure 진단 모드 또는 리소스별 모드를 지원합니다. 이 모드는 데이터가 전송되는 Log Analytics 작업 영역의 테이블을 지정합니다. Azure 진단 모드는 모든 데이터를 AzureDiagnostics 테이블로 보내고, 리소스별 모드는 리소스 로그의 테이블에 표시된 대로 AKS 감사, AKS 감사 관리자, AKS 컨트롤 플레인으로 데이터를 보냅니다.

리소스별 모드는 다음과 같은 이유로 AKS에 권장됩니다.

  • 데이터는 AKS 전용 개별 테이블에 있으므로 쿼리하기가 더 쉽습니다.
  • 상당한 비용 절감을 위해 기본 로그로 구성을 지원합니다.

기존 설정을 변경하는 방법을 포함한 컬렉션 모드 간의 차이점에 대한 자세한 내용은 컬렉션 모드 선택을 참조하세요.

참고 항목

CLI를 통해서 진단 설정을 구성하는 것도 가능합니다. 이러한 경우 클러스터의 프로비저닝 상태를 확인하지 않으므로 성공적으로 작동하도록 보장되지 않습니다. 구성한 후에는 클러스터의 진단 설정을 반드시 확인하여 반영하시기 바랍니다.

az monitor diagnostic-settings create --name AKS-Diagnostics --resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.ContainerService/managedClusters/my-cluster --logs '[{"category": "kube-audit","enabled": true}, {"category": "kube-audit-admin", "enabled": true}, {"category": "kube-apiserver", "enabled": true}, {"category": "kube-controller-manager", "enabled": true}, {"category": "kube-scheduler", "enabled": true}, {"category": "cluster-autoscaler", "enabled": true}, {"category": "cloud-controller-manager", "enabled": true}, {"category": "guard", "enabled": true}, {"category": "csi-azuredisk-controller", "enabled": true}, {"category": "csi-azurefile-controller", "enabled": true}, {"category": "csi-snapshot-controller", "enabled": true}]'  --workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace --export-to-resource-specific true

샘플 로그 쿼리

Important

AKS 클러스터 메뉴에서 로그를 선택하면 쿼리 범위가 현재 클러스터로 설정된 Log Analytics가 열립니다. 즉, 로그 쿼리에는 해당 리소스의 데이터만 포함됩니다. 다른 Azure 서비스의 데이터 또는 다른 클러스터의 데이터를 포함하는 쿼리를 실행하려면 Azure Monitor 메뉴에서 로그를 선택합니다. 자세한 내용은 Azure Monitor Log Analytics의 로그 쿼리 범위 및 시간 범위를 참조하세요.

클러스터의 진단 설정에서 Azure 진단 모드를 사용하는 경우 AKS에 대한 리소스 로그는 AzureDiagnostics 테이블에 저장됩니다. 범주 열로 서로 다른 로그를 구분할 수 있습니다. 각 범주에 대한 설명은 AKS 참조 리소스 로그를 참조하세요.

설명 로그 쿼리
각 범주에 대한 로그 수
(Azure 진단 모드)
AzureDiagnostics
| where ResourceType == "MANAGEDCLUSTERS"
| summarize count() by Category
모든 API 서버 로그
(Azure 진단 모드)
AzureDiagnostics
| where Category == "kube-apiserver"
시간 범위의 모든 kube-audit 로그
(Azure 진단 모드)
let starttime = datetime("2023-02-23");
let endtime = datetime("2023-02-24");
AzureDiagnostics
| where TimeGenerated between(starttime..endtime)
| where Category == "kube-audit"
| extend event = parse_json(log_s)
| extend HttpMethod = tostring(event.verb)
| extend User = tostring(event.user.username)
| extend Apiserver = pod_s
| extend SourceIP = tostring(event.sourceIPs[0])
| project TimeGenerated, Category, HttpMethod, User, Apiserver, SourceIP, OperationName, event
모든 감사 로그
(리소스별 모드)
AKSAudit
감사 이벤트 가져오기 및 나열을 제외한 모든 감사 로그
(리소스별 모드)
AKSAuditAdmin
모든 API 서버 로그
(리소스별 모드)
AKSControlPlane
| where Category == "kube-apiserver"

Log Analytics 작업 영역에서 미리 빌드된 쿼리 집합에 액세스하려면 Log Analytics 쿼리 인터페이스를 참조하고 리소스 종류 Kubernetes 서비스를 선택합니다. 컨테이너 인사이트에 대한 일반적인 쿼리 목록은 컨테이너 인사이트 쿼리를 참조하세요.

AKS 데이터 평면/Container Insights 로그

Container Insights는 컨테이너 및 Kubernetes 클러스터에서 다양한 유형의 원격 분석 데이터를 수집하여 AKS 클러스터에서 실행되는 컨테이너화된 애플리케이션을 모니터링하고, 문제를 해결하고, 인사이트를 얻는 데 도움을 줍니다. Container Insights에서 사용하는 테이블 목록 및 자세한 설명은 Azure Monitor 테이블 참조를 참조하세요. 이러한 테이블은 모두 로그 쿼리에 사용할 수 있습니다.

비용 최적화 설정은 사용자에게 컨테이너 인사이트 에이전트를 통해 수집된 메트릭 데이터를 사용자 지정하고 제어할 수 있도록 합니다. 이 기능은 Azure Monitor DCR(데이터 수집 규칙)을 통해 데이터 수집에서 제외할 개별 테이블 선택, 데이터 수집 간격 및 네임스페이스에 대한 데이터 수집 설정을 지원합니다. 이러한 설정은 수집량을 제어하고 컨테이너 인사이트의 모니터링 비용을 줄입니다. 컨테이너 인사이트 수집된 데이터는 다음 옵션을 사용하여 Azure Portal을 통해 사용자 지정할 수 있습니다. 모두(기본값) 이외의 옵션을 선택하면 컨테이너 인사이트 환경을 사용할 수 없게 됩니다.

그룹화 테이블 주의
모두(기본값) 모든 표준 컨테이너 인사이트 테이블 기본 컨테이너 인사이트 시각화를 사용하도록 설정하는 데 필요합니다.
성능 Perf, InsightsMetrics
로그 및 이벤트 ContainerLog 또는 ContainerLogV2, KubeEvents, KubePodInventory 관리형 Prometheus 메트릭을 사용하도록 설정한 경우 권장됩니다.
워크로드, 배포 및 HPA InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices
지속성 볼륨 InsightsMetrics, KubePVInventory

로그 및 이벤트 그룹화는 ContainerLog 또는 ContainerLogV2, KubeEvents, KubePodInventory 테이블에서 로그를 캡처하지만 메트릭은 캡처하지 않습니다. 메트릭을 수집하는 권장 경로는 AKS 클러스터에서 Prometheus용 Azure Monitor 관리형 서비스 Prometheus를 사용하도록 설정하고 데이터 시각화에 Azure Managed Grafana를 사용하는 것입니다. 자세한 내용은 Azure Monitor 작업 영역 관리를 참조하세요.

ContainerLogV2 스키마

Azure Monitor Container Insights는 권장되는 옵션인 ContainerLogV2라는 컨테이너 로그용 스키마를 제공합니다. 이 형식에는 AKS 및 Azure Arc 지원 Kubernetes 클러스터와 관련된 데이터를 보기 위한 일반적인 쿼리를 용이하게 하기 위해 다음 필드가 포함됩니다.

  • ContainerName
  • PodName
  • PodNamespace

또한 이 스키마는 표준 분석 로그에 대한 저렴한 대안을 제공하는 기본 로그 데이터 플랜과 호환됩니다. 기본 로그 데이터 계획을 사용하면 디버깅, 문제 해결 및 감사를 위해 Log Analytics 작업 영역에 대용량 자세한 정보 로그를 수집하고 저장하는 비용을 절감할 수 있습니다. 분석 및 경고에 대한 비용에는 영향을 주지 않습니다. 자세한 내용은 Log Analytics 작업 영역에서 테이블 관리를 참조하세요.

ContainerLogV2는 권장되는 접근 방식이며 ARM, Bicep, Terraform, Policy 및 Azure Portal을 사용하여 관리 ID 인증으로 컨테이너 인사이트를 온보딩하는 고객을 위한 기본 스키마입니다. 클러스터의 DCR(데이터 수집 규칙) 또는 ConfigMap을 통해 ContainerLogV2를 사용하도록 설정하는 방법에 대한 자세한 내용은 ContainerLogV2 스키마 사용을 참조하세요.

Azure 활동 로그

활동 로그에는 해당 리소스의 외부에서 볼 때 각 Azure 리소스에 대한 작업을 추적하는 구독 수준 이벤트(예: 새 리소스 만들기 또는 가상 머신 시작)가 포함되어 있습니다.

수집: 활동 로그 이벤트는 자동으로 생성되고 별도의 저장소에 수집되어 Azure Portal에서 볼 수 있습니다.

라우팅: 다른 로그 데이터와 함께 분석할 수 있도록 활동 로그 데이터를 Azure Monitor 로그로 보낼 수 있습니다. Azure Storage, Azure Event Hubs, 특정 Microsoft 모니터링 파트너와 같은 다른 위치도 사용할 수 있습니다. 활동 로그를 라우팅하는 방법에 대한 자세한 내용은 Azure 활동 로그 개요를 참조하세요.

AKS(Azure Kubernetes Service) 컨테이너 로그, 이벤트 및 Pod 메트릭을 실시간으로 보기

이 섹션에서는 Container Insights의 라이브 데이터 기능을 사용하여 AKS(Azure Kubernetes Service) 컨테이너 로그, 이벤트 및 Pod 메트릭을 실시간으로 보는 방법을 알아봅니다. 이 기능을 활용하면 kubectl logs -c, kubectl get 이벤트 및 kubectl top pods에 바로 액세스할 수 있으므로 문제를 실시간으로 해결하는 데 도움이 됩니다.

참고 항목

AKS는 Kubernetes 클러스터 수준 로깅 아키텍처를 사용합니다. 컨테이너 로그는 노드의 /var/log/containers 내에 있습니다. 노드에 액세스하려면 AKS(Azure Kubernetes Service) 클러스터 노드에 연결을 참조하세요.

라이브 데이터 기능을 설정하는 방법과 관련된 도움말은 Container Insights에서 라이브 데이터 구성을 참조하세요. 이 기능은 Kubernetes API에 직접 액세스합니다. 인증 모델에 대한 자세한 내용은 Kubernetes API를 참조하세요.

AKS 리소스 라이브 로그 보기

참고 항목

프라이빗 클러스터의 로그에 액세스하려면 클러스터와 동일한 프라이빗 네트워크의 컴퓨터에 있어야 합니다.

  1. Azure Portal에서 AKS 클러스터로 이동합니다.

  2. Kubernetes 리소스에서 워크로드를 선택합니다.

  3. 로그를 보려는 배포, Pod, 복제본 집합, 상태 저장 집합, 작업 또는 Cron 작업을 선택한 다음, 라이브 로그를 선택합니다.

  4. 로그를 보려는 리소스를 선택합니다.

    다음 예제에서는 Pod 리소스에 대한 로그를 보여 줍니다.

    라이브 로그의 배포를 보여 주는 스크린샷

라이브 로그 보기

컨테이너 엔진이 클러스터, 노드, 컨트롤러 또는 컨테이너에서 생성할 때 실시간 로그 데이터를 볼 수 있습니다.

  1. Azure Portal에서 AKS 클러스터로 이동합니다.

  2. 모니터링에서 인사이트를 선택합니다.

  3. 클러스터, 노드, 컨트롤러 또는 컨테이너 탭을 선택한 다음 로그를 보려는 개체를 선택합니다.

  4. 리소스 개요에서 라이브 로그를 선택합니다.

    참고 항목

    Log Analytics 작업 영역에서 데이터를 보려면 Log Analytics에서 로그 보기를 선택합니다. 기록 로그, 이벤트 및 메트릭을 보는 방법에 대한 자세한 내용은 Container Insights에서 로그를 쿼리하는 방법을 참조하세요.

    인증에 성공하면 데이터를 검색할 수 있으면 라이브 로그 탭으로 스트리밍을 시작합니다. 연속 스트림에서 로그 데이터를 볼 수 있습니다. 다음 이미지는 컨테이너 리소스에 대한 로그를 보여 줍니다.

    컨테이너 라이브 로그 뷰 데이터 옵션을 보여 주는 스크린샷.

라이브 이벤트 보기

컨테이너 엔진이 클러스터, 노드, 컨트롤러 또는 컨테이너에서 생성할 때 실시간 이벤트 데이터를 볼 수 있습니다.

  1. Azure Portal에서 AKS 클러스터로 이동합니다.

  2. 모니터링에서 인사이트를 선택합니다.

  3. 클러스터, 노드, 컨트롤러 또는 컨테이너 탭을 선택한 다음 이벤트를 보려는 개체를 선택합니다.

  4. 랩의 개요 페이지에서 라이브 이벤트를 선택합니다.

    참고 항목

    Log Analytics 작업 영역에서 데이터를 보려면 Log Analytics에서 이벤트 보기를 선택합니다. 기록 로그, 이벤트 및 메트릭을 보는 방법에 대한 자세한 내용은 Container Insights에서 로그를 쿼리하는 방법을 참조하세요.

    인증에 성공하면 데이터를 검색할 수 있으면 라이브 이벤트 탭으로 스트리밍을 시작합니다. 다음 이미지는 컨테이너 리소스에 대한 이벤트를 보여 줍니다.

    컨테이너 라이브 이벤트 뷰 데이터 옵션을 보여 주는 스크린샷.

메트릭 보기

컨테이너 엔진이 Pod 리소스를 선택하여 노드 또는 컨트롤러에서 생성할 때 실시간 메트릭 데이터를 볼 수 있습니다.

  1. Azure Portal에서 AKS 클러스터로 이동합니다.

  2. 모니터링에서 인사이트를 선택합니다.

  3. 노드 또는 컨트롤러 탭을 선택한 다음, 메트릭을 보려는 Pod 개체를 선택합니다.

  4. 랩의 개요 페이지에서 라이브 메트릭을 선택합니다.

    참고 항목

    Log Analytics 작업 영역에서 데이터를 보려면 Log Analytics에서 이벤트 보기를 선택합니다. 기록 로그, 이벤트 및 메트릭을 보는 방법에 대한 자세한 내용은 Container Insights에서 로그를 쿼리하는 방법을 참조하세요.

    인증에 성공하면 데이터를 검색할 수 있으면 라이브 메트릭 탭으로 스트리밍을 시작합니다. 다음 이미지에서는 Pod 리소스에 대한 메트릭을 보여 줍니다.

    Pod 라이브 메트릭 뷰 데이터 옵션을 보여 주는 스크린샷.

모니터링 데이터 분석

모니터링 데이터를 분석하기 위한 많은 도구가 있습니다.

Azure Monitor 도구

Azure Monitor는 다음과 같은 기본 도구를 지원합니다.

더 복잡한 시각화를 허용하는 도구는 다음과 같습니다.

  • 대시보드: 다양한 종류의 데이터를 Azure Portal에서 하나의 창에 결합할 수 있습니다.
  • 통합 문서: Azure Portal에서 만들 수 있는 사용자 지정 가능한 보고서입니다. 통합 문서에는 텍스트, 메트릭, 로그 쿼리가 포함될 수 있습니다.
  • Grafana: 뛰어난 운영 대시보드를 제공하는 개방형 플랫폼 도구입니다. Grafana를 사용하여 Azure Monitor 외의 여러 소스에서 온 데이터를 포함하는 대시보드를 만들 수 있습니다.
  • Power BI: 다양한 데이터 소스에서 대화형 시각화를 제공하는 비즈니스 분석 서비스입니다. Azure Monitor에서 자동으로 로그 데이터를 가져오도록 Power BI를 구성하여 이러한 시각화를 활용할 수 있습니다.

Azure Monitor 내보내기 도구

다음 방법을 사용하여 Azure Monitor에서 다른 도구로 데이터를 내보낼 수 있습니다.

Azure Monitor용 REST API를 시작하려면 Azure 모니터링 REST API 연습을 참조하세요.

Azure Portal의 모니터링 개요 페이지

AKS 클러스터 리소스에 대한 개요 페이지의 모니터링 탭은 Azure Portal에서 모니터링 데이터를 빠르게 볼 수 있는 방법을 제공합니다. 이 탭에는 노드 풀로 구분된 클러스터에 대한 공통 메트릭이 있는 그래프가 포함되어 있습니다. 이러한 그래프를 선택하여 메트릭 탐색기에서 데이터를 추가로 분석할 수 있습니다.

모니터링 탭에는 클러스터에 대한 관리되는 PrometheusContainer Insights에 대한 링크도 포함되어 있습니다. 이러한 도구를 사용하도록 설정해야 하는 경우 여기에서 사용하도록 설정할 수 있습니다. 클러스터 모니터링을 개선하기 위해 다른 기능을 사용하도록 권장하는 배너가 화면 맨 위에 표시될 수도 있습니다.

Azure Portal 홈페이지에서 Azure Monitor를 선택하여 구독의 모든 AKS 클러스터에 대한 모니터링 기능에 액세스할 수 있습니다.

Kusto 쿼리

KQL(Kusto 쿼리 언어)을 사용하여 Azure Monitor 로그/로그 분석 저장소에서 모니터링 데이터를 분석할 수 있습니다.

Important

포털의 서비스 메뉴에서 로그를 선택하면 쿼리 범위가 현재 서비스로 설정된 상태로 로그 분석이 열립니다. 이 범위는 로그 쿼리에 해당 유형의 리소스의 데이터만 포함된다는 의미입니다. 다른 Azure 서비스의 데이터를 포함하는 쿼리를 실행하려면 Azure Monitor 메뉴에서 로그를 선택합니다. 자세한 내용은 Azure Monitor Log Analytics의 로그 쿼리 범위 및 시간 범위를 참조하세요.

모든 서비스에 대한 일반적인 쿼리 목록은 로그 분석 쿼리 인터페이스를 참조하세요.

경고

Azure Monitor 경고는 모니터링 데이터에서 특정한 조건이 발견될 때 사용자에게 사전에 알립니다. 경고를 통해 사용자에게 알리기 전에 시스템 문제를 식별하고 해결할 수 있습니다. 자세한 내용은 Azure Monitor 경고을 참조하세요.

Azure 리소스에 대한 일반적인 경고의 소스에는 여러 가지가 있습니다. Azure 리소스에 대한 일반적인 경고의 예는 샘플 로그 경고 쿼리를 참조하세요. AMBA(Azure Monitor 기준 경고) 사이트는 중요한 플랫폼 메트릭 경고, 대시보드 및 지침을 구현하는 반자동 방법을 제공합니다. 이 사이트는 ALZ(Azure 랜딩 존)의 일부인 전체 서비스를 포함하여 지속적으로 확장되는 Azure 서비스 하위 집합에 적용됩니다.

공통 경고 스키마는 Azure Monitor 경고 알림의 사용을 표준화합니다. 자세한 내용은 일반 경고 스키마를 참조하세요.

경고 유형

Azure Monitor 데이터 플랫폼의 모든 메트릭 또는 로그 데이터 원본에 대해 경고할 수 있습니다. 모니터링하는 서비스 및 수집하는 모니터링 데이터에 따라 다양한 유형의 경고가 있습니다. 서로 다른 형식의 경고에는 다양한 장점과 단점이 있습니다. 자세한 내용은 올바른 모니터링 경고 유형 선택을 참조하세요.

다음 목록에서는 만들 수 있는 Azure Monitor 경고의 유형에 대해 설명합니다.

  • 메트릭 경고는 정기적으로 리소스 메트릭을 평가합니다. 메트릭은 플랫폼 메트릭, 사용자 지정 메트릭, 메트릭으로 변환된 Azure Monitor의 로그 또는 Application Insights 메트릭일 수 있습니다. 메트릭 경고는 여러 조건과 동적 임계값을 적용할 수도 있습니다.
  • 로그 경고를 사용하면 사용자가 로그 분석 쿼리를 사용하여 미리 정의된 빈도로 리소스 로그를 평가할 수 있습니다.
  • 활동 로그 경고는 정의된 조건과 일치하는 새 활동 로그 이벤트가 발생할 때 트리거됩니다. Resource Health 경고 및 Service Health 경고는 서비스 및 Resource Health를 보고하는 활동 로그 경고입니다.

일부 Azure 서비스는 스마트 검색 경고, Prometheus 경고 또는 권장 경고 규칙도 지원합니다.

일부 서비스의 경우 동일한 Azure 지역에 존재하는 동일한 형식의 여러 리소스에 동일한 메트릭 경고 규칙을 적용하여 대규모로 모니터링할 수 있습니다. 모니터링되는 각 리소스에 대해 개별 알림이 전송됩니다. 지원되는 Azure 서비스 및 클라우드에 대한 내용은 하나의 경고 규칙을 사용하여 여러 리소스 모니터링을 참조하세요.

일부 Azure 서비스의 경우 권장되는 기본 경고 규칙을 사용하도록 설정할 수 있습니다.

시스템은 다음을 기반으로 권장되는 경고 규칙 목록을 컴파일합니다.

  • 리소스를 모니터링하는 데 중요한 신호 및 임계값에 대한 리소스 공급자의 지식.
  • 이 리소스에 대해 고객이 일반적으로 경고하는 내용을 알려 주는 데이터.

참고 항목

권장 경고 규칙은 다음에 대해 사용할 수 있습니다.

  • 가상 머신
  • AKS(Azure Kubernetes Service) 리소스
  • Log Analytics 작업 영역

Prometheus 메트릭 기반 경고

클러스터에 대해 Prometheus 메트릭 컬렉션을 사용하도록 설정하면 권장되는 Prometheus 경고 규칙 컬렉션을 다운로드할 수 있습니다. 이 다운로드에는 다음 규칙이 포함됩니다.

수준 경고
클러스터 수준 KubeCPUQuotaOvercommit
KubeMemoryQuotaOvercommit
KubeContainerOOMKilledCount
KubeClientErrors
KubePersistentVolumeFillingUp
KubePersistentVolumeInodesFillingUp
KubePersistentVolumeErrors
KubeContainerWaiting
KubeDaemonSetNotScheduled
KubeDaemonSetMisScheduled
KubeQuotaAlmostFull
노드 수준 KubeNodeUnreachable
KubeNodeReadinessFlapping
Pod 수준 KubePVUsageHigh
KubeDeploymentReplicasMismatch
KubeStatefulSetReplicasMismatch
KubeHpaReplicasMismatch
KubeHpaMaxedOut
KubePodCrashLooping
KubeJobStale
KubePodContainerRestart
KubePodReadyStateLow
KubePodFailedState
KubePodNotReadyByController
KubeStatefulSetGenerationMismatch
KubeJobFailed
KubeContainerAverageCPUHigh
KubeContainerAverageMemoryHigh
KubeletPodStartUpLatencyHigh

컨테이너 인사이트에서 로그 경고를 만드는 방법컨테이너 인사이트에서 로그를 쿼리하는 방법을 참조하세요. 로그 경고는 다양한 시나리오에서 모니터링하는 데 사용할 수 있는 두 가지 항목을 측정할 수 있습니다.:

  • 결과 수: 쿼리에서 반환된 행 수를 계산하고 Windows 이벤트 로그, Syslog, 애플리케이션 예외와 같은 이벤트를 처리하는 데 사용할 수 있습니다.
  • 값 계산: 숫자 열을 기반으로 계산을 수행하며 원하는 수의 리소스를 포함하는 데 사용할 수 있습니다. 예를 들어, CPU 백분율이 있습니다.

필요한 경고 시나리오에 따라 now 연산자를 사용하고 1시간 뒤로 이동하여 DateTime과 현재 시간을 비교하면서 로그 쿼리를 만들어야 합니다. 로그 기반 경고를 빌드하는 방법을 알아보려면 Container Insights에서 로그 경고 만들기를 참조하세요.

AKS 경고 규칙

다음 표에는 AKS에 대한 몇 가지 제안된 경고 규칙이 나와 있습니다. 이러한 경고는 예제일 뿐입니다. Azure Kubernetes Service 모니터링 데이터 참조에 나열된 메트릭, 로그 항목 또는 활동 로그 항목에 대한 경고를 설정할 수 있습니다.

조건 설명
CPU 사용 백분율 > 95 모든 노드의 평균 CPU 사용량이 임계값을 초과할 때 발생합니다.
메모리 작업 집합 백분율 > 100 모든 노드의 평균 작업 집합이 임계값을 초과할 때 발생합니다.

Advisor 권장 사항

일부 서비스의 경우 리소스 작업 중에 위험한 상태 또는 임박한 변경 사항이 발생하는 경우 해당 서비스에서 포털의 개요 페이지에 경고가 표시됩니다. 왼쪽 메뉴의 모니터링 아래 Advisor 권장 사항에서 해당 경고에 대한 자세한 정보와 권장 수정 사항을 찾을 수 있습니다. 정상적으로 작동하는 중에는 Advisor 권장 사항이 표시되지 않습니다.

Azure Advisor에 대한 자세한 내용은 Azure Advisor 개요를 참조하세요.

참고 항목

서비스에서 실행되는 애플리케이션을 만들거나 실행하는 경우 Azure Monitor 애플리케이션 정보는 더 많은 형식의 경고를 제공할 수 있습니다.

네트워크 가시성

네트워크 관찰성은 정상적이고 성능이 뛰어난 Kubernetes 클러스터를 유지하는 데 중요한 부분입니다. 네트워크 트래픽에 대한 데이터를 수집하고 분석하면 클러스터가 어떻게 작동하는지에 대한 인사이트를 얻을 수 있으며 중단이나 성능 저하가 발생하기 전에 잠재적인 문제를 식별할 수 있습니다.

네트워크 관찰성 추가 기능을 사용하도록 설정하면 유용한 메트릭을 수집하고 Prometheus 형식으로 변환한 다음, Grafana에서 시각화할 수 있습니다. 사용하도록 설정하면 수집된 메트릭이 Prometheus용 Azure Monitor 관리형 서비스에 자동으로 수집됩니다. Grafana 대시보드는 Grafana 퍼블릭 대시보드 리포지토리에서 Prometheus에 수집된 네트워크 관찰성 메트릭을 시각화할 수 있습니다. 자세한 내용은 네트워크 관찰 가능성 설정을 참조하세요.