다음을 통해 공유


Log Analytics에 대한 Azure Well-Architected Framework 관점

Well-Architected Framework 워크로드 기능 및 성능은 다양한 방법으로 다양한 이유로 모니터링되어야 합니다. Azure Monitor Log Analytics 작업 영역은 모니터링 데이터의 상당 부분에 대한 기본 로그 및 메트릭 싱크입니다. 작업 영역은 임시 쿼리, 시각화 및 경고를 포함하여 Azure Monitor의 여러 기능을 지원합니다. 일반적인 모니터링 원칙은 모니터링 및 진단 지침을 참조하세요. 이 지침은 일반적인 모니터링 원칙을 제공합니다. 다양한 유형의 데이터를 식별합니다. Azure Monitor에서 지원하는 필수 분석을 식별하고 분석을 가능하게 하는 작업 영역에 저장된 데이터도 식별합니다.

이 문서에서는 시스템 디자인 원칙을 이해한다고 가정합니다. 또한 운영 워크로드 데이터를 채우는 Azure Monitor의 Log Analytics 작업 영역 및 기능에 대한 실무 지식이 필요합니다. 자세한 내용은 Log Analytics 작업 영역 개요를 참조하세요.

중요

이 가이드를 사용하는 방법

각 섹션에는 기술 scope 지역화된 디자인 전략과 함께 관심 있는 아키텍처 영역을 제공하는 디자인 검사 목록이 있습니다.

또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능 또는 배포 토폴로지에 대한 권장 사항 도 포함되어 있습니다. 권장 사항은 Log Analytics 작업 영역 및 관련 Azure Monitor 리소스에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나, 워크로드 모니터링 환경을 설계하거나, 기존 워크로드 모니터링 솔루션을 최적화합니다.

기술 scope

이 가이드에서는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.

  • Log Analytics 작업 영역
  • 워크로드 운영 로그 데이터
  • 워크로드의 Azure 리소스에 대한 진단 설정

안정성

안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을 구축하여 지속적인 기능을 제공하는 것입니다.

안정성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 디자인 전략을 제공합니다.

Log Analytics 작업 영역에 대해 고려해야 할 안정성 상황은 다음과 같습니다.

  • 작업 영역의 가용성.
  • Azure 데이터 센터 또는 지역 오류의 드문 경우 수집된 데이터를 보호합니다.

현재 다른 지역의 작업 영역 간에 장애 조치(failover)에 대한 표준 기능은 없지만 가용성 또는 규정 준수에 대한 특정 요구 사항이 있는 경우 사용할 전략이 있습니다.

안정성을 위한 디자인 검사 목록

안정성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 VM(가상 머신)의 SKU 및 기능 및 종속성을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • Log Analytics 작업 영역에 대한 서비스 제한을 검토합니다. 서비스 제한 섹션은 데이터 수집 및 보존 및 서비스의 다른 측면에 대한 제한을 이해하는 데 도움이 됩니다. 이러한 제한은 워크로드 가시성 전략을 올바르게 설계하는 방법을 결정하는 데 도움이 됩니다. 쿼리와 같이 많은 함수가 Log Analytics 작업 영역과 함께 작동하므로 Azure Monitor 서비스 제한을 검토해야 합니다.
  • 작업 영역 복원력 및 복구를 계획합니다. Log Analytics 작업 영역은 지역 간 중복성 또는 복제를 기본적으로 지원하지 않는 지역입니다. 또한 가용성 영역 중복 옵션은 제한됩니다. 따라서 작업 영역의 안정성 요구 사항을 결정하고 이러한 목표를 충족하도록 전략을 설 계획해야 합니다. 요구 사항에 따라 작업 영역이 데이터 센터 오류 또는 지역 오류에 대해 복원력이 있어야 한다고 규정하거나 장애 조치(failover) 지역의 새 작업 영역으로 데이터를 복구할 수 있어야 한다고 규정할 수 있습니다. 이러한 각 시나리오는 성공하려면 추가 리소스와 프로세스를 마련해야 하므로 안정성 목표와 비용 및 복잡성의 균형을 신중하게 고려해야 합니다.
  • 안정성 요구 사항을 충족할 올바른 배포 지역을 선택합니다. 운영 데이터를 내보내는 워크로드 구성 요소와 함께 배치된 Log Analytics 작업 영역 및 DCE(데이터 수집 엔드포인트)를 배포합니다. 작업 영역 및 DCE를 배포할 적절한 지역을 선택한 경우 워크로드를 배포하는 위치를 알려야 합니다. 전용 클러스터와 같은 특정 Log Analytics 기능의 지역 가용성을 워크로드의 안정성, 비용 및 성능 요구 사항의 핵심인 다른 요소와 비교해야 할 수 있습니다.
  • 가시성 시스템이 정상인지 확인합니다. 워크로드의 다른 구성 요소와 마찬가지로 모니터링 및 로깅 시스템이 제대로 작동하는지 확인합니다. 이를 위해 운영 팀에 상태 데이터 신호를 보내는 기능을 사용하도록 설정합니다. Log Analytics 작업 영역 및 관련 리소스와 관련된 상태 데이터 신호를 설정합니다.

안정성에 대한 구성 권장 사항

권장 이점
워크로드의 중요한 경로에 Log Analytics 작업 영역을 포함하지 마세요. 작업 영역은 작동하는 가시성 시스템에 중요하지만 워크로드의 기능은 이에 의존해서는 안 됩니다. 작업 영역 및 관련 함수를 워크로드의 중요한 경로에서 벗어나게 하면 관찰 시스템에 영향을 주는 문제가 워크로드의 런타임 실행에 영향을 주지 않을 위험이 최소화됩니다.
작업 영역 데이터의 높은 내구성을 지원하려면 데이터 복원력을 지원하는 지역에 Log Analytics 작업 영역을 배포합니다. 데이터 복원력은 작업 영역을 동일한 지역의 전용 클러스터 에 연결하는 경우에만 가능합니다. 전용 클러스터를 사용하면 데이터 센터 중단에 대한 보호를 제공하는 가용성 영역에 연결된 작업 영역을 분산할 수 있습니다. 전용 클러스터를 정당화하기 위해 충분한 데이터를 지금 수집하지 않으면 이러한 선제적 지역 선택이 향후 성장을 지원합니다.
워크로드에 근접하여 작업 영역 배포를 선택합니다.

Log Analytics 작업 영역과 동일한 지역에서 DCE(데이터 수집 엔드포인트)를 사용합니다.
워크로드 인스턴스와 동일한 지역에 작업 영역을 배포합니다. 작업 영역과 DCE를 워크로드와 동일한 지역에 두면 다른 지역의 중단으로 인한 영향의 위험을 완화할 수 있습니다.

DCE는 Azure Monitor 에이전트 및 Logs 수집 API에서 작업 작업 데이터를 Log Analytics 작업 영역으로 보내는 데 사용됩니다. 배포에 단일 작업 영역만 있는 경우에도 여러 DCE가 필요할 수 있습니다. 특정 환경에 대해 DCE를 구성하는 방법에 대한 자세한 내용은 배포에 따라 데이터 수집 엔드포인트를 설정하는 방법을 참조하세요.<Br
워크로드가 활성-활성 디자인에 배포된 경우 워크로드가 배포된 지역에 분산된 여러 작업 영역 및 DCE를 사용하는 것이 좋습니다.

여러 지역에 작업 영역을 배포하면 환경에 복잡성이 추가됩니다. Log Analytics 작업 영역 아키텍처 설계에 설명된 조건과 가용성 요구 사항의 균형을 조정합니다.
지역 오류에서 작업 영역을 사용할 수 있어야 하거나 전용 클러스터에 대한 충분한 데이터를 수집하지 않는 경우 다른 지역의 여러 작업 영역에 중요한 데이터를 보내도록 데이터 수집을 구성합니다. 이 사례를 로그 멀티캐스팅이라고도 합니다.

예를 들어 VM에서 실행되는 Azure Monitor 에이전트에 대해 여러 작업 영역에 대해 DCR을 구성합니다. Azure 리소스에서 리소스 로그를 수집하고 로그를 여러 작업 영역으로 보내도록 여러 진단 설정을 구성합니다.
이러한 방식으로 워크로드 운영 데이터는 지역별 오류가 있는 경우 대체 작업 영역에서 사용할 수 있습니다. 그러나 경고 및 통합 문서와 같은 데이터를 사용하는 리소스는 다른 지역에 자동으로 복제되지 않습니다. 대체 작업 영역에 대한 구성을 사용하여 중요한 경고 리소스에 대한 ARM(Azure Resource Manager) 템플릿을 저장하거나 모든 지역에 배포하지만 중복 경고를 방지하기 위해 사용하지 않도록 설정하는 것이 좋습니다. 두 옵션 모두 지역별 오류에서 빠른 사용을 지원합니다.

절충: 이 구성으로 인해 중복 수집 및 보존 요금이 발생하므로 중요한 데이터에만 사용합니다.
데이터 센터 또는 지역 오류에서 데이터를 보호해야 하는 경우 작업 영역에서 데이터 내보내 기를 구성하여 대체 위치에 데이터를 저장합니다.

이 옵션은 데이터를 다른 작업 영역에 멀티캐스트하는 이전 옵션과 유사합니다. 그러나 이 옵션은 추가 데이터가 스토리지에 기록되므로 비용이 적게 듭니다.

GRS(지역 중복 스토리지) 및 GZRS(지역 영역 중복 스토리지)를 포함한 Azure Storage 중복 옵션을 사용하여 이 데이터를 다른 지역에 추가로 복제합니다.

데이터 내보내기에서는 지역 수집 파이프라인에 영향을 미치는 인시던트에 대한 복원력을 제공하지 않습니다.
기록 운영 로그 데이터는 내보낸 상태에서 쉽게 쿼리할 수 없지만 데이터가 장기간 지역 가동 중단에서 유지되고 장기간 액세스 및 보존될 수 있도록 합니다.

데이터 내보내기에서 지원되지 않는 테이블 내보내기를 요구하는 경우 Logic Apps를 비롯한 다른 데이터 내보내기 방법을 사용하여 데이터를 보호할 수 있습니다.

이 전략이 실행 가능한 복구 계획으로 작동하려면 Azure 및 데이터를 제공하는 모든 에이전트에서 리소스에 대한 진단 설정을 다시 구성하는 프로세스가 있어야 합니다. 또한 내보낸 데이터를 새 작업 영역으로 수동으로 리하이딩할 계획도 있어야 합니다. 앞에서 설명한 옵션과 마찬가지로 경고 및 통합 문서와 같은 데이터를 사용하는 리소스에 대한 프로세스도 정의해야 합니다.
고가용성이 필요한 중요 업무용 워크로드의 경우 지역 오류가 있는 경우 여러 작업 영역을 사용하여 고가용성을 제공하는 페더레이션된 작업 영역 모델을 구현하는 것이 좋습니다. 중요 업무용 은 Azure에서 매우 신뢰할 수 있는 애플리케이션을 설계하기 위한 규범적인 모범 사례 지침을 제공합니다. 디자인 방법론에는 여러 Log Analytics 작업 영역이 있는 페더레이션된 작업 영역 모델이 포함되어 Azure 지역의 실패를 포함하여 여러 오류가 있는 경우 고가용성을 제공합니다.

이 전략은 지역 간 송신 비용을 제거하고 지역 오류로 계속 작동합니다. 그러나 Azure에서 중요 업무용 워크로드의 상태 모델링 및 가시성에 설명된 구성 및 프로세스로 관리해야 하는 복잡성이 더 많이 필요합니다.
IaC(Infrastructure as Code)를 사용하여 작업 영역 및 관련 함수를 배포하고 관리합니다. 많은 배포와 복원력 및 복구를 위한 메커니즘을 실용적으로 자동화하면 이러한 작업이 안정적으로 유지됩니다. 운영 프로세스에서 중요한 시간을 절약하고 사용자 오류의 위험을 최소화합니다.

저장된 로그 쿼리와 같은 함수도 IaC를 통해 정의되어 복구가 필요한 경우 새 지역으로 복구해야 합니다.
DCR 규칙을 단순하게 유지하기 위해 단일 책임 원칙으로 DCR을 디자인합니다.

원본 시스템의 모든 입력, 규칙 및 대상과 함께 하나의 DCR을 로드할 수 있지만 데이터 원본을 적게 사용하는 좁게 초점을 맞춘 규칙을 설계하는 것이 좋습니다. 규칙 할당의 컴퍼지션을 사용하여 논리 대상에 대해 원하는 가시성 scope 도달합니다.

또한 DCR에서 변환 최소화
좁게 초점을 맞춘 DCR을 사용하면 규칙 구성이 잘못 구성되어 더 광범위한 영향을 미칠 위험이 최소화됩니다. DCR이 빌드된 scope만 효과를 제한합니다. 자세한 내용은 Azure Monitor에서 데이터 수집 규칙 만들기 및 관리에 대한 모범 사례를 참조하세요.

일부 상황에서는 변환이 강력하고 필요할 수 있지만 수행 중인 키워드(keyword) 쿼리 언어(KQL) 작업을 테스트하고 문제를 해결하는 것은 어려울 수 있습니다. 가능하면 원시 데이터를 수집하고 쿼리 시 변환 다운스트림을 처리하여 데이터 손실 위험을 최소화합니다.
일일 한도 또는 보존 정책을 설정할 때 필요한 로그를 수집하고 유지하여 안정성 요구 사항을 유지하고 있는지 확인합니다. 일일 한도는 지정된 양에 도달하면 작업 영역에 대한 데이터 수집을 중지하므로 수집 볼륨에 대한 제어를 유지하는 데 도움이 됩니다. 그러나 신중한 계획 후에만 이 기능을 사용합니다. 일일 한도가 규칙적으로 적중되지 않도록 합니다. 이 경우 한도가 너무 제한적으로 설정됩니다. 워크로드에서 발생하는 중요한 신호를 놓치지 않도록 일일 한도를 다시 구성해야 합니다.

마찬가지로 중요한 데이터를 실수로 잃지 않도록 데이터 보존 정책의 낮추기를 신중하고 신중하게 접근해야 합니다.
Log Analytics 작업 영역 인사이트를 사용하여 수집 볼륨, 수집된 데이터 대 데이터 대 데이터 한도, 응답하지 않는 로그 원본 및 다른 데이터 간의 실패한 쿼리를 추적합니다. 상태 상태 경고를 만들어 데이터 센터 또는 지역 오류로 인해 작업 영역을 사용할 수 없게 되면 사전에 알립니다. 이 전략을 사용하면 작업 영역의 상태를 성공적으로 모니터링하고 상태가 저하될 위험이 있는 경우 사전에 조치를 수행할 수 있습니다. 워크로드의 다른 구성 요소와 마찬가지로 상태 메트릭을 인식하고 시간이 지남에 따라 안정성을 개선하기 위해 추세를 식별할 수 있는 것이 중요합니다.

Azure Policy

Azure는 Log Analytics 작업 영역의 안정성과 관련된 정책을 제공하지 않습니다. 작업 영역이 전용 클러스터에 연결되도록 하는 등 작업 영역 배포를 중심으로 규정 준수 가드 레일을 빌드하는 사용자 지정 정책을 만들 수 있습니다.

Log Analytics 작업 영역의 안정성과 직접적인 관련이 없지만 사용 가능한 거의 모든 서비스에 대한 Azure 정책이 있습니다. 정책은 해당 서비스에 대해 진단 설정을 사용하도록 설정하고 서비스의 로그 데이터가 Log Analytics 작업 영역으로 흐르는지 확인합니다. 워크로드 아키텍처의 모든 서비스는 자체 안정성 요구 사항을 위해 로그 데이터를 Log Analytics 작업 영역으로 보내야 하며 정책은 이를 적용하는 데 도움이 될 수 있습니다. 마찬가지로 VM 및 Kubernetes와 같은 에이전트 기반 플랫폼에 에이전트가 설치되도록 하는 정책이 있습니다.

Azure Advisor

Azure는 Log Analytics 작업 영역의 안정성과 관련된 Azure Advisor 권장 사항을 제공하지 않습니다.

보안

보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보장을 제공하는 것입니다.

보안 디자인 원칙은 모니터링 및 로깅 솔루션과 관련된 기술 디자인에 접근 방식을 적용하여 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.

보안에 대한 디자인 검사 목록

보안에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 취약성 및 컨트롤을 식별하여 보안 태세를 개선합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • Azure Monitor 보안 기준Log Analytics 작업 영역에 대한 액세스 관리 topics 검토합니다. 이러한 topics 보안 모범 사례에 대한 지침을 제공합니다.
  • 세분화를 사용하여 작업 영역을 초석 원칙으로 배포합니다. 네트워킹, 데이터 및 액세스 수준에서 구분을 구현합니다. 분할은 안정성, 비용 최적화, 운영 우수성 및 성능 효율성에 대한 비즈니스 요구 사항을 충족하면서 작업 영역을 적절한 정도로 격리하고 가능한 최고 수준의 무단 액세스로부터 더 잘 보호되도록 하는 데 도움이 됩니다.
  • 작업 영역 읽기 및 쓰기 활동 및 관련 ID를 감사할 수 있는지 확인합니다. 공격자는 운영 로그를 보는 이점을 얻을 수 있습니다. 손상된 ID는 로그 삽입 공격으로 이어질 수 있습니다. Azure Portal 또는 API 상호 작용 및 관련 사용자를 통해 실행되는 작업에 대한 감사를 사용하도록 설정합니다. 작업 영역을 감사하도록 설정되지 않은 경우 organization 규정 준수 요구 사항을 위반할 위험이 있을 수 있습니다.
  • 강력한 네트워크 컨트롤을 구현합니다. 네트워크 격리 및 방화벽 기능을 통해 작업 영역 및 로그에 대한 네트워크 액세스를 보호합니다. 네트워크 컨트롤이 충분히 구성되지 않으면 권한이 없거나 악의적인 행위자가 액세스할 위험이 있습니다.
  • 불변성 또는 장기 보존이 필요한 데이터 형식을 결정합니다. 로그 데이터는 프로덕션 시스템 내의 워크로드 데이터와 동일한 엄격하게 처리되어야 합니다. 규정 준수 요구 사항에 따라 중요한 로그 데이터를 성공적으로 저장하도록 데이터 분류 사례에 로그 데이터를 포함합니다.
  • 암호화를 통해 미사용 로그 데이터를 보호합니다. 분할만으로는 로그 데이터의 기밀성을 완전히 보호할 수 없습니다. 무단 원시 액세스가 발생하는 경우 로그 데이터를 미사용 시 암호화하면 악의적인 행위자가 작업 영역 외부에서 해당 데이터를 사용하지 못하도록 방지할 수 있습니다.
  • 난독 처리를 통해 중요한 로그 데이터를 보호합니다. 프로덕션 시스템에 상주하는 워크로드 데이터와 마찬가지로 운영 로그에 의도적으로 또는 의도치 않게 존재할 수 있는 중요한 정보에 대해 기밀성이 유지되도록 추가 조치를 취해야 합니다. 난독 처리 방법을 사용하면 무단 눈에서 중요한 로그 데이터를 숨기는 데 도움이 됩니다.

보안에 대한 구성 권장 사항

권장 이점
작업 영역에서 데이터 및 저장된 쿼리를 보호하기 위해 사용자 고유의 암호화 키가 필요한 경우 고객 관리형 키를 사용합니다.

Azure Monitor를 사용하면 모든 데이터 및 저장된 쿼리가 MMK(Microsoft 관리형 키)를 사용하여 미사용 상태로 암호화됩니다. 고유한 암호화 키가 필요하고 전용 클러스터에 대한 충분한 데이터를 수집하는 경우 고객 관리형 키를 사용합니다. 키 수명 주기를 제어하고 데이터에 대한 액세스를 취소하는 기능을 위해 Azure Key Vault 고유한 키를 사용하여 데이터를 암호화할 수 있습니다.

Microsoft Sentinel을 사용하는 경우 Microsoft Sentinel 고객 관리형 키 설정의 고려 사항에 대해 잘 알고 있어야 합니다.
이 전략을 사용하면 Azure Key Vault 고유한 키를 사용하여 데이터를 암호화하고, 키 수명 주기를 제어하고, 데이터에 대한 액세스를 취소할 수 있습니다.
쿼리를 실행하는 사용자를 추적하도록 로그 쿼리 감사를 구성합니다.

운영 및 보안 데이터를 분리하는 경우 각 작업 영역에 대한 감사 로그를 로컬 작업 영역으로 보내거나 전용 보안 작업 영역에 통합하도록 구성합니다. Log Analytics 작업 영역 인사이트를 사용하여 이 데이터를 주기적으로 검토합니다. 권한이 없는 사용자가 쿼리를 실행하려고 하는 경우 사전에 알리기 위해 로그 쿼리 경고 규칙을 만드는 것이 좋습니다.
로그 쿼리 감사는 작업 영역에서 실행되는 각 쿼리에 대한 세부 정보를 기록합니다. 이 감사 데이터를 보안 데이터로 처리하고 LAQueryLogs 테이블을 적절하게 보호합니다. 이 전략은 무단 액세스가 발생할 경우 즉시 포착되도록 하여 보안 태세를 강화합니다.
프라이빗 네트워킹 및 세분화 측정값을 통해 작업 영역을 보호합니다.

프라이빗 링크 기능을 사용하여 로그 원본과 작업 영역 간의 통신을 프라이빗 네트워킹으로 제한합니다.
프라이빗 링크를 사용하면 지정된 작업 영역에 액세스할 수 있는 가상 네트워크를 제어하여 세분화를 통해 보안을 더욱 강화할 수 있습니다.
사용 가능한 경우 작업 영역 API 액세스에 API 키 대신 Microsoft Entra ID 사용합니다. 쿼리 API에 대한 API 키 기반 액세스는 클라이언트별 감사 내역을 남기지 않습니다. 프로그래밍 방식 액세스를 제대로 감사할 수 있도록 충분히 범위가 지정된 Entra ID 기반 액세스를 사용합니다.
organization 다양한 역할에 필요한 작업 영역의 다양한 데이터 형식에 대한 액세스를 구성합니다.

작업 영역에 대한 액세스 제어 모드리소스 또는 작업 영역 사용 권한으로 설정합니다. 이 액세스 제어를 사용하면 리소스 소유자가 리소스 컨텍스트 를 사용하여 작업 영역에 대한 명시적 액세스 권한을 부여하지 않고 데이터에 액세스할 수 있습니다.

여러 리소스에서 테이블 집합에 액세스해야 하는 사용자에 대해 테이블 수준 RBAC 를 사용합니다.
이 설정은 작업 영역 구성을 간소화하고 사용자가 사용하지 않아야 하는 운영 데이터에 액세스할 수 없도록 하는 데 도움이 됩니다.

적절한 기본 제공 역할을 할당하여 책임 scope 따라 구독, 리소스 그룹 또는 작업 영역 수준에서 관리자에게 작업 영역 권한을 부여합니다.

테이블 권한이 있는 사용자는 리소스 사용 권한에 관계없이 테이블의 모든 데이터에 액세스할 수 있습니다.

작업 영역의 데이터에 대한 액세스 권한을 부여하는 다양한 옵션에 대한 자세한 내용은 Log Analytics 작업 영역에 대한 액세스 관리를 참조하세요.
장기 보존 또는 불변성이 필요한 로그를 내보냅니다.

데이터 내보내기를 사용하여 데이터 변조로부터 보호하는 데 도움이 되는 불변성 정책을 사용하여 Azure Storage 계정에 데이터를 보냅니다. 모든 유형의 로그가 규정 준수, 감사 또는 보안과 동일한 관련성을 가지는 것은 아니므로 내보내야 하는 특정 데이터 형식을 결정합니다.
장기 보존이 필요한 규정의 적용을 받는 작업 영역에서 감사 데이터를 수집할 수 있습니다. Log Analytics 작업 영역의 데이터는 변경할 수 없지만 제거할 수 있습니다. 보존을 위해 운영 데이터의 복사본을 내보내면 규정 준수 요구 사항을 충족하는 솔루션을 빌드할 수 있습니다.
작업 영역에서 중요한 데이터를 필터링하거나 난독 처리하기 위한 전략을 결정합니다.

중요한 정보를 포함하는 데이터를 수집할 수 있습니다. 특정 데이터 원본에 대한 구성을 사용하여 수집해서는 안 되는 레코드를 필터링합니다. 데이터의 특정 열만 제거하거나 난독 처리를 해야 하는 경우 변환 을 사용합니다.

원래 데이터를 수정 해제해야 하는 표준이 있는 경우 KQL 쿼리에서 'h' 리터럴 을 사용하여 통합 문서에 표시된 쿼리 결과를 난독 처리할 수 있습니다.
작업 영역에서 중요한 데이터를 난독 처리하거나 필터링하면 중요한 정보에 대한 기밀성을 유지하는 데 도움이 됩니다. 대부분의 경우 규정 준수 요구 사항에 따라 중요한 정보를 처리할 수 있는 방법이 결정됩니다. 이 전략은 요구 사항을 사전에 준수하는 데 도움이 됩니다.

Azure Policy

Azure는 원하는 보안 태세를 적용하는 데 도움이 되는 Log Analytics 작업 영역의 보안과 관련된 정책을 제공합니다. 이러한 정책의 예는 다음과 같습니다.

또한 Azure는 Log Analytics 작업 영역이 공용 네트워크에서 로그 수집 및 쿼리를 차단하거나프라이빗 DNS 영역을 사용하도록 Azure Monitor Private Link 범위 구성과 같은 DINE 정책을 통해 솔루션을 구성하는 등 프라이빗 링크 구성을 적용하는 데 도움이 되는 다양한 정책을 제공합니다.

Azure Advisor

Azure는 Log Analytics 작업 영역의 보안과 관련된 Azure Advisor 권장 사항을 제공하지 않습니다.

비용 최적화

비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 비즈니스 요구 사항을 충족하는 동안 organization 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.

비용 최적화 디자인 원칙은 이러한 비즈니스 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다. 또한 모니터링 및 로깅 솔루션과 관련된 기술 설계에서 필요에 따라 절충을 수행할 수 있습니다.

Log Analytics 작업 영역에 대한 데이터 요금이 계산되는 방법에 대한 자세한 내용은 Azure Monitor 로그 비용 계산 및 옵션을 참조하세요.

비용 최적화를 위한 디자인 검사 목록

투자 비용 최적화에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.

  • 비용 모델링 연습을 수행합니다. 이러한 확장은 현재 작업 영역 비용을 이해하고 작업 영역 증가에 따른 비용을 예측하는 데 도움이 됩니다. 워크로드의 성장 추세를 분석하고 워크로드 확장 계획을 이해하여 향후 운영 로깅 비용을 적절하게 예측해야 합니다.
  • 올바른 청구 모델을 선택합니다. 비용 모델을 사용하여 시나리오에 가장 적합한 청구 모델을 결정합니다. 현재 작업 영역을 사용하는 방법과 워크로드가 발전함에 따라 작업 영역을 사용하려는 계획은 종량제 또는 약정 계층 모델이 시나리오에 가장 적합한지 여부를 결정합니다.

    각 작업 영역에 대해 서로 다른 청구 모델을 선택할 수 있으며 특정 경우에 작업 영역 비용을 결합하여 분석 및 의사 결정에 세분화할 수 있습니다.
  • 적절한 양의 로그 데이터만 수집합니다. 리소스, 데이터 수집 규칙 구성 및 사용자 지정 애플리케이션 코드 로깅에 대한 진단 설정에 대해 정기적으로 예약된 분석을 수행하여 불필요한 로그 데이터를 수집하지 않도록 합니다.
  • 비프로덕션 환경을 프로덕션 환경과 다르게 처리합니다. 비프로덕션 환경을 검토하여 진단 설정 및 보존 정책을 적절하게 구성되었는지 확인합니다. 특히 개발/테스트 또는 샌드박스 환경의 경우 프로덕션보다 훨씬 덜 강력할 수 있습니다.

비용 최적화에 대한 구성 권장 사항

권장 이점
각 Log Analytics 작업 영역에서 일반적으로 수집하는 데이터의 양에 대한 가격 책정 계층을 구성합니다. 기본적으로 Log Analytics 작업 영역은 최소 데이터 볼륨 없이 종량제 가격을 사용합니다. 충분한 데이터를 수집하는 경우 약정 계층을 사용하여 비용을 크게 줄일 수 있습니다. 이를 통해 더 낮은 속도의 대가로 수집된 일일 최소 데이터로 커밋할 수 있습니다. 단일 지역의 작업 영역에서 충분한 데이터를 수집하는 경우 전용 클러스터 에 연결하고 클러스터 가격 책정을 사용하여 수집된 볼륨을 결합할 수 있습니다.

약정 계층에 대한 자세한 내용과 사용 수준에 가장 적합한 항목을 결정하는 지침은 Azure Monitor 로그 비용 계산 및 옵션을 참조하세요. 다양한 가격 책정 계층에서 사용량에 대한 예상 비용을 보려면 사용량 및 예상 비용을 참조하세요.
데이터 보존 및 보관을 구성합니다. 기본값인 31일을 초과하여 Log Analytics 작업 영역에 데이터를 보존하는 데 요금이 부과됩니다. 작업 영역에서 Microsoft Sentinel을 사용하도록 설정한 경우 90일, Application Insights 데이터에 대해 90일입니다. 로그 쿼리에서 데이터를 쉽게 사용할 수 있도록 하는 특정 요구 사항을 고려합니다. 보관된 로그를 구성하여 비용을 크게 줄일 수 있습니다. 보관된 로그를 사용하면 최대 7년 동안 데이터를 보존하고 가끔씩 액세스할 수 있습니다. 검색 작업을 사용하거나 작업 영역에 데이터 집합을 복원하여 데이터에 액세스합니다.
Microsoft Sentinel을 사용하여 보안 로그를 분석하는 경우 별도의 작업 영역을 사용하여 해당 로그를 저장하는 것이 좋습니다. SIEM에서 사용하는 로그 데이터에 전용 작업 영역을 사용하면 비용을 제어하는 데 도움이 될 수 있습니다. Microsoft Sentinel에서 사용하는 작업 영역에는 Microsoft Sentinel 가격 책정이 적용됩니다. 보안 요구 사항에 따라 SIEM 솔루션에 포함해야 하는 로그 유형이 결정됩니다. 별도의 작업 영역에 있는 경우 표준 Log Analytics 가격 책정으로 청구되는 운영 로그를 제외할 수 있습니다.
디버깅, 문제 해결 및 감사에 사용되는 테이블을 기본 로그로 구성합니다. 기본 로그용으로 구성된 Log Analytics 작업 영역의 테이블은 제한된 기능과 로그 쿼리에 대한 요금 대신 수집 요금이 낮습니다. 이러한 테이블을 자주 쿼리하지 않고 경고에 사용하지 않는 경우 이 쿼리 비용은 감소된 수집 비용에 따른 상쇄 비용보다 더 클 수 있습니다.
작업 영역에 대한 데이터 원본의 데이터 수집을 제한합니다. Azure Monitor 비용의 주요 요소는 Log Analytics 작업 영역에서 수집하는 데이터의 양입니다. 서비스 및 애플리케이션의 상태 및 성능을 평가하는 데 필요한 것보다 더 많은 데이터를 수집하지 않도록 합니다. 각 리소스에 대해 필요한 운영 데이터의 양을 제공하도록 구성한 진단 설정에 적합한 범주를 선택합니다. 워크로드를 성공적으로 관리하고 무시된 데이터를 관리하지 않는 데 도움이 됩니다.

비용과 모니터링 요구 사항 간에 절충이 있을 수 있습니다. 예를 들어 높은 샘플 속도로 성능 문제를 더 빠르게 검색할 수 있지만 비용을 절감하기 위해 더 낮은 샘플 속도를 원할 수 있습니다. 대부분의 환경에는 다양한 유형의 컬렉션이 있는 여러 데이터 원본이 있으므로 각 환경에 대한 비용 목표와 특정 요구 사항의 균형을 유지해야 합니다. 다양한 데이터 원본에 대한 컬렉션 구성에 대한 권장 사항은 Azure Monitor의 비용 최적화 를 참조하세요.
정기적으로 작업 영역 사용량 현황 데이터를 분석하여 추세 및 변칙을 식별합니다.

Log Analytics 작업 영역 인사이트를 사용하여 작업 영역에서 수집된 데이터의 양을 주기적으로 검토합니다. Log Analytics 작업 영역에서 사용량 분석의 메서드를 사용하여 데이터 수집을 추가로 분석하여 사용량을 더 줄일 수 있는 다른 구성이 있는지 확인합니다.
다양한 원본에서 수집한 데이터의 양을 이해하도록 지원함으로써 초과 비용을 초래할 수 있는 데이터 수집의 변칙 및 상향 추세를 식별합니다. 이 고려 사항은 워크로드에 새 데이터 원본 집합을 추가할 때 중요합니다. 예를 들어 새 VM 집합을 추가하는 경우 서비스에서 새 Azure 진단 설정을 사용하도록 설정하거나 애플리케이션에서 로그 수준을 변경합니다.
데이터 수집량이 많을 때는 경고를 만듭니다. 예기치 않은 청구를 방지하려면 과도한 사용량이 발생할 때마다 사전에 알림을 받아야 합니다. 알림을 통해 청구 기간이 끝나기 전에 잠재적인 변칙을 해결할 수 있습니다.
특정 예산을 초과하지 않도록 일별 한도를 예방 측정값으로 고려합니다. 일일 상한은 구성된 제한에 도달하면 그 날의 남은 시간 동안 Log Analytics 작업 영역에서 데이터 수집을 사용하지 않도록 설정합니다. 일별 한도를 사용하는 경우에서 설명한 대로 비용을 절감하는 방법으로 이 방법을 사용하지 말고 잘못된 구성 또는 남용으로 인한 가출 수집을 방지합니다.

일일 상한을 설정하는 경우 상한 에 도달하면 경고를 만듭니다. 일부 백분율에 도달하면 경고 규칙도 만들어야 합니다. 예를 들어 90% 용량에 도달한 경우에 대한 경고 규칙을 설정할 수 있습니다. 이 경고는 한도가 워크로드에서 중요한 데이터 수집을 차단하기 전에 증가된 데이터의 원인을 조사하고 해결할 수 있는 기회를 제공합니다.

Azure Policy

Azure는 Log Analytics 작업 영역의 비용 최적화와 관련된 정책을 제공하지 않습니다. 작업 영역에 올바른 보존 설정이 포함되어 있는지 확인하는 등 작업 영역 배포를 중심으로 규정 준수 가드 레일을 빌드하는 사용자 지정 정책을 만들 수 있습니다.

Azure Advisor

Azure Advisor는 상대적으로 높은 수집 볼륨을 수신하는 테이블에 대해 작업 영역의 특정 테이블을 저렴한 기본 로그 데이터 계획으로 이동하는 것이 좋습니다. 전환하기 전에 기본 로그를 사용하여 제한 사항을 이해합니다. 자세한 내용은 기본 로그를 사용해야 하는 경우를 참조하세요. 또한 Azure Advisor는 전체 사용량 볼륨에 따라 전체 작업 영역에 대한 가격 책정 약정 계층을 변경하는 것이 좋습니다.

운영 효율성

운영 우수성은 주로 개발 사례, 가시성 및 릴리스 관리를 위한 절차에 중점을 둡니다.

운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대해 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.

운영 우수성에 대한 디자인 검사 목록

Log Analytics 작업 영역과 관련된 가시성, 테스트 및 배포를 위한 프로세스를 정의하기 위한 운영 우수성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.

  • 워크로드의 Log Analytics 작업 영역과 관련된 모든 함수에 IaC(Infrastructure as Code)를 사용합니다. 코드를 통해 가능한 한 많은 함수를 자동화하여 저장된 쿼리 및 쿼리 팩을 포함하여 로그 수집, 수집, 스토리지 및 쿼리 함수를 수동으로 관리하고 운영할 때 발생할 수 있는 사용자 오류의 위험을 최소화합니다. 또한 상태 상태 변경 내용을 보고하는 경고와 IaC 코드의 작업 영역에 로그를 보내는 리소스에 대한 진단 설정 구성을 포함합니다. 작업 영역 관리를 위해 안전한 배포 사례가 유지되도록 다른 워크로드 관련 코드에 코드를 포함합니다.
  • 작업 영역이 정상인지 확인하고 문제가 발생할 때 알림을 받습니다. 워크로드의 다른 구성 요소와 마찬가지로 작업 영역에 문제가 발생할 수 있습니다. 이 문제는 문제를 해결하고 resolve 데 귀중한 시간과 리소스가 소요될 수 있으며, 잠재적으로 팀이 프로덕션 워크로드 상태 인식하지 못할 수 있습니다. 작업 영역을 사전에 모니터링하고 잠재적인 문제를 완화할 수 있으면 운영 팀이 문제를 해결하고 해결하는 데 소요되는 시간을 최소화할 수 있습니다.
  • 프로덕션을 비프로덕션 워크로드와 분리합니다. 프로덕션 환경에 대해 비프로덕션 환경에서 사용하는 작업 영역과 다른 작업 영역을 사용하여 운영 팀에 추가 작업을 발생시킬 수 있는 불필요한 복잡성을 방지합니다. 테스트 작업이 프로덕션의 이벤트로 보일 수 있으므로 오는 데이터로 인해 혼란이 발생할 수도 있습니다.
  • Microsoft가 아닌 솔루션보다 기본 제공 도구 및 함수 선호 기본 제공 도구를 사용하여 모니터링 및 로깅 시스템의 기능을 확장합니다. Log Analytics 작업 영역에서 기본으로 사용할 수 없는 복구 가능성 또는 데이터 주권과 같은 요구 사항을 지원하기 위해 추가 구성을 배치해야 할 수 있습니다. 이러한 경우 실용적일 때마다 네이티브 Azure 또는 Microsoft 도구를 사용하여 organization 지원해야 하는 도구 수를 최소한으로 유지합니다.
  • 작업 영역을 임시 구성 요소가 아닌 정적으로 처리 다른 유형의 데이터 저장소와 마찬가지로 작업 영역은 워크로드의 임시 구성 요소 중에서 고려해서는 안 됩니다. Well-Architected Framework는 일반적으로 변경할 수 없는 인프라와 배포의 일부로 워크로드 내의 리소스를 빠르고 쉽게 대체할 수 있는 기능을 선호합니다. 그러나 작업 영역 데이터의 손실은 치명적이고 되돌릴 수 없습니다. 이러한 이유로 업데이트 중에 인프라를 대체하는 배포 패키지에서 작업 영역을 그대로 두고 작업 영역에서만 현재 위치 업그레이드를 수행합니다.
  • 운영 직원이 필요할 때 쿼리를 만들거나 수정하도록 교육하는 Kusto 쿼리 언어 교육되었는지 확인합니다. 운영자가 쿼리를 작성하거나 수정할 수 없는 경우 운영자가 다른 팀에 의존하여 해당 작업을 수행해야 하므로 중요한 문제 해결 또는 기타 기능이 느려질 수 있습니다.

운영 우수성에 대한 구성 권장 사항

권장 이점
비즈니스 요구 사항을 충족하도록 작업 영역 전략을 설계합니다.

Log Analytics 작업 영역에 대한 전략 설계에 대한 지침은 Log Analytics 작업 영역 아키텍처 디자인을 참조하세요. 만들 수 및 배치 위치를 포함합니다.

워크로드에서 중앙 집중식 플랫폼 팀 제품을 사용해야 하는 경우 필요한 모든 운영 액세스를 설정해야 합니다. 또한 워크로드 가시성 요구 사항을 충족하도록 경고를 생성합니다.
단일 또는 최소 수의 작업 영역은 워크로드의 운영 효율성을 최대화합니다. 운영 및 보안 데이터의 배포를 제한하고, 잠재적인 문제에 대한 가시성을 높이고, 패턴을 보다 쉽게 식별하고, 유지 관리 요구 사항을 최소화합니다.

여러 테넌트 같은 여러 작업 영역에 대한 요구 사항이 있거나 가용성 요구 사항을 지원하기 위해 여러 지역의 작업 영역이 필요할 수 있습니다. 따라서 이 증가된 복잡성을 관리하기 위한 적절한 프로세스가 마련되어 있는지 확인합니다.
IaC(Infrastructure as Code)를 사용하여 작업 영역 및 관련 함수를 배포하고 관리합니다. IaC(Infrastructure as code)를 사용하여 ARM 템플릿, Azure BICEP 또는 Terraform에서 작업 영역의 세부 정보를 정의합니다. 기존 DevOps 프로세스를 사용하여 새 작업 영역을 배포하고 Azure Policy 구성을 적용할 수 있습니다.

모든 IaC 코드를 애플리케이션 코드와 공동 배치하면 모든 배포에 대해 안전한 배포 사례가 유지 관리되도록 할 수 있습니다.
Log Analytics 작업 영역 인사이트를 사용하여 Log Analytics 작업 영역의 상태 및 성능을 추적하고 의미 있고 실행 가능한 경고를 만들어 운영 문제를 사전에 통보합니다.

Log Analytics 작업 영역 인사이트는 모든 작업 영역에 대한 사용량, 성능, 상태, 에이전트, 쿼리 및 변경 로그에 대한 통합 보기를 제공합니다.

각 작업 영역에는 작업 영역에 영향을 주는 중요한 활동을 기록하는 작업 테이블 이 있습니다.
Log Analytics 인사이트가 정기적으로 제공하는 정보를 검토하여 각 작업 영역의 상태 및 작업을 추적합니다. 이 정보를 사용하면 작업 및 관련자가 작업 영역의 상태를 추적하는 데 사용할 수 있는 대시보드 또는 보고서와 같은 쉽게 이해할 수 있는 시각화를 만들 수 있습니다.

운영 문제가 발생할 때 사전에 알림을 받도록 이 테이블을 기반으로 경고 규칙을 만듭니다. 작업 영역에 권장되는 경고를 사용하여 가장 중요한 경고 규칙을 만드는 방법을 간소화할 수 있습니다.
리소스, 데이터 수집 규칙 및 애플리케이션 로그 세부 정보 표시에 대한 Azure 진단 설정을 자주 다시 검토하여 지속적인 개선을 연습합니다.

리소스 설정을 자주 검토하여 로그 수집 전략을 최적화하고 있는지 확인합니다. 운영 관점에서 리소스의 상태 상태 대한 유용한 정보를 제공하는 로그에 집중하여 로그의 노이즈를 줄이려고 합니다.
이러한 방식으로 최적화하면 운영자가 문제가 발생할 때 문제를 조사하고 해결하거나 다른 루틴, 즉석 또는 응급 작업을 수행할 수 있습니다.

리소스 종류에 대해 새 진단 범주를 사용할 수 있게 되면 이 범주로 내보낸 로그 유형을 검토하여 사용하도록 설정하면 컬렉션 전략을 최적화하는 데 도움이 되는지 여부를 이해합니다. 예를 들어 새 범주는 캡처되는 더 큰 활동 집합의 하위 집합일 수 있습니다. 새 하위 집합을 사용하면 작업 추적에 중요한 활동에 집중하여 들어오는 로그 볼륨을 줄일 수 있습니다.

Azure Policy 및 Azure Advisor

Azure는 Log Analytics 작업 영역의 운영 우수성과 관련된 정책이나 Azure Advisor 권장 사항을 제공하지 않습니다.

성능 효율성

성능 효율성은 용량 을 관리하여 부하가 증가하는 경우에도 사용자 환경을 유지하는 것입니다. 이 전략에는 리소스 크기 조정, 잠재적 병목 현상 식별 및 최적화, 최대 성능 최적화가 포함됩니다.

성능 효율성 디자인 원칙은 예상 사용량에 대해 이러한 용량 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공합니다.

성능 효율성을 위한 디자인 검사 목록

Log Analytics 작업 영역 및 관련 함수에 대한 기준을 정의하기 위한 성능 효율성에 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.

  • Azure Monitor에서 로그 데이터 수집 대기 시간의 기본 사항에 대해 잘 알고 있어야 합니다. 작업 영역에 로그를 수집할 때 대기 시간에 영향을 주는 몇 가지 요인이 있습니다. 이러한 요인의 대부분은 Azure Monitor 플랫폼에 내재되어 있습니다. 요인과 일반적인 대기 시간 동작을 이해하면 워크로드 운영 팀 내에서 적절한 기대치를 설정하는 데 도움이 될 수 있습니다.
  • 비프로덕션 및 프로덕션 워크로드를 구분합니다. 프로덕션별 작업 영역은 비프로덕션 시스템에서 발생할 수 있는 모든 오버헤드를 완화합니다. 작업 영역의 전체 공간을 줄여 로그 데이터 처리를 처리하는 데 필요한 리소스가 줄어듭니다.
  • 성능 요구 사항을 충족하는 올바른 배포 지역을 선택합니다. 워크로드에 가까운 Log Analytics 작업 영역 및 DCE(데이터 수집 엔드포인트)를 배포합니다. 작업 영역과 DCE를 배포할 적절한 지역을 선택하는 경우 워크로드를 배포하는 위치를 알려야 합니다. 로그 데이터에 대한 이러한 요구 사항을 지원할 수 없는 지역에 워크로드를 이미 배포한 경우 워크로드와 동일한 지역에 작업 영역 및 DCE를 배포할 때의 성능 이점을 안정성 요구 사항과 비교할 수 있습니다.

성능 효율성에 대한 구성 권장 사항

권장 이점
로그 쿼리 감사를 구성하고 Log Analytics 작업 영역 인사이트를 사용하여 느리고 비효율적인 쿼리를 식별합니다.

로그 쿼리 감사는 각 쿼리 를 실행하는 데 필요한 컴퓨팅 시간과 결과가 반환될 때까지의 시간을 저장합니다. Log Analytics 작업 영역 인사이트는 이 데이터를 사용하여 작업 영역에서 잠재적으로 비효율적인 쿼리를 나열합니다. 성능을 향상시키려면 이러한 쿼리를 다시 작성하는 것이 좋습니다. 로그 쿼리 최적화에 대한 지침은 Azure Monitor에서 로그 쿼리 최적화를 참조하세요.
최적화된 쿼리는 결과를 더 빠르게 반환하고 백 엔드에서 더 적은 리소스를 사용하므로 이러한 쿼리를 사용하는 프로세스도 더 효율적입니다.
Log Analytics 작업 영역에 대한 서비스 제한을 이해합니다.

트래픽이 많은 특정 구현에서는 성능 및 작업 영역 또는 워크로드 디자인에 영향을 주는 서비스 제한이 발생할 수 있습니다. 예를 들어 쿼리 API는 쿼리에서 반환되는 레코드 및 데이터 볼륨의 수를 제한합니다. 로그 수집 API는 각 API 호출의 크기를 제한합니다.

작업 영역 자체와 관련된 Azure Monitor 및 Log Analytics 작업 영역 제한 및 제한의 전체 목록은 Azure Monitor 서비스 제한을 참조하세요.
작업 영역의 성능에 영향을 줄 수 있는 제한을 이해하면 이를 완화하기 위해 적절하게 디자인하는 데 도움이 됩니다. 단일 작업 영역과 관련된 제한에 도달하지 않도록 여러 작업 영역을 사용하도록 결정할 수 있습니다.

다른 핵심 요소에 대한 요구 사항 및 대상에 대한 서비스 제한을 완화하기 위한 설계 결정의 무게를 측정합니다.
하나 이상의 정의된 가시성 범위 내에서 데이터 원본 형식과 관련된 DCR을 만듭니다. 성능 및 이벤트를 위한 별도의 DCR을 만들어 백 엔드 처리 컴퓨팅 사용률을 최적화합니다. 성능 및 이벤트에 별도의 DCR을 사용하는 경우 백 엔드 리소스 소모를 완화하는 데 도움이 됩니다. 성능 이벤트를 결합하는 DCR을 사용하면 연결된 모든 가상 머신이 설치된 소프트웨어에 따라 적용되지 않을 수 있는 구성을 전송, 처리 및 실행하도록 강제합니다. 과도한 컴퓨팅 리소스 사용량 및 구성 처리 오류가 발생하여 AMA(Azure Monitor 에이전트)가 응답하지 않을 수 있습니다.

Azure Policy 및 Azure Advisor

Azure는 Log Analytics 작업 영역의 성능과 관련된 정책이나 Azure Advisor 권장 사항을 제공하지 않습니다.

다음 단계