컨테이너 인사이트에 대한 모니터링 비용 이해

  • 아티클

이 문서에서는 다음을 이해하는 데 도움이 되도록 컨테이너 인사이트에 대한 가격 책정 지침을 제공합니다.

  • 하나 이상의 컨테이너에 대해 컨테이너 인사이트를 사용하도록 설정한 후 비용을 측정하세요.
  • 데이터 수집을 제어하고 비용을 절감합니다.

팁

Azure Monitor 비용을 줄이기 위한 전략은 비용 최적화 및 Azure Monitor를 참조하세요.

Azure Monitor 가격 책정 모델은 주로 Log Analytics 작업 영역에 매일 기가바이트 단위로 수집되는 데이터의 양을 기반으로 합니다. Log Analytics 작업 영역의 비용은 수집된 데이터 볼륨만을 기반으로 하지 않으며, 선택한 계획 및 클러스터에서 생성된 데이터를 저장하기 위해 선택한 기간에 따라서도 달라집니다.

참고 항목

기능을 사용하도록 설정하기 전에 Azure Monitor 비용 예측을 참조하여 Container Insights에 대한 비용을 예측하세요.

컨테이너 인사이트를 사용하여 Kubernetes 클러스터에서 수집하는 다음 유형의 데이터는 비용에 영향을 미치고 사용량에 따라 사용자 지정할 수 있습니다.

  • 성능, 인벤토리, InsightsMetrics, KubeEvents는 비용 최적화 설정을 통해 제어할 수 있습니다.
  • 에이전트 ConfigMap을 통해 클러스터의 모든 Kubernetes 네임스페이스에 있는 모니터링되는 모든 컨테이너의 stdout, stderr 컨테이너 로그
  • 클러스터에서 모니터링되는 모든 컨테이너의 컨테이너 환경 변수
  • 모니터링이 필요하지 않은 클러스터의 완료된 Kubernetes 작업/Pod
  • Prometheus 메트릭의 활성 스크래핑
  • kube-apiserver 및 kube-controller-manager와 같은 주요 구성 요소에 의해 생성된 로그 데이터를 분석하기 위한 AKS(Azure Kubernetes Service) 클러스터에 있는 Kubernetes 기본 노드 로그의 리소스 로그 컬렉션.

비용 절감을 위한 처리 제어

조직의 여러 사업부가 Kubernetes 인프라와 Log Analytics 작업 영역을 공유하는 시나리오를 고려해 보겠습니다. 각 사업부를 Kubernetes 네임스페이스로 구분합니다. 데이터 사용량 Runbook을 사용하여 각 작업 영역에서 수집되는 데이터의 양을 시각화할 수 있습니다. Runbook은 보고서 탭에서 사용할 수 있습니다.

Screenshot that shows the View Workbooks dropdown list.

이 통합 문서를 사용하면 설명서에서 공유하는 쿼리 라이브러리를 직접 작성하지 않고도 데이터 원본을 시각화할 수 있습니다. 이 통합 문서에서는 다음과 같은 청구 가능한 데이터를 표시하는 차트를 볼 수 있습니다.

  • 솔루션별로 수집된 총 청구 가능한 데이터(GB)입니다.
  • 컨테이너 로그(애플리케이션 로그)별로 수집된 청구 가능한 데이터입니다.
  • Kubernetes 네임스페이스별로 수집된 청구 가능한 컨테이너 로그 데이터입니다.
  • 클러스터 이름별로 구분하여 수집된 청구 가능한 컨테이너 로그 데이터입니다.
  • 로그 소스 항목별로 수집된 청구 가능한 컨테이너 로그 데이터입니다.
  • 진단 기본 노드 로그별로 수집된 청구 가능한 진단 데이터입니다.

Screenshot that shows the Data Usage workbook.

통합 문서에 대한 권한을 관리하는 방법에 대한 자세한 내용은 액세스 제어를 검토하세요.

데이터 수집의 근본 원인 파악

컨테이너 인사이트 데이터는 주로 메트릭 카운터(Perf, Inventory, InsightsMetrics, 사용자 지정 메트릭)와 로그(ContainerLog)로 구성됩니다. 클러스터 사용량과 크기에 따라 요구 사항과 모니터링 요구 사항이 다를 수 있습니다.

데이터 사용량 통합 문서의 테이블별 섹션으로 이동하여 컨테이너 인사이트에 대한 테이블 크기 분석을 확인할 수 있습니다.

Screenshot that shows the By Table breakdown in Data Usage workbook.

대부분의 데이터가 다음 테이블 중 하나에서 제공되는 경우:

  • 성능
  • InsightsMetrics
  • ContainerInventory
  • ContainerNodeInventory
  • KubeNodeInventory
  • KubePodInventory
  • KubePVInventory
  • KubeServices
  • KubeEvents

비용 최적화 설정을 사용하거나 Prometheus 메트릭 추가 기능으로 마이그레이션하여 수집을 조정할 수 있습니다.

그러지 않으면 대부분의 데이터가 ContainerLog 테이블에 속합니다. 아래 단계에 따라 ContainerLog 비용을 줄일 수 있습니다.

ContainerLog 비용 절감

어떤 원본이 요구 사항을 초과하는 데이터를 생성하는지 확인하기 위한 분석을 완료한 후 데이터 수집을 다시 구성할 수 있습니다. stdout, stderr, 환경 변수의 컬렉션을 구성하는 방법에 대한 자세한 내용은 에이전트 데이터 수집 설정 구성을 참조하세요.

다음 예제는 비용을 제어할 수 있도록 ConfigMap 파일을 수정하여 클러스터에 적용할 수 있는 변경 내용을 보여 줍니다.

  1. 메트릭을 풀하는 Azure 컨테이너 인사이트 서비스에 대한 ConfigMap 파일에서 다음 코드를 수정하여 클러스터의 모든 네임스페이스에서 stdout 로그를 사용하지 않도록 설정합니다.

    [log_collection_settings]       
   [log_collection_settings.stdout]          
      enabled = false

  2. 개발 네임스페이스에서 stderr 로그 수집을 사용하지 않도록 설정합니다. 예제는 dev-test입니다. ConfigMap 파일에서 다음 코드를 수정하여 prod 및 default와 같은 다른 네임스페이스에서 stderr 로그를 계속 수집합니다.

    참고 항목

    기본적으로 kube-system 로그 컬렉션은 사용되지 않습니다. 기본 설정은 유지됩니다. 기본 설정은 유지되며, 제외 네임스페이스 목록에 dev-test 네임스페이스를 추가하는 것이 stderr 로그 컬렉션에 적용됩니다.

    [log_collection_settings.stderr]          
   enabled = true          
      exclude_namespaces = ["kube-system", "dev-test"]

  3. ConfigMap 파일에서 다음을 수정하여 클러스터에서 환경 변수 컬렉션을 사용하지 않도록 설정합니다. 이 수정 사항은 모든 Kubernetes 네임스페이스의 모든 컨테이너에 적용됩니다.

    [log_collection_settings.env_var]
    enabled = false

  4. 완료된 작업을 정리하려면 작업 정의 yaml에서 정리 정책을 지정합니다. 다음은 정리 정책을 사용하는 작업 정의 예제입니다. 자세한 내용은 Kubernetes 설명서를 참조하세요.

    apiVersion: batch/v1
kind: Job
metadata:
  name: pi-with-ttl
spec:
  ttlSecondsAfterFinished: 100

이 변경 내용 중 하나 이상을 ConfigMap에 적용한 후 kubectl apply -f <config3. map_yaml_file.yaml> 명령을 사용하여 클러스터에 적용합니다. 예를 들어, kubectl apply -f container-azm-ms-agentconfig.yaml 명령을 실행하여 기본 편집기에서 파일을 열고 수정한 후 저장합니다.

기본 로그 구성

주로 기본 로그로 디버깅, 문제 해결, 감사에 사용하는 Log Analytics 작업 영역의 ContainerLog에서 데이터 수집 비용을 절감할 수 있습니다. 기본 로그의 제한을 비롯한 자세한 내용은 Azure Monitor에서 기본 로그 구성을 참조하세요. ContainerLogV2는 Container Insights에서 사용하는 기본 로그의 구성 버전입니다. ContainerLogV2에는 자세한 텍스트 기반 로그 레코드가 포함됩니다.

기본 로그를 구성하려면 ContainerLogV2 스키마에 있어야 합니다. 자세한 내용은 ContainerLogV2 스키마 사용(미리 보기)을 참조하세요.

Prometheus 메트릭 스크래핑

참고 항목

이 섹션에서는 Log Analytics 작업 영역의 Prometheus 메트릭 수집에 대해 설명합니다. 이 정보는 Managed Prometheus를 사용하여 Prometheus 메트릭을 제거하는 경우에는 적용되지 않습니다.

Log Analytics 작업 영역에서 Prometheus 메트릭을 수집하는 경우 클러스터에서 수집하는 메트릭 수를 제한해야 합니다.

  • 스크래핑 빈도가 최적으로 설정되어 있는지 확인합니다. 기본값은 60초입니다. 주기를 15초로 늘릴 수 있지만, 스크래핑하는 메트릭이 해당 주기로 게시되는지 확인해야 합니다. 그러지 않으면 많은 중복 메트릭이 스크랩되어 일정한 간격으로 Log Analytics 작업 영역으로 전송되는데, 이에 따라 데이터 수집 및 보존 비용이 늘어나지만 가치는 그에 미치지 못합니다.
  • 컨테이너 인사이트는 메트릭 이름별로 제외 및 포함 목록을 지원합니다. 예를 들어 클러스터에서 kubedns 메트릭을 스크래핑하는 경우 기본적으로 수백 개의 메트릭이 스크래핑될 수 있습니다. 하지만 메트릭의 하위 집합에만 관심이 있을 가능성이 큽니다. 스크랩할 메트릭 목록을 지정했는지 확인하거나, 데이터 수집 볼륨을 줄이기 위해 몇 가지를 제외한 나머지 메트릭을 제외합니다. 스크래핑을 사용하도록 설정하고 많은 메트릭을 사용하지 않는 것은 Log Analytics 청구서에 요금만 추가로 발생하게 됩니다.
  • Pod 주석을 스크래핑할 때 네임스페이스별로 필터링하여 사용하지 않는 네임스페이스에서 Pod 메트릭의 스크래핑을 제외해야 합니다. 예를 들어 dev-test 네임스페이스가 있습니다.

Kubernetes 클러스터에서 수집되는 데이터

메트릭 데이터

컨테이너 인사이트는 Log Analytics 작업 영역에서 로그 데이터로 기록되어 수집된 미리 정의된 메트릭 및 인벤토리 항목 세트를 포함합니다. 다음 표의 모든 메트릭은 1분마다 수집됩니다.

Type 메트릭
노드 메트릭 cpuUsageNanoCores
cpuCapacityNanoCores
cpuAllocatableNanoCores
memoryRssBytes
memoryWorkingSetBytes
memoryCapacityBytes
memoryAllocatableBytes
restartTimeEpoch
used(디스크)
free(디스크)
used_percent(디스크)
io_time(diskio)
writes(diskio)
reads(diskio)
write_bytes(diskio)
write_time(diskio)
iops_in_progress(diskio)
read_bytes(diskio)
read_time(diskio)
err_in(net)
err_out(net)
bytes_recv(net)
bytes_sent(net)
Kubelet_docker_operations(kubelet)
컨테이너 메트릭 cpuUsageNanoCores
cpuRequestNanoCores
cpuLimitNanoCores
memoryRssBytes
memoryWorkingSetBytes
memoryRequestBytes
memoryLimitBytes
restartTimeEpoch

클러스터 인벤토리

다음 목록은 기본적으로 수집되는 클러스터 인벤토리 데이터입니다.

  • KubePodInventory – 분당 Pod당 1
  • KubeNodeInventory – 분당 노드당 1
  • KubeServices – 분당 서비스당 1
  • ContainerInventory – 분당 컨테이너당 1

다음 단계

컨테이너 인사이트를 사용하여 수집된 데이터의 최근 사용 패턴을 기반으로 하는 비용을 파악하는 방법에 대한 자세한 내용은 Log Analytics 작업 영역에서 사용량 분석을 참조하세요.