컨테이너 인사이트의 데이터 변환
이 문서에서는 컨테이너 인사이트에서 데이터 변환을 구현하는 방법을 설명합니다. Azure Monitor의 변환을 사용하면 Log Analytics 작업 영역에 데이터가 수집되기 전에 데이터를 수정하거나 필터링할 수 있습니다. 이를 통해 클러스터에서 수집된 데이터를 필터링하여 비용을 절약하거나 들어오는 데이터를 처리하여 데이터 쿼리를 지원하는 등의 작업을 수행할 수 있습니다.
Important
컨테이너 인사이트에서 로그 수집 구성 및 컨테이너 인사이트에서 로그 수집 필터링 문서에서 는 데이터 수집을 구성하고 필터링하기 위한 컨테이너 인사이트의 표준 구성 설정을 설명합니다. 변환을 사용하기 전에 이러한 기능을 사용하여 필요한 구성을 수행해야 합니다. 표준 구성 설정으로 수행할 수 없는 필터링 또는 기타 데이터 구성을 수행하는 데 변환을 사용하세요.
데이터 수집 규칙
변환은 Azure Monitor에서 데이터 수집을 구성하는 데 사용되는 DCR(데이터 수집 규칙)에서 구현됩니다. DCR을 사용한 데이터 수집 구성에서는 클러스터에서 컨테이너 인사이트를 활성화할 때 자동으로 생성되는 DCR에 대해 설명합니다. 변환을 만들려면 다음 작업 중 하나를 수행해야 합니다.
- 새 클러스터. 기존 ARM 템플릿을 사용하여 AKS 클러스터를 컨테이너 인사이트에 온보딩합니다. 아래 샘플 중 하나와 유사한 변환을 비롯해 필요한 구성으로 해당 템플릿의 DCR을 수정합니다.
- 기존 DCR. 클러스터가 컨테이너 인사이트에 온보딩되고 데이터 수집이 구성된 후 데이터 수집 규칙 편집의 방법 중 하나를 사용하여 변환을 포함하도록 DCR을 편집합니다.
참고 항목
현재, 변환을 추가하는 데 필요한 최소한의 DCR 편집용 UI가 있습니다. 대부분의 경우 DCR을 수동으로 편집해야 합니다. 이 문서에서는 구현할 DCR 구조에 대해 설명합니다. 해당 구조를 구현하는 방법에 대한 지침은 Azure Monitor에서 DCR(데이터 수집 규칙) 만들기 및 편집을 참조하세요.
데이터 원본
DCR의 데이터 원본 섹션은 DCR 에서 처리할 다양한 유형의 들어오는 데이터를 정의합니다. 컨테이너 인사이트의 경우 이는 접두사 Microsoft-로 시작하는 하나 이상의 사전 정의된 streams를 포함하는 컨테이너 인사이트 확장입니다.
DCR의 컨테이너 인사이트 스트림 목록은 클러스터에 대해 선택한 비용 사전 설정에 따라 다릅니다. 모든 테이블을 수집하는 경우 DCR은 스트림 값에 나열된 모든 스트림을 포함하는 그룹 스트림인 Microsoft-ContainerInsights-Group-Default 스트림을 사용합니다. 변환을 사용하려면 이를 개별 스트림으로 변경해야 합니다. 다른 비용 사전 설정 설정은 이미 개별 스트림을 사용합니다.
아래 샘플은 Microsoft-ContainerInsights-Group-Default 스트림을 보여줍니다. 개별 스트림을 사용하는 샘플은 샘플 DCR을 참조하세요.
"dataSources": {
"extensions": [
{
"streams": [
"Microsoft-ContainerInsights-Group-Default"
],
"name": "ContainerInsightsExtension",
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"namespaces": null,
"enableContainerLogV2": true
}
}
}
]
}
데이터 흐름
DCR의 데이터 흐름 섹션은 DCR 섹션에 destinations 정의된 대상과 스트림을 일치합니다. 데이터가 기본 테이블로 전송되는 경우 알려진 스트림에 대해 테이블 이름을 지정할 필요가 없습니다. 변환이 필요하지 않은 스트림은 작업 영역 대상만 포함하는 단일 항목으로 그룹화할 수 있습니다. 각각 해당 기본 테이블로 전송됩니다.
변환이 필요한 스트림에 대해 별도의 항목을 만듭니다. 여기에는 작업 영역 대상 및 transformKql 속성이 포함되어야 합니다. 대체 테이블로 데이터를 전송하는 경우 대상 테이블의 이름을 지정하는 outputStream 속성을 포함해야 합니다.
아래 샘플은 변환이 포함된 단일 스트림에 대한 dataFlows 섹션을 보여 줍니다. 단일 DCR의 여러 데이터 흐름에 대해서는 샘플 DCR을 참조하세요.
"dataFlows": [
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where PodNamespace == 'kube-system'"
}
]
샘플 DCR
데이터 필터링
첫 번째 예에서는 LogLevel 열을 기반으로 ContainerLogV2에서 데이터를 필터링합니다. LogLevel이 error 또는 critical인 레코드만 수집되는데, 이 항목들을 클러스터의 문제를 알리고 식별하는 데 사용할 수 있기 때문입니다. info 및 debug와 같은 다른 수준을 수집하고 저장하면 큰 이점 없이 비용이 발생하게 됩니다.
다음 로그 쿼리를 사용하여 이러한 레코드를 검색할 수 있습니다.
ContainerLogV2 | where LogLevel in ('error', 'critical')
다음 다이어그램에서 이 논리를 확인할 수 있습니다.
변환에서 테이블 이름 source는 들어오는 데이터를 나타내는 데 사용됩니다. 다음은 변환에 사용할 수정된 쿼리입니다.
source | where LogLevel in ('error', 'critical')
다음 샘플에서는 컨테이너 인사이트 DCR에 추가된 이 변환을 보여 줍니다. Microsoft-ContainerLogV2는 변환을 적용해야 하는 유일한 수신 스트림이므로 별도의 데이터 흐름이 사용됩니다. 다른 스트림에는 별도의 데이터 흐름이 사용됩니다.
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
}
],
},
}
다른 테이블로 데이터 전송
위의 예에서는 LogLevel이 error 또는 critical인 레코드만 수집됩니다. 이러한 레코드를 전혀 수집하지 않는 대신 사용할 수 있는 대체 전략은 기본 로그용으로 구성된 대체 테이블에 해당 레코드를 저장하는 것입니다.
이 전략에는 두 가지 변환이 필요합니다. 첫 번째 변환은 LogLevel이 error이거나 critical인 레코드를 기본 테이블로 보냅니다. 두 번째 변환은 다른 레코드를 ContainerLogV2_CL이라는 사용자 지정 테이블로 보냅니다. 이전 예에서 설명한 대로 들어오는 데이터에 대해 source를 사용하여 각각에 대한 쿼리가 아래에 표시됩니다.
# Return error and critical logs
source | where LogLevel in ('error', 'critical')
# Return logs that aren't error or critical
source | where LogLevel !in ('error', 'critical')
다음 다이어그램에서 이 논리를 확인할 수 있습니다.
Important
이 샘플에서 DCR을 설치하기 전에 ContainerLogV2와 동일한 스키마를 사용하여 새 테이블을 생성해야 합니다. 이름을 ContainerLogV2_CL로 지정하고 기본 로그용으로 구성합니다.
다음 샘플에서는 컨테이너 인사이트 DCR에 추가된 이 변환을 보여 줍니다. 이 DCR에는 Microsoft-ContainerLogV2에 대한 데이터 흐름이 각 변환마다 하나씩, 총 두 개가 있습니다. 첫 번째 흐름은 테이블 이름을 지정할 필요가 없는 기본 테이블로 보냅니다. 두 번째 흐름에는 대상 테이블을 지정하기 위해 outputStream 속성이 필요합니다.
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel !in ('error','critical')",
"outputStream": "Custom-ContainerLogV2_CL"
}
],
},
}