높은 데이터 수집으로 인해 Application Insights 또는 Log Analytics에 대한 청구 요금이 증가하는 경우가 많습니다. 이 문서는 이 문제를 해결하는 데 도움이 되며 데이터 수집 비용을 줄이는 방법을 제공합니다.
일반적인 문제 해결 단계
1단계: 높은 데이터 수집을 제공하는 리소스 식별
Azure Portal에서 구독으로 이동하고 Cost Management>비용 분석을 선택합니다. 이 블레이드는 다음과 같이 리소스당 비용을 차트로 제공하는 비용 분석 보기를 제공합니다.
2단계: 높은 데이터 수집으로 비용이 많이 드는 테이블 식별
Application Insights 리소스 또는 Log Analytics 작업 영역을 식별한 후에는 데이터를 분석하고 가장 높은 수집이 발생하는 위치를 결정합니다. 시나리오에 가장 적합한 방법을 고려합니다.
원시 레코드 수 기반
다음 쿼리를 사용하여 테이블의 레코드 수를 비교합니다.
search * | where timestamp > ago(7d) | summarize count() by $table | sort by count_ desc이 쿼리는 가장 시끄러운 테이블을 식별하는 데 도움이 될 수 있습니다. 여기에서 쿼리를 구체화하여 조사 범위를 좁힐 수 있습니다.
사용된 바이트 기준
format_bytes() 스칼라 함수를 사용하여 바이트 수집이 가장 높은 테이블을 결정합니다.
systemEvents | where timestamp > ago(7d) | where type == "Billing" | extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"]) | extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"]) | summarize TotalBillingTelemetrySize = sum(BillingTelemetrySizeInBytes) by BillingTelemetryType | extend BillingTelemetrySizeGB = format_bytes(TotalBillingTelemetrySize, 1 ,"GB") | sort by BillingTelemetrySizeInBytes desc | project-away BillingTelemetrySizeInBytes레코드 개수 쿼리와 마찬가지로 이전 쿼리는 가장 활성 테이블을 식별하는 데 도움이 되므로 추가 조사를 위해 특정 테이블을 정확히 파악할 수 있습니다.
Log Analytics 작업 영역의 통합 문서(Workbook) 사용
Azure Portal에서 Log Analytics 작업 영역으로 이동하고, 모니터링>에서 통합문서를 선택한 다음 Log Analytics 작업 영역 인사이트 아래의 사용량을 선택합니다.
이 통합 문서에서는 각 테이블에 대한 데이터 수집 비율 및 동일한 작업 영역에 보고하는 각 리소스에 대한 자세한 수집 통계와 같은 중요한 인사이트를 제공합니다.
3단계: 높은 데이터 수집에 기여하는 요인 확인
높은 데이터 수집을 사용하여 테이블을 식별한 후 가장 높은 작업이 있는 테이블에 초점을 맞추고 높은 데이터 수집에 영향을 주는 요인을 결정합니다. 이는 다른 애플리케이션보다 더 많은 데이터를 생성하는 특정 애플리케이션, 너무 자주 기록되는 예외 메시지 또는 너무 많은 정보를 내보내는 새 로거 범주일 수 있습니다.
다음은 이 식별에 사용할 수 있는 몇 가지 샘플 쿼리입니다.
requests
| where timestamp > ago(7d)
| summarize count() by cloud_RoleInstance
| sort by count_ desc
requests
| where timestamp > ago(7d)
| summarize count() by operation_Name
| sort by count_ desc
dependencies
| where timestamp > ago(7d)
| summarize count() by cloud_RoleName
| sort by count_ desc
dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc
traces
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc
exceptions
| where timestamp > ago(7d)
| summarize count() by message
| sort by count_ desc
다른 원격 분석 필드를 사용해 볼 수 있습니다. 예를 들어 먼저 다음 쿼리를 실행하고 과도한 원격 분석에 대한 명백한 원인이 없는지 확인할 수 있습니다.
dependencies
| where timestamp > ago(7d)
| summarize count() by target
| sort by count_ desc
그러나 target 대신 type 같은 다른 원격 분석 필드를 시도할 수 있습니다.
dependencies
| where timestamp > ago(7d)
| summarize count() by type
| sort by count_ desc
일부 시나리오에서는 특정 애플리케이션 또는 인스턴스를 추가로 조사해야 할 수 있습니다. 다음 쿼리를 사용하여 시끄러운 메시지 또는 예외 유형을 식별합니다.
traces
| where timestamp > ago(7d)
| where cloud_RoleName == 'Specify a role name'
| summarize count() by type
| sort by count_ desc
exceptions
| where timestamp > ago(7d)
| where cloud_RoleInstance == 'Specify a role instance'
| summarize count() by type
| sort by count_ desc
4단계: 시간에 따른 데이터 처리 방식의 변화 조사
이전에 확인된 요인에 따라 시간이 지남에 따라 섭취의 진화를 검토합니다. 이러한 방식으로 이 동작이 일관되었는지 또는 특정 지점에서 변경이 발생했는지 여부를 확인할 수 있습니다. 이러한 방식으로 데이터를 분석하면 변경이 발생한 시기를 정확히 파악하고 높은 데이터 수집의 원인을 보다 명확하게 이해할 수 있습니다. 이 인사이트는 문제를 해결하고 효과적인 솔루션을 구현하는 데 중요합니다.
다음 쿼리에서는 bin() KQL(Kusto Query Language) 스칼라 함수를 사용하여 데이터를 1일 간격으로 분할합니다. 이 방법은 시간이 지남에 따라 데이터가 어떻게 변경되었는지 확인할 수 있으므로 추세 분석을 용이하게 합니다.
dependencies
| where timestamp > ago(30d)
| summarize count() by bin(timestamp, 1d), operation_Name
| sort by timestamp desc
집계 함수를 min() 사용하여 특정 요인에 대해 기록된 가장 빠른 타임스탬프를 식별합니다. 이 방법은 기준을 설정하는 데 도움이 되며 이벤트 또는 변경이 처음 발생한 시기에 대한 인사이트를 제공합니다.
dependencies
| where timestamp > ago(30d)
| where type == 'Specify dependency type being investigated'
| summarize min(timestamp) by type
| sort by min_timestamp desc
특정 시나리오에 대한 문제 해결 단계
시나리오 1: Log Analytics에서 높은 데이터 수집
Log Analytics 작업 영역 내의 모든 테이블을 쿼리합니다.
search * | where TimeGenerated > ago(7d) | where _IsBillable == true | summarize TotalBilledSize = sum(_BilledSize) by $table | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB") | sort by TotalBilledSize desc | project-away TotalBilledSize비용에 가장 큰 기여를 하는 테이블은 알 수 있습니다.
AppTraces의 예제는 다음과 같습니다.
추적 비용을 구동하는 특정 애플리케이션을 쿼리합니다.
AppTraces | where TimeGenerated > ago(7d) | where _IsBillable == true | summarize TotalBilledSize = sum(_BilledSize) by AppRoleName | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB") | sort by TotalBilledSize desc | project-away TotalBilledSize
해당 애플리케이션과 관련된 다음 쿼리를 실행하십시오. 그리고
AppTraces테이블에 원격 분석 데이터를 보내는 특정 로거 범주를 자세히 조사합니다.AppTraces | where TimeGenerated > ago(7d) | where _IsBillable == true | where AppRoleName contains 'transformation' | extend LoggerCategory = Properties['Category'] | summarize TotalBilledSize = sum(_BilledSize) by tostring(LoggerCategory) | extend IngestedVolumeGB = format_bytes(TotalBilledSize, 1, "GB") | sort by TotalBilledSize desc | project-away TotalBilledSize결과는 비용을 담당하는 두 가지 주요 범주를 보여줍니다.
시나리오 2: Application Insight에서 높은 데이터 수집
비용에 영향을 주는 요인을 확인하려면 다음 단계를 수행합니다.
모든 테이블에서 원격 분석을 조회하고, 테이블별 및 SDK 버전별로 레코드 수를 가져옵니다.
search * | where TimeGenerated > ago(7d) | summarize count() by $table, SDKVersion | sort by count_ desc다음 예제에서는 Azure Functions가 다량의 추적 및 예외 원격 분석 데이터를 생성하고 있음을 보여 줍니다.
다음 쿼리를 실행하여 다른 앱보다 더 많은 추적을 생성하는 특정 앱을 가져옵니다.
AppTraces | where TimeGenerated > ago(7d) | where SDKVersion == 'azurefunctions: 4.34.2.22820' | summarize count() by AppRoleName | sort by count_ desc
특정 앱을 포함하도록 쿼리를 구체화하고 각 개별 메시지당 레코드 수를 생성합니다.
AppTraces | where TimeGenerated > ago(7d) | where SDKVersion == 'azurefunctions: 4.34.2.22820' | where AppRoleName contains 'inbound' | summarize count() by Message | sort by count_ desc결과는 수집 비용이 증가하는 특정 메시지를 표시할 수 있습니다.
시나리오 3: 일일 한도에 예기치 않게 도달
9월 4일에 일일 한도에 예기치 않게 도달했다고 가정합니다. 다음 쿼리를 사용하여 사용자 지정 이벤트 수를 가져오고 각 이벤트와 연결된 가장 최근의 타임스탬프를 식별합니다.
customEvents
| where timestamp between(datetime(8/25/2024) .. 15d)
| summarize count(), min(timestamp) by name
이 분석은 특정 이벤트가 9월 4일에 수집되기 시작했고 그 후 매우 빠르게 시끄럽게 되었음을 나타냅니다.
데이터 수집 비용 절감
예기치 않은 데이터 수집을 담당하는 Azure Monitor 테이블의 요소를 식별한 후 시나리오에 따라 다음 방법을 사용하여 데이터 수집 비용을 줄입니다.
방법 1: 일일 상한 구성 업데이트
과도한 원격 분석 수집을 방지하도록 일일 한도를 조정합니다.
방법 2: 테이블 계획 전환
Application Insights에 대해 지원되는 다른 테이블 계획으로 전환합니다. 데이터 수집에 대한 청구는 테이블 계획 및 Log Analytics 작업 영역의 지역에 따라 달라집니다. Azure Monitor 로그에서 기본 테이블 계획을 지원하는 테이블 계획 및 테이블을 참조하세요.
방법 3: Java 에이전트에 원격 분석 SDK 기능 사용
기본 권장 솔루션은 샘플링 재정의를 사용하는 것입니다. Application Insights Java 에이전트는 두 가지 유형의 샘플링을 제공합니다. 일반적인 활용 사례는 건강 점검을 위한 원격 분석 수집을 억제하는 것입니다.
샘플링 오버라이드에 대한 몇 가지 보조 방법이 있습니다.
traces테이블에서 비용을 줄입니다.applicationinsights.json 파일을 업데이트하여 로그 계측을 사용하지 않도록 설정합니다.
{ "instrumentation": { "logging": { "enabled": false } } }
dependencies테이블에서 비용을 줄입니다.종속성 원격 분석 데이터를 생성하는 계측을 사용하지 않도록 설정합니다.
종속성이 데이터베이스 호출인 경우 애플리케이션 맵에 데이터베이스가 표시되지 않습니다. HTTP 호출 또는 메시지(예: Kafka 메시지)의 종속성 계측을 제거하면 모든 다운스트림 원격 분석 데이터가 삭제됩니다.
customMetrics테이블의 비용을 줄입니다.OpenTelemetry 특성의 비용을 줄입니다.
OpenTelemetry 특성이 customDimensions 열에 추가됩니다. Application Insights에서 속성으로 표시됩니다. 특성 원격 분석 프로세서를 사용하여 특성을 제거할 수 있습니다. 자세한 내용은 원격 분석 프로세서 예제 - 삭제를 참조하세요.
방법 4: 애플리케이션 코드 업데이트(로그 수준 또는 예외)
일부 시나리오에서는 애플리케이션 코드를 직접 업데이트하면 Application Insights 백 엔드 서비스에서 생성하고 사용하는 원격 분석의 양을 줄이는 데 도움이 될 수 있습니다. 일반적인 예는 애플리케이션에 의해 표시되는 시끄러운 예외일 수 있습니다.
참고문헌
- Azure Monitor 가격 책정
- Log Analytics 작업 영역에 대한 가격 책정 계층 변경
- Azure Monitor의 테이블 계획
- Azure Monitor 비용 및 사용량
- Log Analytics 작업 영역에서 사용량 분석
- Azure Monitor의 비용 최적화
타사 연락처 고지
Microsoft는 이 항목에 대한 추가 정보를 찾는 데 도움이 되는 타사 연락처 정보를 제공합니다. 이 연락처 정보는 예고 없이 변경 될 수 있습니다. Microsoft는 타사 연락처 정보의 정확도를 보장하지 않습니다.
도움을 요청하십시오.
질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.