메트릭을 사용하여 대기 중인 수집 모니터링

대기 중인 수집 프로세스에서 Azure Data Explorer는 구성 가능한 수집 일괄 처리 정책에 따라 들어오는 작은 데이터 청크를 일괄 처리로 일괄 처리하여 높은 처리량을 위해 데이터 수집을 최적화 합니다. 일괄 처리 정책을 사용하면 일괄 처리를 봉인하기 위한 트리거 조건(데이터 크기, Blob 수 또는 경과 시간)을 설정할 수 있습니다. 그런 다음, 이러한 일괄 처리는 빠른 쿼리 결과를 위해 최적으로 수집됩니다.

이 문서에서는 메트릭을 사용하여 Azure Portal에서 Azure Data Explorer에 대한 대기 중인 수집을 모니터링하는 방법을 알아봅니다.

일괄 처리 단계

이 섹션에 설명된 단계는 모든 일괄 처리 수집에 적용됩니다. Azure Event Grid, Azure Event Hubs, Azure IoT Hub 및 Cosmos DB 수집의 경우 데이터 수집을 위해 데이터가 큐에 대기되기 전에 데이터 연결 이 외부 원본에서 데이터를 가져오고 초기 데이터 다시 정렬을 수행합니다.

대기 중인 수집은 다음과 같은 단계로 수행됩니다.

1. Batching Manager는 메시지 수집을 위해 큐를 수신 대기하고 요청을 처리합니다.
2. Batching Manager는 수신하는 작은 수신 데이터 청크를 사용하고 수집 일괄 처리 정책에 따라 URL을 일괄 처리하여 수집 처리량을 최적화합니다.
3. 수집 관리자는 수집 명령을 Azure Data Explorer 스토리지 엔진에 보냅니다.
4. Azure Data Explorer 스토리지 엔진은 수집된 데이터를 저장하여 쿼리에 사용할 수 있도록 합니다.

Azure Data Explorer는 대기 중인 수집 프로세스의 모든 단계 및 구성 요소에서 데이터 수집을 모니터링할 수 있도록 Azure Monitor 수집 메트릭 집합을 제공합니다.

Azure Data Explorer 수집 메트릭은 다음에 대한 자세한 정보를 제공합니다.

• 대기 중인 수집의 결과입니다.
• 수집된 데이터의 양
• 대기 중인 수집의 대기 시간 및 발생 위치입니다.
• 일괄 처리 프로세스 자체
• Event Hubs, Event Grid 및 IoT Hub 수집의 경우: 수신된 이벤트 수입니다.

이 문서에서는 Azure Portal에서 수집 메트릭을 사용하여 Azure Data Explorer에 대한 대기 중인 수집을 모니터링하는 방법을 알아봅니다.

필수 구성 요소

• Azure 구독 평가판 Azure 계정을 만듭니다.
• Azure Data Explorer 클러스터 및 데이터베이스. 클러스터 및 데이터베이스를 만듭니다.
• Event Hubs, IoT Hub 또는 Event Grid와 같은 활성 큐에 대기된 수집입니다.

Azure Monitor 메트릭 탐색기로 메트릭 차트 만들기

다음은 이후 섹션에서 구현할 Azure Monitor 메트릭을 사용하는 방법에 대한 일반적인 설명입니다. Azure Portal에서 Azure Monitor 메트릭 탐색기를 사용하여 메트릭 차트를 만들려면 다음 단계를 사용합니다.

1. Azure Portal에 로그인하고 Azure Data Explorer 클러스터에 대한 개요 페이지로 이동합니다.

2. 왼쪽 탐색 모음에서 메트릭을 선택하여 메트릭 창을 엽니다.

3. 메트릭 창의 오른쪽 위에 있는 시간 선택 패널을 열고 시간 범위를 분석하려는 시간으로 변경합니다. 이 문서에서는 지난 48시간 동안 Azure Data Explorer에 대한 데이터 수집을 분석합니다.

4. 범위 및 메트릭 네임스페이스를 선택합니다.

   • 범위는 Azure Data Explorer 클러스터의 이름입니다. 다음 예제에서는 demo11이라는 클러스터를 사용합니다.
   • 메트릭 네임스페이스를 Kusto Cluster standard metrics로 설정해야 합니다. Azure Data Explorer 메트릭이 포함된 네임스페이스입니다.

   

5. 메트릭 이름과 관련 집계 값을 선택합니다.

이 문서의 일부 예제에서는 차원이 있는 메트릭에 필터 추가 및 분할 적용을 선택합니다. 또한 메트릭 추가를 사용하여 동일한 차트에 다른 메트릭을 표시하고 + 새 차트를 사용하여 한 보기에서 여러 차트를 볼 수 있습니다.

새 메트릭을 추가할 때마다 4단계와 5단계를 반복합니다.

이 문서에서는 대기 중인 수집을 추적하는 데 사용할 수 있는 메트릭과 이러한 메트릭을 사용하는 방법을 알아봅니다.

수집 결과 보기

수집 결과 메트릭은 성공적으로 수집된 총 원본 수와 수집하지 못한 원본 수에 대한 정보를 제공합니다.

이 예에서는 이 메트릭을 사용하여 수집을 시도한 결과를 살펴보고 상태 정보를 사용하여 실패한 시도의 문제를 해결합니다.

1. Azure Monitor 메트릭 창에서 메트릭 추가를 선택합니다.
2. 메트릭 값으로 수집 결과를 선택하고 집계 값으로 합계를 선택합니다. 이 선택 항목은 시간 경과에 따른 수집 결과를 한 차트 선에 보여줍니다.
3. 차트 위의 분할 적용 단추를 선택하고 상태를 선택하여 수집 결과의 상태에 따라 차트를 분류합니다. 분할 값을 선택한 후 분할 선택기 바깥쪽을 클릭하여 닫습니다.

이제 메트릭 정보가 상태별로 분할되고 수집 결과의 상태에 대한 정보가 세 줄로 분할된 것을 볼 수 있습니다.

1. 파랑은 성공적인 수집 작업입니다.
2. 주황색은 엔터티를 찾을 수 없어서 실패한 수집 작업입니다.
3. 자주색은 잘못된 요청으로 인해 실패한 수집 작업입니다.

수집 결과 차트를 살펴보면서 다음 사항을 고려하세요.

• 이벤트 허브 또는 IoT 허브 수집을 사용하는 경우 데이터 연결 구성 요소에 이벤트 사전 집계가 있습니다. 이 수집 단계에서 이벤트는 수집될 단일 원본으로 취급됩니다. 따라서 사전 집계 후 몇 개의 이벤트가 하나의 수집 결과로 나타납니다.
• 일시적인 실패는 내부적으로 다시 시도되며 시도 횟수가 제한됩니다. 각각의 일시적 실패는 일시적인 수집 결과로 보고됩니다. 따라서 단일 수집이 둘 이상의 수집 결과를 만들 수 있습니다.
• 차트의 수집 오류는 오류 코드의 범주별로 나열됩니다. 수집 오류 코드의 전체 목록을 범주별 살펴보고 가능한 오류 이유를 더 잘 이해하려면 Azure Data Explorer의 수집 오류 코드를 참조하세요.
• 수집 오류에 대한 자세한 내용을 보려면 실패한 수집 진단 로그를 설정하면 됩니다. 하지만, 로그를 생성하면 추가 리소스가 생성되므로 COGS(판매 제품 원가)가 증가한다는 점을 고려하는 것이 중요합니다.

수집된 데이터의 양 보기

Blob 처리됨, 수신된 Blob 및 Blob 삭제된 메트릭은 큐에 대기 중인 수집 단계 동안 수집 구성 요소에서 처리, 수신 및 삭제되는 Blob 수에 대한 정보를 제공합니다.

이 예에서는 이러한 메트릭을 사용하여 수집 파이프라인을 통해 전달된 데이터의 양, 수집 구성 요소가 받은 데이터의 양, 삭제된 데이터의 양을 확인합니다.

처리된 Blob

1. Azure Monitor 메트릭 창에서 메트릭 추가를 선택합니다.
2. 메트릭 값으로 처리된 Blob을 선택하고 집계 값으로 합계를 선택합니다.
3. 분할 적용 단추를 선택하고 구성 요소 유형을 선택하여 다양한 수집 구성 요소별로 차트를 분할합니다.
4. 클러스터의 특정 데이터베이스에 초점을 맞추려면 차트 위의 필터 추가 단추를 선택한 다음, 차트를 그릴 때 포함할 데이터베이스 값을 선택합니다. 이 예제에서는 GitHub 데이터베이스로 전송된 Blob을 필터링하기 위해 속성으로 데이터베이스를 선택하고, =로서 을 선택하며, 값 드롭다운에서 GitHub을 선택합니다. 필터 값을 선택한 후 필터 선택기 바깥쪽을 클릭하여 닫습니다.

이제 GitHub 데이터베이스로 전송된 Blob 중 시간이 지나면서 각 수집 구성 요소에서 처리된 수가 차트에 표시됩니다.

• 2월 13일에는 시간이 지나면서 GitHub 데이터베이스에 수집된 Blob 수가 감소했습니다. 또한 각 구성 요소에서 처리된 Blob의 수는 비슷합니다. 즉, 데이터 연결(Data Connection) 구성 요소에서 처리된 거의 모든 데이터는 일괄 처리 관리자(Batching Manager), 수집 관리자(Ingestion Manager) 및 Azure Data Explorer 스토리지 엔진 구성 요소에서도 성공적으로 처리되었습니다. 이 데이터는 쿼리에 사용할 수 있습니다.

받은 Blob

각 구성 요소가 받은 Blob 수와 각 구성 요소에서 성공적으로 처리된 Blob 수 간의 관계를 더 잘 이해하기 위해 새 차트를 추가하겠습니다.

1. + 새 차트를 선택합니다.
2. 범위, 메트릭 네임스페이스, 집계에 위와 동일한 값을 선택하고 받은 Blob 메트릭을 선택합니다.
3. 분할 적용 단추를 선택하고 구성 요소 유형을 선택하여 받은 Blob 메트릭을 구성 요소 유형별로 분할합니다.
4. 필터 추가 단추를 선택하고 이전과 동일한 값을 설정하여 GitHub 데이터베이스로 전송된 Blob만 필터링합니다

• 차트를 비교하면 각 구성 요소가 받은 Blob 수가 각 구성 요소에서 처리된 Blob 수와 거의 일치하는 것을 알 수 있습니다. 이러한 비교는 수집 중에 삭제된 Blob이 없음을 나타냅니다.

삭제된 Blob

수집 중에 삭제된 Blob이 있는지 여부를 확인하려면 삭제된 Blob 메트릭을 분석해야 합니다. 이 메트릭은 수집 중에 삭제된 Blob 수를 보여주고 특정 수집 구성 요소에서 처리하는 데 문제가 있는지 여부를 검색하는 데 유용합니다. 삭제된 각 Blob에 대해서는 실패 이유에 대한 자세한 정보가 포함된 수집 결과 메트릭도 제공됩니다.

수집 대기 시간 보기

단계 대기 시간 및 검색 대기 시간 메트릭은 수집 프로세스의 대기 시간을 모니터링하며 Azure Data Explorer에서 또는 데이터가 수집을 위해 Azure Data Explorer에 도착하기 전에 긴 대기 시간이 발생하는지 알려줍니다.

• 단계 대기 시간은 Azure Data Explorer에서 메시지가 검색된 시점부터 처리를 위해 수집 구성 요소가 해당 콘텐츠를 받을 때까지의 시간 범위를 나타냅니다.
• 검색 대기 시간은 데이터 연결(예: 이벤트 허브, IoT Hub 및 Event Grid)이 있는 파이프라인을 수집하는 데 사용됩니다. 이 메트릭은 데이터 큐에서 Azure Data Explorer 데이터 연결에 의한 검색까지의 시간 범위에 대한 정보를 제공합니다. 이 시간 범위는 Azure Data Explorer의 업스트림이므로 Azure Data Explorer의 대기 시간만 측정하는 단계 대기 시간 메트릭에는 포함되지 않습니다.

데이터를 쿼리할 준비가 될 때까지 대기 시간이 긴 경우, 단계 대기 시간 및 검색 대기 시간을 분석하면 긴 대기 시간이 Azure Data Explorer의 긴 대기 시간 때문인지 아니면 Azure Data Explorer의 업스트림 때문인지 파악하는 데 도움이 됩니다. Azure Data Explorer 자체에 대기 시간이 있는 경우 긴 대기 시간의 원인이 되는 특정 구성 요소를 감지할 수도 있습니다.

단계 대기 시간(미리 보기)

먼저 대기 중인 수집의 단계 대기 시간을 살펴보겠습니다. 각 단계에 대한 설명은 일괄 처리 단계를 참조하세요.

1. Azure Monitor 메트릭 창에서 메트릭 추가를 선택합니다.
2. 메트릭 값으로 단계 대기 시간을 선택하고 집계 값으로 평균을 선택합니다.
3. 분할 적용 단추를 선택하고 구성 요소 유형을 선택하여 다양한 수집 구성 요소별로 차트를 분할합니다.
4. 필터 추가 단추를 선택하고 GitHub 데이터베이스로 전송된 데이터를 필터링합니다. 필터 값을 선택한 후 필터 선택기 바깥쪽을 클릭하여 닫습니다. 이제 수집을 통해 각 구성 요소에서 GitHub 데이터베이스로 전송되는 수집 작업의 시간 경과에 따른 대기 시간이 차트에 표시됩니다.

이 차트에서 다음 정보를 확인할 수 있습니다.

• Event Hubs 데이터 연결 구성 요소의 대기 시간은 약 0초입니다. 단계 대기 시간은 Azure Data Explorer에서 메시지가 검색된 이후의 대기 시간만 측정하기 때문에 타당합니다.
• 수집 프로세스에서 가장 긴 시간(약 5분)은 일괄 처리 관리자(Batching Manager) 구성 요소가 데이터를 받은 시점부터 수집 관리자(Ingestion Manager) 구성 요소가 데이터를 받은 시점까지입니다. 이 예에서는 GitHub 데이터베이스에 대한 기본 일괄 처리 정책을 사용합니다. 앞에서 설명한 것처럼 기본 일괄 처리 정책의 대기 시간 제한은 5분이므로 거의 모든 데이터가 시간별로 일괄 처리되었으며 대기 중인 수집에 대한 대기 시간 대부분은 일괄 처리 자체 때문임을 나타냅니다.
• 차트의 스토리지 엔진 대기 시간은 데이터가 Azure Data Explorer 스토리지 엔진에 저장되고 쿼리할 준비가 될 때까지의 대기 시간을 나타냅니다. Azure Data Explorer의 데이터 검색 시간부터 쿼리용으로 준비가 될 때까지의 평균 총 대기 시간이 5.2분임을 알 수 있습니다.

검색 대기 시간

데이터 연결과 함께 수집을 사용하는 경우 Azure Data Explorer가 수집을 위해 데이터를 가져오기 전에 긴 대기 시간이 발생할 수도 있으므로 시간 경과에 따른 Azure Data Explorer에 대한 업스트림 대기 시간을 추정하는 것이 좋습니다. 이러한 목적을 위해 검색 대기 시간 메트릭을 사용할 수 있습니다.

1. + 새 차트를 선택합니다.
2. 메트릭 값으로 검색 대기 시간을 선택하고 집계 값으로 평균을 선택합니다.
3. 분할 적용 단추를 선택하고 구성 요소 유형을 선택하여 다양한 데이터 연결 구성 요소 유형별로 차트를 분할합니다. 분할 값을 선택한 후 분할 선택기 바깥쪽을 클릭하여 닫습니다.

• 대부분의 기간 동안 검색 대기 시간이 0초에 가까우며, 이것은 데이터를 큐에 넣은 직후에 Azure Data Explorer가 데이터를 얻었음을 나타냅니다. 최고 피크인 약 300밀리초는 2월 13일 14:00 경이며, 이때 Azure Data Explorer 클러스터는 데이터를 큐에 넣고 약 300밀리초 후에 데이터를 받았음을 나타냅니다.

일괄 처리 프로세스 이해

대기 중인 수집 흐름의 두 번째 단계에서 Batching Manager 구성 요소는 수집 일괄 처리 정책에 따라 수신하는 데이터를 일괄 처리하여 수집 처리량을 최적화합니다.

다음 메트릭 집합을 통해 수집 중에 데이터가 일괄 처리되는 방식을 이해할 수 있습니다.

• 처리된 일괄 처리: 수집을 위해 완료된 일괄 처리의 수입니다.
• 일괄 처리 크기: 수집을 위해 집계된 일괄 처리에서 압축되지 않은 데이터의 예상 크기입니다.
• 일괄 처리 기간: 일괄 처리가 열리는 순간부터 일괄 처리 밀봉까지 각 개별 일괄 처리의 지속 시간입니다.
• 일괄 처리 Blob 수: 수집을 위해 완료된 일괄 처리의 Blob 수입니다.

처리된 일괄 처리

처리된 일괄 처리 메트릭을 살펴보면서 일괄 처리 프로세스를 전반적으로 살펴보겠습니다.

1. Azure Monitor 메트릭 창에서 메트릭 추가를 선택합니다.
2. 메트릭 값으로 처리된 일괄 처리를 선택하고 집계 값으로 합계를 선택합니다.
3. 분할 적용 단추를 선택하고 일괄 처리 유형을 선택하여 일괄 처리가 봉인된 이유에 따라 차트를 분할합니다. 일괄 처리 유형의 전체 목록은 일괄 처리 유형을 참조하세요.
4. 필터 추가 단추를 선택하고 GitHub 데이터베이스로 전송된 일괄 처리를 필터링합니다. 필터 값을 선택한 후 필터 선택기 바깥쪽을 클릭하여 닫습니다.

GitHub 데이터베이스로 전송된 데이터가 포함되어 있는 봉인된 시간별 일괄 처리의 수가, 일괄 처리 유형으로 분할되어 차트에 표시됩니다.

• 시간 단위당 일괄 처리는 2~4개이며, 모든 일괄 처리는 단계 대기 시간 섹션에서 예상한 대로(기본 일괄 처리 정책에 따라 데이터를 일괄 처리하는 데 약 5분이 소요되는 것을 볼 수 있음) 시간에 따라 봉인됩니다.

일괄 처리 기간, 크기 및 Blob 수

이제 처리된 일괄 처리의 특징을 더 자세히 살펴보겠습니다.

1. 각 차트에 대해 + 차트 추가 단추를 선택하여 메트릭 값 일괄 처리 기간, 일괄 처리 크기 및 일괄 처리 Blob 수에 대한 차트를 더 만듭니다.
2. 평균을 집계 값으로 사용합니다.
3. 앞의 예에서와 같이, 필터 추가 단추를 선택하고 GitHub 데이터베이스로 전송된 데이터를 필터링합니다.

일괄 처리 기간, 일괄 처리 크기, 일괄 처리 Blob 수 차트에서 몇 가지 인사이트를 얻을 수 있습니다.

• 평균 일괄 처리 기간은 기본 일괄 처리 정책에 따라 5분입니다. 총 수집 대기 시간을 살펴볼 때 이 점을 고려해야 합니다.

• 일괄 처리 크기 차트에서 일괄 처리의 평균 크기는 시간이 지나면서 약 200~500MB임을 알 수 있습니다. 수집할 최적의 데이터 크기는 비압축 데이터 1GB이며, 이 크기도 기본 일괄 처리 정책에 의해 봉인 조건으로 정의됩니다. 시간이 지나도 일괄 처리할 데이터가 1GB가 되지 않아서 크기에 따라 봉인된 일괄 처리는 보이지 않습니다.

• 일괄 처리의 평균 Blob 수는 시간 경과에 따라 Blob 약 160개이며, 이후 Blob 60~120개로 감소합니다. 기본 일괄 처리 정책에 따라 Blob 수가 1000개이면 일괄 처리가 봉인될 수 있습니다. 이 수에 도착하지 않으므로 일괄 처리가 개수별로 봉인되지 않습니다.

수집용으로 보낸 이벤트와 받은 이벤트 비교

이벤트 허브, IoT Hub 또는 Event Grid 수집을 적용할 때 Azure Data Explorer에서 받은 이벤트 수를 이벤트 원본에서 Azure Data Explorer로 전송된 이벤트 수와 비교하는 것이 유용할 수 있습니다. 받은 이벤트, 처리된 이벤트, 삭제된 이벤트 메트릭을 사용하여 이러한 비교를 수행할 수 있습니다.

받은 이벤트

1. Azure Monitor 메트릭 창에서 메트릭 추가를 선택합니다.
2. 메트릭 값으로 받은 이벤트를 선택하고 집계 값으로 합계를 선택합니다.
3. 차트 위의 필터 추가 단추를 선택하고 속성 값 구성 요소 이름을 선택하여 클러스터에 정의된 특정 데이터 연결에서 받은 이벤트를 필터링합니다. 이 예에서는 GitHubStreamingEvents 데이터 연결을 필터링합니다. 필터 값을 선택한 후 필터 선택기 바깥쪽을 클릭하여 닫습니다.

이제 선택한 데이터 연결에서 시간이 지나면서 받은 이벤트 수가 차트에 표시됩니다.

• 이 차트에서 GitHubStreamingEvents 데이터 연결은 시간이 지나면서 시간 단위당 약 200~500개의 이벤트를 받습니다.

처리된 이벤트 및 삭제된 이벤트

Azure Data Explorer에서 삭제된 이벤트가 있는지 확인하려면 처리된 이벤트 및 삭제된 이벤트 메트릭을 사용합니다.

1. 이미 만든 차트에서 메트릭 추가를 선택합니다.
2. 메트릭 값으로 처리된 이벤트를 선택하고 집계 값으로 합계를 선택합니다.
3. 메트릭 추가를 다시 선택하고 메트릭 값으로 삭제된 이벤트를 선택하고 집계 값으로 합계를 선택합니다.

이제 GitHubStreamingEvents 데이터 연결에서 시간이 지나면서 받은 이벤트, 처리된 이벤트 및 삭제된 이벤트 수가 차트에 표시됩니다.

• 거의 모든 받은 이벤트가 데이터 연결에 의해 성공적으로 처리되었습니다. 삭제된 이벤트가 하나 있으며, 이것은 수집 결과 메트릭을 볼 때 표시된 잘못된 요청으로 인해 실패한 수집 결과와 호환됩니다.

Azure Data Explorer에서 받은 이벤트를 이벤트 허브에서 보내는 메시지와 비교

받은 이벤트와 보내는 메시지 메트릭을 비교하면 받은 이벤트 수와 이벤트 허브에서 Azure Data Explorer로 보낸 이벤트 수를 비교할 수도 있습니다.

1. 받은 이벤트에 대해 이미 만든 차트에서 메트릭 추가를 선택합니다.

2. 범위를 선택하고 범위 선택 대화 상자에서 데이터 연결에 데이터를 보내는 이벤트 허브의 네임스페이스를 찾아서 선택합니다.

   

3. 적용을 선택합니다.

4. 메트릭 값으로 보내는 메시지를 선택하고 집계 값으로 합계를 선택합니다.

설정 바깥쪽을 클릭하면 Azure Data Explorer 데이터 연결에서 처리된 이벤트 수와 이벤트 허브에서 보낸 이벤트 수를 비교하는 전체 차트가 표시됩니다.

• 이벤트 허브에서 보낸 모든 이벤트는 Azure Data Explorer 데이터 연결에 의해 성공적으로 처리되었습니다.
• 이벤트 허브 네임스페이스에 이벤트 허브가 둘 이상 있는 경우 이벤트 허브 네임스페이스에 있는 원하는 이벤트 허브의 데이터만 가져오려면 보내는 메시지 메트릭을 엔터티 이름 차원으로 필터링해야 합니다.

관련 콘텐츠

• 메트릭을 사용하여 Azure Data Explorer 성능, 상태 및 사용량 모니터링
• 진단 로그를 사용하여 Azure Data Explorer 수집, 명령, 쿼리 및 테이블 모니터링
• Azure Monitor 인사이트 사용