지역 간에 Log Analytics 작업 영역을 복제하여 복원력 향상(미리 보기)

지역 간에 Log Analytics 작업 영역을 복제하면 복제된 작업 영역으로 스위치오버하고 지역 오류가 있는 경우 작업을 계속할 수 있으므로 복원력이 향상됩니다. 이 문서에서는 Log Analytics 작업 영역 복제가 작동하는 방식, 작업 영역을 복제하는 방법, 스위치오버 및 스위치백 방법, 복제된 작업 영역 간 전환 시기를 결정하는 방법에 대해 설명합니다.

Log Analytics 작업 영역 복제가 작동하는 방식에 대한 간략한 개요를 제공하는 동영상은 다음과 같습니다.

Important

예를 들어, API 호출에서 장애 조치(failover)라는 용어를 사용하는 경우도 있지만 장애 조치(failover)는 자동 프로세스를 설명하는 데에도 일반적으로 사용됩니다. 따라서 이 문서에서는 스위치오버라는 용어를 사용하여 복제된 작업 영역으로의 전환이 수동으로 트리거하는 작업임을 강조합니다.

필수 사용 권한

작업	필수 사용 권한
작업 영역 복제 사용	예를 들어 모니터링 기여자 기본 제공 역할에서 제공하는 Microsoft.OperationalInsights/workspaces/write 및 Microsoft.Insights/dataCollectionEndpoints/write권한
스위치오버 및 스위치백(장애 조치(failover) 및 장애 복구(failback) 트리거)	예를 들어 모니터링 기여자 기본 제공 역할에서 제공하는 Microsoft.OperationalInsights/locations/workspaces/failover, Microsoft.OperationalInsights/workspaces/failback 및 Microsoft.Insights/dataCollectionEndpoints/triggerFailover/action권한
작업 영역 상태 확인	예를 들어 모니터링 기여자 기본 제공 역할에서 제공하는 Log Analytics 작업 영역에 대한 Microsoft.OperationalInsights/workspaces/read 권한

Log Analytics 작업 영역 복제 작동 방식

원래 작업 영역 및 지역을 기본이라고 합니다. 복제된 작업 영역과 대체 지역을 보조라고 합니다.

작업 영역 복제 프로세스는 보조 지역에 작업 영역의 인스턴스를 만듭니다. 이 프로세스는 기본 작업 영역과 동일한 구성을 사용하여 보조 작업 영역을 만들고, Azure Monitor는 기본 작업 영역 구성에 대한 향후 변경 내용으로 보조 작업 영역을 자동으로 업데이트합니다.

보조 작업 영역은 복원력만을 위한 "섀도" 작업 영역입니다. Azure Portal에서는 보조 작업 영역을 볼 수 없으며 직접 관리하거나 액세스할 수 없습니다.

작업 영역 복제를 사용하도록 설정하면 Azure Monitor는 기본 작업 영역에 수집된 새 로그를 보조 지역에도 보냅니다. 작업 영역 복제를 사용하도록 설정하기 전에 작업 영역에 수집한 로그는 복사되지 않습니다.

중단이 주 지역에 영향을 미치는 경우 모든 수집 및 쿼리 요청을 보조 지역으로 스위치오버하고 다시 라우팅할 수 있습니다. Azure가 중단을 완화하고 기본 작업 영역이 다시 정상 상태가 되면 주 지역으로 스위치백할 수 있습니다.

스위치오버하면 보조 작업 영역이 활성화되고 기본 작업 영역이 비활성화됩니다. 그러면 Azure Monitor는 주 지역이 아닌 보조 지역의 수집 파이프라인을 통해 새 데이터를 수집합니다. 보조 지역으로 스위치오버하면 Azure Monitor는 보조 지역에서 수집하는 모든 데이터를 주 지역에 복제합니다. 이 프로세스는 비동기식이며 수집 대기 시간에 영향을 주지 않습니다.

Important

보조 지역으로 스위치오버한 후 주 지역이 들어오는 로그 데이터를 처리할 수 없는 경우 Azure Monitor는 최대 11일 동안 보조 지역의 데이터를 버퍼링합니다. 처음 4일 동안 Azure Monitor는 주기적으로 데이터 복제를 자동으로 다시 시도합니다.

지원되는 지역

작업 영역 복제는 현재 지역 그룹(지리적으로 인접한 지역의 그룹)으로 구성된 제한된 지역 집합의 작업 영역에 대해 지원됩니다. 복제를 사용하도록 설정하는 경우 작업 영역 기본 위치와 동일한 지역 그룹의 지원되는 지역 목록에서 보조 위치를 선택합니다. 예를 들어, 서부 유럽의 작업 영역은 북유럽에서 복제될 수 있지만 미국 서부 2에서는 이러한 지역이 서로 다른 지역 그룹에 속하기 때문에 복제할 수 없습니다.

현재 지원되는 지역 그룹 및 지역은 다음과 같습니다.

지역 그룹	지역	주의
북아메리카	미국 동부	미국 동부 2 지역 간 복제는 지원되지 않습니다.
	미국 동부 2	미국 동부 지역 간 복제는 지원되지 않습니다.
	미국 서부
	미국 서부 2
	미국 중부
	미국 중남부
	캐나다 중부
유럽	서유럽
	북유럽
	영국 남부
	영국 서부
	독일 중서부
	프랑스 중부

데이터 보존 요구 사항

고객마다 데이터 보존 요구 사항이 다르므로 데이터가 저장되는 위치를 제어해야 합니다. Azure Monitor는 선택한 기본 및 보조 지역에서 로그를 처리하고 저장합니다. 자세한 내용은 지원되는 지역을 참조하세요.

Sentinel 및 기타 서비스 지원

Log Analytics 작업 영역을 사용하는 다양한 서비스 및 기능은 작업 영역 복제 및 스위치오버와 호환됩니다. 이러한 서비스와 기능은 보조 작업 영역으로 스위치오버해도 계속 작동합니다.

예를 들어, 로그 수집 대기 시간을 유발하는 지역 네트워크 문제는 Sentinel 고객에게 영향을 미칠 수 있습니다. 복제된 작업 영역을 사용하는 고객은 보조 지역으로 스위치오버하여 Log Analytics 작업 영역 및 Sentinel을 계속 사용할 수 있습니다. 그러나 네트워크 문제가 Sentinel 서비스 상태에 영향을 미치는 경우 다른 지역으로 전환해도 문제가 완화되지 않습니다.

Application Insights 및 VM 인사이트를 포함한 일부 Azure Monitor 환경은 현재 작업 영역 복제 및 스위치오버와 부분적으로만 호환됩니다. 전체 목록을 보려면 제한 사항을 참조하세요.

작업 영역 복제 사용 및 사용 안 함

REST 명령을 사용하여 작업 영역 복제를 사용하거나 사용하지 않도록 설정합니다. 이 명령은 장기 실행 작업을 트리거합니다. 즉, 새 설정이 적용되는 데 몇 분 정도 걸릴 수 있습니다. 복제를 사용하도록 설정한 후 모든 테이블(데이터 형식)이 복제를 시작하는 데 최대 1시간이 걸릴 수 있으며 일부 데이터 형식은 다른 데이터 형식보다 먼저 복제를 시작할 수 있습니다. 작업 영역 복제를 사용하도록 설정한 후 테이블 스키마에 대한 변경 내용(예: 만든 새 사용자 지정 로그 테이블 또는 사용자 지정 필드 또는 새 리소스 종류에 대해 설정된 진단 로그)이 복제를 시작하는 데 최대 1시간이 걸릴 수 있습니다.

Important

전용 클러스터에 연결된 Log Analytics 작업 영역 복제는 현재 지원되지 않습니다.

작업 영역 복제 사용

Log Analytics 작업 영역에서 복제를 사용하도록 설정하려면 다음 PUT 명령을 사용합니다.

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": true,
            "location": "<secondary_region>"
        }
    },
    "location": "<primary_region>"
}

여기서

• <subscription_id>: 작업 영역과 관련된 구독 ID입니다.
• <resourcegroup_name>: Log Analytics 작업 영역 리소스가 포함된 리소스 그룹입니다.
• <workspace_name>: 작업 영역의 이름.
• <primary_region>: Log Analytics 작업 영역의 주 지역입니다.
• <secondary_region>: Azure Monitor가 보조 작업 영역을 만드는 지역입니다.

지원되는 location 값은 지원되는 지역을 참조하세요.

PUT 명령은 완료하는 데 다소 시간이 걸릴 수 있는 장기 실행 작업입니다. 성공적인 호출은 200 상태 코드를 반환합니다. 요청 프로비전 상태 확인에 설명된 대로 요청의 프로비전 상태를 추적할 수 있습니다.

요청 프로비전 상태 확인

요청의 프로비전 상태를 확인하려면 다음 GET 명령을 실행합니다.

GET

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

여기서

• <subscription_id>: 작업 영역과 관련된 구독 ID입니다.
• <resourcegroup_name>: Log Analytics 작업 영역 리소스가 포함된 리소스 그룹입니다.
• <workspace_name>: Log Analytics 작업 영역의 이름입니다.

GET 명령을 사용하여 작업 영역 프로비전 상태가 Updating에서 Succeeded로 변경되고 보조 지역이 예상대로 설정되었는지 확인합니다.

참고 항목

Sentinel과 상호 작용하는 작업 영역에 대해 복제를 사용하도록 설정하면 관심 목록 및 위협 인텔리전스 데이터를 보조 작업 영역에 완전히 복제하는 데 최대 12일이 걸릴 수 있습니다.

데이터 수집 규칙을 시스템 데이터 수집 엔드포인트와 연결

Azure Monitor 에이전트 및 로그 수집 API를 통해 로그 데이터를 수집하려면 DCR(데이터 수집 규칙)을 사용합니다.

기본 작업 영역으로 데이터를 보내는 데이터 수집 규칙이 있는 경우 작업 영역 복제를 사용하도록 설정할 때 Azure Monitor가 만드는 시스템 DCE(데이터 수집 엔드포인트)에 규칙을 연결해야 합니다. 시스템 데이터 수집 엔드포인트의 이름은 작업 영역 ID와 동일합니다. 작업 영역의 시스템 데이터 수집 엔드포인트에 연결하는 데이터 수집 규칙만 복제 및 스위치오버를 사용하도록 설정합니다. 이 동작을 통해 복제할 로그 스트림 집합을 지정할 수 있으므로 복제 비용을 제어하는 데 도움이 됩니다.

데이터 수집 규칙을 사용하여 수집한 데이터를 복제하려면 데이터 수집 규칙을 Log Analytics 작업 영역의 시스템 데이터 수집 엔드포인트에 연결합니다.

1. Azure Portal에서 데이터 수집 규칙을 선택합니다.

2. 데이터 수집 규칙 화면에서 기본 Log Analytics 작업 영역으로 데이터를 보내는 데이터 수집 규칙을 선택합니다.

3. 데이터 수집 규칙 개요 페이지에서 DCE 구성을 선택하고 사용 가능한 목록에서 시스템 데이터 수집 엔드포인트를 선택합니다.

   시스템 DCE에 대한 자세한 내용은 작업 영역 개체 속성을 확인합니다.

Important

작업 영역의 시스템 데이터 수집 엔드포인트에 연결된 데이터 수집 규칙은 해당 특정 작업 영역만 대상으로 할 수 있습니다. 데이터 수집 규칙은 다른 작업 영역이나 Azure Storage 계정과 같은 다른 대상을 대상으로 삼아서는 안 됩니다.

작업 영역 복제 사용 안 함

작업 영역에 대한 복제를 사용하지 않도록 설정하려면 다음 PUT 명령을 사용합니다.

PUT 

https://management.azure.com/subscriptions/<subscription_id>/resourcegroups/<resourcegroup_name>/providers/microsoft.operationalinsights/workspaces/<workspace_name>?api-version=2023-01-01-preview

body:
{
    "properties": {
        "replication": {
            "enabled": false
        }
    },
    "location": "<primary_region>"
}

여기서

• <subscription_id>: 작업 영역과 관련된 구독 ID입니다.
• <resourcegroup_name>: 작업 영역 리소스가 포함된 리소스 그룹입니다.
• <workspace_name>: 작업 영역의 이름.
• <primary_region>: 작업 영역의 주 지역입니다.

PUT 명령은 완료하는 데 다소 시간이 걸릴 수 있는 장기 실행 작업입니다. 성공적인 호출은 200 상태 코드를 반환합니다. 요청 프로비전 상태 확인에 설명된 대로 요청의 프로비전 상태를 추적할 수 있습니다.

작업 영역 및 서비스 상태 모니터링

수집 대기 시간 또는 쿼리 실패는 보조 지역으로 장애 조치(failover)하여 처리할 수 있는 문제의 예입니다. 이러한 문제는 Service Health 알림 및 로그 쿼리를 사용하여 검색할 수 있습니다.

Service Health 알림은 서비스 관련 문제에 유용합니다. 특정 작업 영역(전체 서비스가 아닐 수도 있음)에 영향을 미치는 문제를 식별하려면 다른 측정값을 사용할 수 있습니다.

• 작업 영역 리소스 상태를 기반으로 경고 만들기
• 작업 영역 상태 메트릭에 대한 자체 임계값 설정
• 쿼리를 사용하여 작업 영역 성능 모니터링에 설명된 대로 작업 영역에 대한 사용자 지정 상태 표시기 역할을 할 자체 모니터링 쿼리를 만들어 다음을 수행합니다.
  • 테이블당 수집 대기 시간 측정
  • 대기 시간의 원인이 컬렉션 에이전트인지 수집 파이프라인인지 식별
  • 테이블별, 리소스별 수집량 변칙 모니터링
  • 테이블, 사용자, 리소스별 쿼리 성공률 모니터링
  • 쿼리를 기반으로 경고 만들기

참고 항목

로그 쿼리를 사용하여 보조 작업 영역을 모니터링할 수도 있지만 로그 복제는 일괄 처리 작업으로 수행된다는 점에 유의해야 합니다. 측정된 대기 시간은 변동될 수 있으며 보조 작업 영역의 상태 문제를 나타내지 않습니다. 자세한 내용은 비활성 작업 영역 감사를 참조하세요.

보조 작업 영역으로 스위치오버

스위치오버 중에 대부분의 작업은 기본 작업 영역 및 지역을 사용할 때와 동일하게 작동합니다. 그러나 일부 작업은 동작이 약간 다르거나 차단됩니다. 자세한 내용은 제한 사항을 참조하세요.

언제 스위치오버해야 하나요?

지속적인 성능 및 상태 모니터링과 시스템 표준 및 요구 사항에 따라 보조 작업 영역으로 스위치오버하고 기본 작업 영역으로 스위치백할 시기를 결정합니다.

다음 하위 섹션에 설명된 대로 스위치오버 계획에서 고려해야 할 몇 가지 사항이 있습니다.

문제 유형 및 범위

스위치오버 프로세스는 수집 및 쿼리 요청을 보조 지역으로 라우팅하며, 이는 일반적으로 주 지역에서 대기 시간이나 오류를 일으키는 결함이 있는 구성 요소를 무시합니다. 결과적으로 다음과 같은 경우에는 스위치오버가 도움이 되지 않을 것입니다.

• 기본 리소스에 지역 간 문제가 있습니다. 예를 들어, 기본 지역과 보조 지역 모두에서 동일한 리소스 종류가 실패하는 경우입니다.
• 작업 영역 보존 변경 등 작업 영역 관리와 관련된 문제가 발생합니다. 작업 영역 관리 작업은 항상 주 지역에서 처리됩니다. 스위치오버 중에는 작업 영역 관리 작업이 차단됩니다.

발급 기간

스위치오버는 즉각적이지 않습니다. 요청을 다시 라우팅하는 프로세스는 DNS 업데이트에 의존합니다. 일부 클라이언트는 몇 분 안에 이를 선택하지만 다른 클라이언트는 더 많은 시간이 걸릴 수 있습니다. 따라서 문제가 몇 분 내에 해결될 수 있는지 이해하는 것이 도움이 됩니다. 관찰된 문제가 일관되거나 지속되는 경우 스위치오버할 때까지 기다리지 마세요. 다음 몇 가지 예를 참조하세요.

• 수집: 주 지역의 수집 파이프라인 문제는 보조 작업 영역으로의 데이터 복제에 영향을 미칠 수 있습니다. 스위치오버 중에 로그는 대신 보조 지역의 수집 파이프라인으로 전송됩니다.

• 쿼리: 기본 작업 영역의 쿼리가 실패하거나 시간 제한되면 로그 검색 경고가 영향을 받을 수 있습니다. 이 시나리오에서는 보조 작업 영역으로 스위치오버하여 모든 경고가 올바르게 트리거되는지 확인합니다.

보조 작업 영역 데이터

복제를 사용하도록 설정하기 전에 기본 작업 영역에 수집된 로그는 보조 작업 영역에 복사되지 않습니다. 3시간 전에 작업 영역 복제를 사용하도록 설정하고 이제 보조 작업 영역으로 스위치오버하는 경우 쿼리는 지난 3시간의 데이터만 반환할 수 있습니다.

스위치오버 중에 지역을 전환하기 전에 보조 작업 영역에 유용한 양의 로그가 포함되어 있어야 합니다. 복제를 사용하도록 설정한 후 스위치오버를 트리거하기 전에 최소 1주일을 기다리는 것이 좋습니다. 7일 동안 보조 지역에서 충분한 데이터를 사용할 수 있습니다.

스위치오버 트리거

스위치오버하기 전에 작업 영역 복제 작업이 성공적으로 완료되었는지 확인합니다. 스위치오버는 보조 작업 영역이 올바르게 구성된 경우에만 성공합니다.

보조 작업 영역으로 스위치오버하려면 다음 POST 명령을 사용합니다.

POST 
https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/locations/<secondary_region>/workspaces/<workspace_name>/failover?api-version=2023-01-01-preview

여기서

• <subscription_id>: 작업 영역과 관련된 구독 ID입니다.
• <resourcegroup_name>: 작업 영역 리소스가 포함된 리소스 그룹입니다.
• <secondary_region>: 스위치오버 중에 전환할 지역입니다.
• <workspace_name>: 스위치오버 중에 전환할 작업 영역의 이름입니다.

POST 명령은 완료하는 데 다소 시간이 걸릴 수 있는 장기 실행 작업입니다. 성공적인 호출은 202 상태 코드를 반환합니다. 요청 프로비전 상태 확인에 설명된 대로 요청의 프로비전 상태를 추적할 수 있습니다.

기본 작업 영역으로 스위치백

스위치백 프로세스는 쿼리 재라우팅과 보조 작업 영역에 대한 로그 수집 요청을 취소합니다. 스위치백하면 Azure Monitor는 기본 작업 영역에 대한 쿼리 및 로그 수집 요청 라우팅으로 돌아갑니다.

보조 지역으로 스위치오버하면 Azure Monitor는 보조 작업 영역의 로그를 기본 작업 영역으로 복제합니다. 가동 중단이 주 지역의 로그 수집 프로세스에 영향을 미치는 경우 Azure Monitor가 기본 작업 영역에 복제된 로그 수집을 완료하는 데 시간이 걸릴 수 있습니다.

언제 다시 스위치백해야 하나요?

다음 하위 섹션에 설명된 대로 스위치백 계획에서 고려해야 할 몇 가지 사항이 있습니다.

로그 복제 상태

스위치백하기 전에 Azure Monitor가 주 지역으로 스위치오버하는 동안 수집된 모든 로그 복제를 완료했는지 확인합니다. 모든 로그가 기본 작업 영역에 복제되기 전에 스위치백하면 로그 수집이 완료될 때까지 쿼리가 부분 결과를 반환할 수 있습니다.

비활성 작업 영역 감사에 설명된 대로 Azure Portal에서 비활성 지역에 대한 기본 작업 영역을 쿼리할 수 있습니다.

기본 작업 영역 상태

기본 작업 영역으로의 스위치백을 준비하기 위해 확인해야 할 두 가지 중요한 상태 항목이 있습니다.

• 기본 작업 영역 및 지역에 대해 미해결 Service Health 알림이 없는지 확인합니다.
• 기본 작업 영역이 예상대로 로그를 수집하고 쿼리를 처리하고 있는지 확인합니다.

보조 작업 영역이 활성 상태일 때 기본 작업 영역을 쿼리하고 보조 작업 영역으로의 요청 재라우팅을 무시하는 방법에 대한 예는 비활성 작업 영역 감사를 참조하세요.

스위치백 트리거

스위치백하기 전에 기본 작업 영역 상태를 확인하고 로그 복제를 완료합니다.

스위치백 프로세스는 DNS 레코드를 업데이트합니다. DNS 레코드가 업데이트된 후 모든 클라이언트가 업데이트된 DNS 설정을 수신하고 기본 작업 영역으로의 라우팅을 다시 시작하는 데 시간이 걸릴 수 있습니다.

기본 작업 영역으로 스위치백하려면 다음 POST 명령을 사용합니다.

POST

https://management.azure.com/subscriptions/<subscription_id>/resourceGroups/<resourcegroup_name>/providers/Microsoft.OperationalInsights/workspaces/<workspace_name>/failback?api-version=2023-01-01-preview

여기서

• <subscription_id>: 작업 영역과 관련된 구독 ID입니다.
• <resourcegroup_name>: 작업 영역 리소스가 포함된 리소스 그룹입니다.
• <workspace_name>: 스위치백 중에 전환할 작업 영역의 이름입니다.

POST 명령은 완료하는 데 다소 시간이 걸릴 수 있는 장기 실행 작업입니다. 성공적인 호출은 202 상태 코드를 반환합니다. 요청 프로비전 상태 확인에 설명된 대로 요청의 프로비전 상태를 추적할 수 있습니다.

비활성 작업 영역 감사

기본적으로 작업 영역의 활성 지역은 작업 영역을 만드는 지역이며, 비활성 지역은 Azure Monitor가 복제된 작업 영역을 만드는 보조 지역입니다.

장애 조치(failover)를 트리거하면 보조 지역이 활성화되고 주 지역이 비활성 상태가 됩니다. 로그 수집 및 쿼리 요청의 직접 대상이 아니기 때문에’비활성 상태라고 합니다.

비활성 지역의 작업 영역에 예상되는 로그가 있는지 확인하기 위해 지역 간을 전환하기 전에 비활성 지역을 쿼리하는 것이 유용합니다.

비활성 지역 쿼리

비활성 지역에서 로그 데이터를 쿼리하려면 다음 GET 명령을 사용합니다.

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=<query>&timespan=<timespan-in-ISO8601-format>&overrideWorkspaceRegion=<primary|secondary>

예를 들어 보조 지역에서 지난 날에 대해 Perf | count 같은 간단한 쿼리를 실행하려면 다음을 사용합니다.

GET

api.loganalytics.azure.com/v1/workspaces/<workspace id>/query?query=Perf%20|%20count&timespan=P1D&overrideWorkspaceRegion=secondary

Log Analytics 작업 영역에서 쿼리 감사를 사용하도록 설정할 때 만들어지는 LAQueryLogs 테이블에서 다음 필드를 확인하여 Azure Monitor가 의도한 지역에서 쿼리를 실행하는지 확인할 수 있습니다.

• isWorkspaceInFailover: 쿼리 중에 작업 영역이 스위치오버 모드에 있었는지 여부를 나타냅니다. 데이터 형식은 부울(True, False)입니다.
• workspaceRegion: 쿼리의 대상 작업 영역 지역입니다. 데이터 형식은 문자열입니다.

쿼리를 사용하여 작업 영역 성능 모니터링

이 섹션의 쿼리를 사용하여 가능한 작업 영역 상태 또는 성능 문제를 알리는 경고 규칙을 만드는 것이 좋습니다. 그러나 스위치오버 결정은 신중한 고려가 필요하며 자동으로 결정되어서는 안 됩니다.

쿼리 규칙에서 지정된 위반 횟수 이후 보조 작업 영역으로 스위치오버하는 조건을 정의할 수 있습니다. 자세한 내용은 로그 검색 경고 규칙 만들기 또는 편집을 참조하세요.

작업 영역 성능을 측정하는 두 가지 중요한 측정에는 수집 대기 시간과 수집량이 있습니다. 다음 섹션에서는 이러한 모니터링 옵션을 살펴봅니다.

엔드투엔드 수집 대기 시간 모니터링

수집 대기 시간은 작업 영역에 로그를 수집하는 데 걸리는 시간을 측정합니다. 시간 측정은 초기 기록된 이벤트가 발생할 때 시작되고 로그가 작업 영역에 저장될 때 종료됩니다. 총 수집 대기 시간은 두 부분으로 구성됩니다.

• 에이전트 대기 시간: 에이전트가 이벤트를 보고하는 데 필요한 시간입니다.
• 수집 파이프라인(백 엔드) 대기 시간: 수집 파이프라인이 로그를 처리하고 작업 영역에 쓰는 데 필요한 시간입니다.

데이터 형식마다 수집 대기 시간이 다릅니다. 각 데이터 형식에 대한 수집을 개별적으로 측정하거나, 모든 형식에 대한 제네릭 쿼리를 만들고, 더 중요한 특정 형식에 대해 보다 세분화된 쿼리를 만들 수 있습니다. 수집 대기 시간의 90번째 백분위수를 측정하는 것이 좋습니다. 이는 평균 또는 50번째 백분위수(중앙값)보다 변화에 더 민감합니다.

다음 섹션에서는 쿼리를 사용하여 작업 영역의 수집 대기 시간을 확인하는 방법을 보여 줍니다.

특정 테이블의 기준 수집 대기 시간 평가

며칠 동안 특정 테이블의 기본 대기 시간을 결정하는 것부터 시작합니다.

이 쿼리 예는 Perf 테이블에서 수집 대기 시간의 90번째 백분위수에 대한 차트를 만듭니다.

// Assess the ingestion latency baseline for a specific data type
Perf
| where TimeGenerated > ago(3d) 
| project TimeGenerated, 
IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize LatencyIngestion90Percentile=percentile(IngestionDurationSeconds, 90) by bin(TimeGenerated, 1h) 
| render timechart

쿼리를 실행한 후 결과와 렌더링된 차트를 검토하여 해당 테이블의 예상 대기 시간을 확인합니다.

현재 수집 대기 시간 모니터링 및 경고

특정 테이블에 대한 기본 수집 대기 시간을 설정한 후 짧은 기간 동안의 대기 시간 변화를 기반으로 테이블에 대한 로그 검색 경고 규칙을 만듭니다.

이 쿼리는 지난 20분 동안의 수집 대기 시간을 계산합니다.

// Track the recent ingestion latency (in seconds) of a specific table
Perf
| where TimeGenerated > ago(20m) 
| extend IngestionDurationSeconds = (ingestion_time()-TimeGenerated)/1s
| summarize Ingestion90Percent_seconds=percentile(IngestionDurationSeconds, 90)

약간의 변동이 예상될 수 있으므로 쿼리가 기준보다 훨씬 더 큰 값을 반환하는지 확인하는 경고 규칙 조건을 만듭니다.

수집 대기 시간의 원인 확인

총 수집 대기 시간이 증가하는 것을 확인하면 쿼리를 사용하여 대기 시간의 원인이 에이전트인지 수집 파이프라인인지 확인할 수 있습니다.

이 쿼리는 에이전트와 파이프라인의 90번째 백분위수 대기 시간을 개별적으로 차트로 표시합니다.

// Assess agent and pipeline (backend) latency
Perf
| where TimeGenerated > ago(1h) 
| extend AgentLatencySeconds = (_TimeReceived-TimeGenerated)/1s,
	  PipelineLatencySeconds=(ingestion_time()-_TimeReceived)/1s
| summarize percentile(AgentLatencySeconds,90), percentile(PipelineLatencySeconds,90) by bin(TimeGenerated,5m)
| render columnchart

참고 항목

차트에는 90번째 백분위수 데이터가 누적 열로 표시되지만 두 차트의 데이터 합계는 총 처리 90번째 백분위수와 동일하지 않습니다.

수집량 모니터링

수집량 측정은 작업 영역의 전체 또는 테이블별 수집량에 대한 예기치 못한 변화를 식별하는 데 도움이 될 수 있습니다. 쿼리 볼륨 측정은 로그 수집과 관련된 성능 문제를 식별하는 데 도움이 될 수 있습니다. 유용한 부피 측정에는 다음이 포함됩니다.

• 테이블당 총 수집량
• 일정한 수집량(정지)
• 수집 변칙 - 수집량의 급증 및 감소

다음 섹션에서는 쿼리를 사용하여 작업 영역의 수집량을 확인하는 방법을 보여 줍니다.

테이블당 총 수집량 모니터링

작업 영역의 테이블당 수집량을 모니터링하는 쿼리를 정의할 수 있습니다. 쿼리에는 총 볼륨 또는 테이블별 볼륨에 대한 예기치 않은 변경 내용을 확인하는 경고가 포함될 수 있습니다.

이 쿼리는 테이블당 지난 시간 동안의 총 수집량을 초당 MB(메가바이트) 단위로 계산합니다.

// Calculate total ingestion volume over the past hour per table
Usage 
| where TimeGenerated > ago(1h) 
| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated,1h), DataType

수집 정지 확인

에이전트를 통해 로그를 수집하는 경우 에이전트의 하트비트를 사용하여 연결을 검색할 수 있습니다. 중지된 하트비트는 작업 영역에 대한 로그 수집 중단을 나타낼 수 있습니다. 쿼리 데이터에서 수집 정지 상태가 나타나면 원하는 응답을 트리거하는 조건을 정의할 수 있습니다.

다음 쿼리는 에이전트 하트비트를 확인하여 연결 문제를 검색합니다.

// Count agent heartbeats in the last ten minutes
Heartbeat 
| where TimeGenerated>ago(10m) 
| count

수집 변칙 모니터링

다양한 방법으로 작업 영역 수집 볼륨 데이터의 급증과 하락을 식별할 수 있습니다. series_decompose_anomalies() 함수를 사용하여 작업 영역에서 모니터링하는 수집량에서 변칙 현상을 추출하거나 고유한 작업 영역 시나리오를 지원하는 자체 변칙 감지기를 만듭니다.

series_decompose_anomalies를 사용하여 변칙 징후 식별

series_decompose_anomalies() 함수는 일련의 데이터 값에서 변칙을 식별합니다. 이 쿼리는 Log Analytics 작업 영역에 있는 각 테이블의 시간당 수집량을 계산하고 series_decompose_anomalies()를 사용하여 변칙을 식별합니다.

// Calculate hourly ingestion volume per table and identify anomalies
Usage
| where TimeGenerated > ago(24h)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| summarize
    Timestamp=make_list(TimeGenerated),
    IngestionVolumeMB=make_list(IngestionVolumeMB)
    by DataType
| extend series_decompose_anomalies(IngestionVolumeMB)
| mv-expand
    Timestamp,
    IngestionVolumeMB,
    series_decompose_anomalies_IngestionVolumeMB_ad_flag,
    series_decompose_anomalies_IngestionVolumeMB_ad_score,
    series_decompose_anomalies_IngestionVolumeMB_baseline
| where series_decompose_anomalies_IngestionVolumeMB_ad_flag != 0

series_decompose_anomalies()를 사용하여 로그 데이터의 변칙을 검색하는 방법에 대한 자세한 내용은 Azure Monitor에서 KQL 기계 학습 기능을 사용하여 변칙 검색 및 분석을 참조하세요.

사용자 고유의 변칙 감지기 만들기

작업 영역 구성에 대한 시나리오 요구 사항을 지원하기 위해 사용자 지정 변칙 감지기를 만들 수 있습니다. 이 섹션에서는 프로세스를 보여 주는 예를 제공합니다.

다음 쿼리는 다음을 계산합니다.

• 예상 수집량: 시간당, 테이블별(중앙값의 중앙값을 기준으로, 하지만 논리를 사용자 지정할 수 있음)
• 실제 수집량: 시간당, 테이블별

예상 수집량과 실제 수집량 사이의 사소한 차이를 필터링하기 위해 쿼리는 두 가지 필터를 적용합니다.

• 변동률: 테이블당 예상 볼륨의 150% 초과 또는 66% 미만
• 변화량: 증가 또는 감소한 볼륨이 해당 테이블의 월별 볼륨의 0.1%를 초과하는지 여부를 나타냅니다.

// Calculate expected vs actual hourly ingestion per table
let TimeRange=24h;
let MonthlyIngestionByType=
    Usage
    | where TimeGenerated > ago(30d)
    | summarize MonthlyIngestionMB=sum(Quantity) by DataType;
// Calculate the expected ingestion volume by median of hourly medians
let ExpectedIngestionVolumeByType=
    Usage
    | where TimeGenerated > ago(TimeRange)
    | project TimeGenerated, DataType, Quantity
    | summarize IngestionMedian=percentile(Quantity, 50) by bin(TimeGenerated, 1h), DataType
    | summarize ExpectedIngestionVolumeMB=percentile(IngestionMedian, 50) by DataType;
Usage
| where TimeGenerated > ago(TimeRange)
| project TimeGenerated, DataType, Quantity
| summarize IngestionVolumeMB=sum(Quantity) by bin(TimeGenerated, 1h), DataType
| join kind=inner (ExpectedIngestionVolumeByType) on DataType
| extend GapVolumeMB = round(IngestionVolumeMB-ExpectedIngestionVolumeMB,2)
| where GapVolumeMB != 0
| extend Trend=iff(GapVolumeMB > 0, "Up", "Down")
| extend IngestedVsExpectedAsPercent = round(IngestionVolumeMB * 100 / ExpectedIngestionVolumeMB, 2)
| join kind=inner (MonthlyIngestionByType) on DataType
| extend GapAsPercentOfMonthlyIngestion = round(abs(GapVolumeMB) * 100 / MonthlyIngestionMB, 2)
| project-away DataType1, DataType2
// Determine whether the spike/deep is substantial: over 150% or under 66% of the expected volume for this data type
| where IngestedVsExpectedAsPercent > 150 or IngestedVsExpectedAsPercent < 66
// Determine whether the gap volume is significant: over 0.1% of the total monthly ingestion volume to this workspace
| where GapAsPercentOfMonthlyIngestion > 0.1
| project
    Timestamp=format_datetime(todatetime(TimeGenerated), 'yyyy-MM-dd HH:mm:ss'),
    Trend,
    IngestionVolumeMB,
    ExpectedIngestionVolumeMB,
    IngestedVsExpectedAsPercent,
    GapAsPercentOfMonthlyIngestion

쿼리 성공 및 실패 모니터링

각 쿼리는 성공 또는 실패를 나타내는 응답 코드를 반환합니다. 쿼리가 실패하면 응답에 오류 유형도 포함됩니다. 오류 급증은 작업 영역 가용성이나 서비스 성능에 문제가 있음을 나타낼 수 있습니다.

이 쿼리는 서버 오류 코드를 반환한 쿼리 수를 계산합니다.

// Count query errors
LAQueryLogs 
| where ResponseCode>=500 and ResponseCode<600 
| count

제한 사항

• 전용 클러스터에 연결된 Log Analytics 작업 영역 복제는 현재 지원되지 않습니다.

• 작업 영역에서 레코드를 제거하는 제거 작업은 기본 작업 영역과 보조 작업 영역 모두에서 관련 레코드를 제거합니다. 작업 영역 인스턴스 중 하나를 사용할 수 없으면 제거 작업이 실패합니다.

• 지역 간 경고 규칙 복제는 현재 지원되지 않습니다. Azure Monitor는 비활성 지역 쿼리를 지원하므로 활성 지역의 경고 서비스가 제대로 작동하지 않거나 경고 규칙을 사용할 수 없는 경우가 아니면 지역 간에 전환할 때 쿼리 기반 경고가 계속 작동합니다.

• Sentinel과 상호 작용하는 작업 영역에 대해 복제를 사용하도록 설정하면 관심 목록 및 위협 인텔리전스 데이터를 보조 작업 영역에 완전히 복제하는 데 최대 12일이 걸릴 수 있습니다.

• 스위치오버 중에는 다음을 포함한 작업 영역 관리 작업이 지원되지 않습니다.

  • 작업 영역 보존, 가격 책정 계층, 일별 한도 등 변경
  • 네트워크 설정 변경
  • 새로운 사용자 지정 로그를 통해 스키마를 변경하거나 새로운 리소스 종류에서 진단 로그를 보내는 등 새로운 리소스 공급자의 플랫폼 로그를 연결합니다.

• 스위치오버 중에는 레거시 Log Analytics 에이전트의 솔루션 대상 지정 기능이 지원되지 않습니다. 따라서 스위치오버 중에 솔루션 데이터가 모든 에이전트에서 수집됩니다.

• 장애 조치(failover) 프로세스는 DNS(Domain Name System) 레코드를 업데이트하여 처리를 위해 모든 수집 요청을 보조 지역으로 다시 라우팅합니다. 일부 HTTP 클라이언트에는 "고정 연결"이 있으므로 DNS 업데이트된 DNS를 선택하는 데 시간이 더 오래 걸릴 수 있습니다. 스위치오버 중에 이러한 클라이언트는 일정 시간 동안 주 지역을 통해 로그 수집을 시도할 수 있습니다. 레거시 Log Analytics 에이전트, Azure Monitor 에이전트, 코드(로그 컬렉션 API 또는 레거시 HTTP 데이터 수집 API 사용) 및 Sentinel과 같은 기타 서비스를 포함한 다양한 클라이언트를 사용하여 기본 작업 영역에 로그를 수집할 수 있습니다.

• 이러한 기능은 현재 지원되지 않거나 부분적으로만 지원됩니다.

  기능	지원
  보조 테이블 계획	지원되지 않습니다. Azure Monitor는 보조 로그 계획이 있는 테이블의 데이터를 보조 작업 영역에 복제하지 않습니다. 따라서 이 데이터는 지역별 장애 발생 시 데이터 손실로부터 보호되지 않으며 보조 작업 영역으로 전환할 때 사용할 수 없습니다.
  작업 검색, 복원	부분적으로 지원 - 검색 작업 및 복원 작업은 테이블을 만들고 검색 결과 또는 복원된 데이터로 채웁니다. 작업 영역 복제를 사용하도록 설정하면 이러한 작업을 위해 만들어진 새 테이블이 보조 작업 영역에 복제됩니다. 복제를 사용하도록 설정하기 전에 채워진 테이블은 복제되지 않습니다. 스위치오버할 때 이러한 작업이 진행 중인 경우 결과는 예기치 못한 것입니다. 작업 영역 상태와 정확한 타이밍에 따라 성공적으로 완료되지만 복제되지 않거나 실패할 수 있습니다.
  Log Analytics 작업 영역에 대한 Application Insights	지원되지 않음
  VM 인사이트	지원되지 않음
  컨테이너 인사이트	지원되지 않음
  Private Link	장애 조치(failover) 중에는 지원되지 않음

관련 콘텐츠

• Log Analytics 작업 영역 상태 모니터링
• Azure Monitor Log Analytics 작업 영역에서 운영 문제 모니터링