Azure Monitor의 로그 데이터 수집 시간

아티클
11/21/2024

Azure Monitor는 점점 더 빠른 속도로 매달 테라바이트의 데이터를 보내는 수천 명의 고객에게 서비스를 제공하는 대규모 데이터 서비스입니다. 로그 데이터가 수집된 후 사용할 수 있기까지 걸리는 시간에 대해 질문하는 경우가 많습니다. 이 문서에서는 이 대기 시간에 영향을 주는 여러 요인에 대해 설명합니다.

평균 대기 시간

대기 시간은 모니터링되는 시스템에서 데이터가 생성된 시간과 Azure Monitor에서 데이터를 분석에 사용할 수 있는 시간을 참조합니다. 로그 데이터 수집을 위한 평균 대기 시간은 20초에서 3분 사이입니다. 특정 데이터에 대한 특정 대기 시간은 이 문서에서 설명하는 여러 요인에 따라 달라집니다.

대기 시간에 영향을 주는 요인

특정 데이터 집합의 총 수집 시간을 다음과 같은 상위 수준 영역으로 분석할 수 있습니다.

에이전트 시간: 이벤트를 발견하고 수집한 다음 로그 레코드로 데이터 수집 엔드포인트에 보내는 시간입니다. 대부분의 경우, 이 프로세스는 에이전트가 처리합니다. 네트워크에서 더 많은 대기 시간이 발생할 수 있습니다.
파이프라인 시간: 수집 파이프라인이 로그 레코드를 처리하는 시간입니다. 이 기간에는 이벤트 속성을 구문 분석하고 잠재적으로 계산된 정보를 추가하는 작업이 포함됩니다.
인덱싱 시간: 로그 레코드를 Azure Monitor 빅 데이터 저장소에 수집하는 데 소요되는 시간입니다.

이 프로세스에서 발생하는 다양한 대기 시간에 대한 자세한 내용은 다음 섹션에서 설명합니다.

에이전트 수집 대기 시간

시간이 달라짐

에이전트 및 관리 솔루션은 다양한 전략을 사용하여 가상 머신에서 데이터를 수집하므로 대기 시간에 영향을 줄 수 있습니다. 몇 가지 구체적인 예가 다음 표에 나열되어 있습니다.

데이터 형식	수집 빈도	주의
Windows 이벤트, Syslog 이벤트 및 성능 메트릭	즉시 수집됨
Linux 성능 카운터	30초 간격으로 폴링됨
IIS 로그 및 텍스트 로그	타임스탬프가 변경된 후 수집됨	IIS 로그의 경우 이 일정은 IIS에 구성된 롤오버 일정의 영향을 받습니다.
Active Directory 복제 솔루션	5일마다 평가	에이전트는 평가가 완료된 경우에만 로그를 수집합니다.
Active Directory 평가 솔루션	Active Directory 인프라에 대한 주간 평가	에이전트는 평가가 완료된 경우에만 로그를 수집합니다.

에이전트 업로드 빈도

1분 미만

Log Analytics 에이전트를 경량으로 유지하기 위해 에이전트는 로그를 버퍼링하고 주기적으로 Azure Monitor에 업로드합니다. 업로드 빈도는 데이터 형식에 따라 30초에서 2분 사이입니다. 대부분의 데이터는 1분 이내에 업로드됩니다.

네트워크

다양함

네트워크 조건은 데이터 수집 엔드포인트에 도달하기 위해 이 데이터의 대기 시간에 부정적인 영향을 미칠 수 있습니다.

Azure 메트릭, 리소스 로그, 활동 로그

30초~20분

Azure 데이터는 처리를 위해 데이터 수집 엔드포인트에서 사용할 수 있는 시간을 더 추가합니다.

Azure 플랫폼 메트릭은 메트릭 데이터베이스에서 1분 이내에 사용할 수 있지만 데이터 수집 엔드포인트로 내보내려면 3분이 더 걸립니다.
리소스 로그에는 일반적으로 Azure 서비스에 따라 30-90초가 추가적으로 소요됩니다. 일부 Azure 서비스(특히 Azure SQL Database 및 Azure Virtual Network)는 현재 5분 간격으로 로그를 보고합니다. 이번에는 더 개선하기 위한 작업이 진행 중입니다. 사용자 환경에서 이 대기 시간을 조사하려면 다음 쿼리를 참조하세요.
활동 로그는 3~20분 후에 분석 및 경고에 사용할 수 있습니다.

관리 솔루션 수집

다양함

일부 솔루션은 에이전트에서 데이터를 수집하지 않으며 더 많은 대기 시간을 도입하는 수집 방법을 사용할 수 있습니다. 일부 솔루션은 거의 실시간으로 수집하지 않고 주기적으로 데이터를 수집합니다. 구체적인 예는 다음과 같습니다.

Microsoft 365 솔루션은 현재 거의 실시간 대기 시간을 보장하지 않는 관리 작업 API를 사용하여 활동 로그를 폴링합니다.
Windows Analytics 솔루션(예: 업데이트 준수) 데이터는 매일 솔루션에 의해 수집됩니다.

솔루션의 컬렉션 빈도를 확인하려면 각 솔루션에 대한 설명서를 참조하세요.

파이프라인 프로세스 시간

30~60초

데이터 수집 엔드포인트에서 데이터를 사용할 수 있게 된 후 쿼리에 사용할 수 있는 데 30~60초가 더 걸립니다.

로그 레코드가 Azure Monitor 파이프라인에 수집되고 나면(_TimeReceived 속성에 식별), 테넌트 격리를 보장하고 해당 데이터가 손실되지 않도록 임시 스토리지에 기록됩니다. 이 프로세스는 일반적으로 5~15초를 추가합니다.

일부 솔루션은 데이터가 스트리밍될 때 데이터를 집계하고 인사이트를 파생하기 위해 부하가 높은 알고리즘을 구현합니다. 예를 들어, Application Insights는 애플리케이션 맵 데이터를 계산합니다. Azure 네트워크 성능 모니터링은 3분 간격으로 들어오는 데이터를 집계하여 3분 대기 시간을 효과적으로 추가합니다.

데이터 수집에 수집 시간 변환이 포함되는 경우 파이프라인에 약간의 대기 시간이 추가됩니다. 분당 로그 변환 기간 메트릭을 사용하여 변환 쿼리의 효율성을 모니터링합니다.

대기 시간을 증가시키는 또 다른 프로세스는 사용자 지정 로그를 처리하는 프로세스입니다. 경우에 따라 이 프로세스로 인해 로그에 에이전트가 파일에서 수집하는 대기 시간이 몇 분 정도 추가될 수 있습니다.

새 사용자 지정 데이터 형식 프로비저닝

사용자 지정 로그 또는 데이터 수집기 API에서 새 사용자 지정 데이터 형식이 생성되는 경우, 시스템이 전용 스토리지 컨테이너를 만듭니다. 이 일회용 오버헤드는 이 데이터 형식이 처음 나타날 때만 발생합니다.

서지 보호

일반적으로 1분 미만이지만 더 걸릴 수 있음

Azure Monitor의 최우선 과제는 고객 데이터가 손실되지 않도록 하는 것이므로, 시스템에 데이터 서지에 대한 보호 기능이 기본 제공됩니다. 이 보호 함수에는 막대한 부하가 걸리는 경우에도 시스템이 계속 작동하도록 보장하는 버퍼가 포함됩니다. 정상 부하에서 이러한 컨트롤은 1분도 채 걸리지 않습니다. 극단적인 조건과 오류 상황에서는 데이터를 안전하게 유지하는 반면 상당한 시간이 추가될 수 있습니다.

인덱싱 시간

5분 이하

모든 빅 데이터 플랫폼에는 데이터를 즉시 액세스할 수 있도록 하는 것과 분석 및 고급 검색 기능을 제공하는 것 사이의 적절한 균형이 기본 제공됩니다. Azure Monitor를 사용하면 수십억 개의 레코드에 대해 강력한 쿼리를 실행하고 몇 초 안에 결과를 가져올 수 있습니다. 이러한 성능은 인프라가 수집 중에 데이터를 극적으로 변환하고 고유한 압축 구조에 저장하기 때문에 가능합니다. 이러한 구조를 만들기에 충분할 때까지 데이터가 시스템에 버퍼링됩니다. 로그 레코드가 검색 결과에 나타나기 전에 이 프로세스를 완료해야 합니다.

이 프로세스는 현재 데이터 양이 적을 때 약 5분 정도 걸리지만 데이터 속도가 높을수록 시간이 덜 걸릴 수 있습니다. 이 동작은 모순되는 것 같지만 이 프로세스를 통해 대량 프로덕션 워크로드에 대한 대기 시간을 최적화할 수 있습니다.

수집 시간 확인

수집 시간은 상황에 따라 리소스마다 다를 수 있습니다. 로그 쿼리를 사용하여 현재 환경의 특정 동작을 파악할 수 있습니다. 다음 표에서는 레코드를 만들고 Azure Monitor로 전송할 때 레코드에 대해 다른 시간을 결정하는 방법을 지정합니다.

단계	속성 또는 함수	설명
데이터 원본에 생성되는 레코드	TimeGenerated	TimeGenerated 값은 수신된 시간보다 2일 이상 또는 나중에 하루 이상 될 수 없습니다. 그렇지 않으면 Azure Monitor 로그는 TimeGenerated 값을 실제 수신 시간으로 바꿉니다. 데이터 원본이 이 값을 설정하지 않으면 Azure Monitor 로그는 값을 _TimeReceived 동일한 시간으로 설정합니다.
데이터 수집 엔드포인트에서 수신한 레코드	_TimeReceived	이 필드는 대량 처리에 최적화되어 있지 않으며 대규모 데이터 세트를 필터링하는 데 사용해서는 안 됩니다.
작업 영역에 저장되어 쿼리에 사용할 수 있는 레코드	ingestion_time()	특정 기간에 수집된 레코드만 필터링해야 하는 경우 `ingestion_time()`을 사용하는 것이 좋습니다. 이러한 경우 더 넓은 범위의 `TimeGenerated` 필터를 추가하는 것이 좋습니다.

수집 대기 시간 지연

ingestion_time() 함수의 결과를 TimeGenerated 속성과 비교하여 특정 레코드의 대기 시간을 측정할 수 있습니다. 이 데이터는 다양한 집계와 함께 사용되어 수집 대기 시간이 작동하는 방식을 발견할 수 있습니다. 수집 시간의 백분위수 몇 개를 검사하면 대량의 데이터 수집 시간 관련 정보를 파악할 수 있습니다.

예를 들어 다음 쿼리는 8시간 전에 수집 시간이 가장 긴 컴퓨터를 보여 줍니다.

Heartbeat
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer 
| top 20 by percentile_E2EIngestionLatency_95 desc

위의 백분위 수 검사는 대기 시간의 일반적인 추세를 찾는 데 유용합니다. 대기 시간의 단기 스파이크를 식별하기 위해서는 최대값(max())이 더 효과적일 수 있습니다.

일정 기간 동안 특정 컴퓨터의 수집 시간을 드릴다운하려는 경우 다음 쿼리를 사용합니다. 이 쿼리도 전날의 데이터를 그래프에 표시합니다.

Heartbeat 
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"  
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60 
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60 
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m) 
| render timechart

다음 쿼리를 사용하여 IP 주소를 기반으로 컴퓨터가 위치한 국가/지역별로 컴퓨터 수집 시간을 표시합니다.

Heartbeat 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

에이전트에서 생성되는 각 데이터 형식의 수집 대기 시간은 서로 다를 수 있으므로 위의 쿼리를 다른 형식에 사용할 수도 있습니다. 여러 Azure 서비스의 수집 시간을 검사하려면 다음 쿼리를 사용합니다.

AzureDiagnostics 
| where TimeGenerated > ago(8h) 
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated 
| extend AgentLatency = _TimeReceived - TimeGenerated 
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

동일한 쿼리 논리를 사용하여 Application Insights 데이터에 대한 대기 시간 조건을 진단합니다.

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp  > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated  > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure ,  ingestion_time(), TimeRequiredtoIngest, EndtoEndTime 
| sort by EndtoEndTime desc

위의 두 쿼리는 "requests"가 아닌 다른 Application Insights 테이블과 쌍으로 연결될 수 있습니다.

응답하지 않는 리소스

리소스에서 데이터 전송이 중지되는 경우도 있습니다. 리소스가 데이터를 전송하고 있는지를 파악하려면 표준 TimeGenerated 필드를 통해 식별 가능한 최신 레코드를 확인하세요.

하트비트는 에이전트에서 1분에 한 번 전송되므로 Heartbeat 테이블을 사용하여 VM의 가용성을 확인합니다. 최근 하트비트를 보고하지 않은 활성 컴퓨터 목록을 표시하려면 다음 쿼리를 사용합니다.

Heartbeat  
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer  
| top 20 by NoHeartbeatPeriod desc

다음 단계

Azure Monitor에 대한 서비스 수준 계약을 참조하세요.

다음을 통해 공유