컨테이너 인사이트 로그 스키마
Container Insights는 수집한 로그 데이터를 Log Analytics 작업 영역의 ContainerLogV2라는 테이블에 저장합니다. 이 문서에서는 이 테이블의 스키마와 관련 구성 옵션에 대해 설명합니다. 또한 이 테이블을 레거시 ContainerLog 테이블과 비교하고 마이그레이션에 대한 세부 정보를 제공합니다.
테이블 비교
ContainerLogV2는 CLI 버전 2.54.0 이상용 기본 스키마입니다. 관리 ID 인증을 사용하여 Container Insights를 온보딩하는 고객을 위한 기본 테이블입니다. ContainerLogV2는 데이터 수집 설정을 사용하여 CLI 버전 2.51.0 이상을 통해 명시적으로 사용하도록 설정할 수 있습니다.
Important
ContainerLog 테이블에 대한 지원은 2026년 9월 30일에 사용 중지됩니다.
다음 표에서는 ContainerLogV2와 ContainerLog 스키마 사용 간의 주요 차이점을 강조 표시합니다.
| 기능 차이점 | ContainerLog | ContainerLogV2 |
|---|---|---|
| 스키마 | ContainerLog의 세부 정보. | ContainerLogV2의 세부 정보. 추가 열은 다음과 같습니다. - ContainerName- PodName- PodNamespace- LogLevel1- KubernetesMetadata2 |
| 온보딩 | ConfigMap을 통해서만 구성할 수 있습니다. | ConfigMap 및 DCR을 통해 구성할 수 있습니다. 3 |
| 가격 책정 | 정가 분석 로그와만 호환됩니다. | 분석 로그 외에도 저렴한 기본 로그 계층을 지원합니다. |
| 쿼리 | 표준 쿼리를 위해 인벤토리 테이블을 사용하는 여러 조인 작업이 필요합니다. | 쿼리 복잡성을 줄이고 작업에 조인하는 추가 Pod 및 컨테이너 메타데이터를 포함합니다. |
| 여러 줄 | 지원되지 않는 여러 줄 항목은 여러 행으로 분할됩니다. | 여러 줄 출력에 대한 통합된 단일 항목을 허용하도록 여러 줄 로깅을 지원합니다. |
1 LogMessage가 유효한 JSON이고 level이라는 키가 있는 경우 해당 값이 사용됩니다. 그렇지 않으면 regex 기반 키워드 일치를 사용하여 LogMessage에서 LogLevel을 유추합니다. 이러한 유추로 인해 분류가 잘못될 수 있습니다. LogLevel은 CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE은 또는 UNKNOWN 등의 상태 값이 있는 문자열 필드입니다.
2 KubernetesMetadata는 Kubernetes 메타데이터가 사용하도록 설정된 선택적 열입니다. 이 필드의 값은 필드 podLabels, podAnnotations, podUid, Image, ImageTag 및 Image repo가 있는 JSON입니다.
3 DCR 구성에는 관리 ID 인증이 필요합니다.
참고 항목
들어오는 LogMessage가 유효한 JSON이 아닌 경우 Event Hub 및 Storage 계정으로 내보내기는 지원되지 않습니다. 최상의 성능을 위해 JSON 형식으로 컨테이너 로그를 내보냅니다.
ContainerLogV2 스키마 사용
클러스터의 DCR(데이터 수집 규칙) 또는 ConfigMap을 사용하여 클러스터에 대한 ContainerLogV2 스키마를 사용하도록 설정합니다. 두 설정이 모두 사용하도록 설정되면 ConfigMap이 우선적으로 적용됩니다. ContainerLog 테이블은 DCR과 ConfigMap이 모두 명시적으로 해제된 경우에만 사용됩니다.
ContainerLogsV2 스키마를 사용하도록 설정하기 전에 ContainerLog 테이블을 사용하는 경고 규칙이 있는지 평가해야 합니다. 새 테이블을 사용하려면 이러한 경고를 업데이트해야 합니다. ContainerLog 테이블을 참조하는 경고 규칙을 검사하려면 다음 Azure Resource Graph 쿼리를 실행합니다.
resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc
Kubernetes 메타데이터 및 로그 필터링
Kubernetes 메타데이터 및 로그 필터링은 추가 Kubernetes 메타데이터를 사용하여 ContainerLogsV2 스키마를 확장합니다. 로그 필터링 기능은 워크로드와 플랫폼 컨테이너 모두에 대한 필터링 기능을 제공합니다. 이러한 기능을 통해 사용자는 워크로드에 대한 더 풍부한 컨텍스트와 개선된 가시성을 얻을 수 있습니다.
참고 항목
Grafana 대시보드를 필터링하는 Kubernetes 메타데이터 및 로그는 현재 기본 로그를 지원하지 않습니다.
기능
향상된 ContainerLogV2 스키마 Kubernetes Logs 메타데이터를 사용하도록 설정하면
KubernetesMetadata라는ContainerLogV2에 열이 추가되어 간단한 로그 쿼리로 문제 해결이 개선되고 다른 테이블과 조인할 필요가 없어집니다. 이 열의 필드에는PodLabels,PodAnnotations,PodUid,Image,ImageID,ImageRepo,ImageTag등이 있습니다. 이러한 필드는 다른 테이블과 조인할 필요 없이 로그 쿼리를 사용하여 문제 해결 환경을 개선합니다. Kubernetes 메타데이터 기능을 사용하도록 설정하는 방법은 아래를 참조하세요.로그 수준 이 기능은 가능한 값 위험, 오류, 경고, 정보, 디버그, 추적 또는 알 수 없음을 포함하는
LogLevel열을 ContainerLogV2에 추가합니다. 이러한 기능은 심각도 수준에 따라 애플리케이션 상태를 평가하는 데 도움이 됩니다. Grafana 대시보드를 추가하면 시간에 따른 로그 수준 추세를 시각화하고 영향을 받는 리소스를 신속하게 파악할 수 있습니다.시각화를 위한 Grafana 대시보드 Grafana 대시보드는 로그 수준을 색으로 구분해서 표시하고 로그 볼륨, 로그 속도, 로그 레코드, 로그에 대한 인사이트를 제공합니다. 시간이 촉박한 분석, 시간 경과에 따른 로그 수준 추세에 대한 동적 인사이트 및 중요한 실시간 모니터링을 가져올 수 있습니다. 또한 대시보드에는 심층 분석과 정확한 문제 해결을 지원하는 컴퓨터, Pod, 컨테이너별 세부 분석도 제공됩니다. Grafana 대시보드 설치에 대한 자세한 내용은 아래를 참조하세요.
워크로드에 대한 주석 기반 로그 필터링: Pod 주석을 통한 효율적인 로그 필터링 기술입니다. 이를 통해 노이즈를 걸러내지 않고도 관련 정보에 집중할 수 있습니다. 주석 기반 필터링을 사용하면 Pod에 주석을 달아 특정 Pod 및 컨테이너에 대한 로그 컬렉션을 제외할 수 있으므로 로그 분석 비용을 크게 줄이는 데 도움이 됩니다. 주석 기반 필터링 구성에 대한 자세한 내용은 주석 기반 로그 필터링을 참조하세요.
플랫폼 로그(시스템 Kubernetes 네임스페이스)에 대한 ConfigMap 기반 로그 필터링: 플랫폼 로그는 시스템(또는 이와 유사하게 제한된) 네임스페이스의 컨테이너에서 생성됩니다. 기본적으로 Log Analytics 작업 영역의 데이터 비용을 최소화하기 위해 시스템 네임스페이스의 모든 컨테이너 로그가 제외됩니다. 그러나 특정 문제 해결 시나리오에서는 시스템 컨테이너의 컨테이너 로그가 중요한 역할을 합니다. 한 가지 예제는
kube-system네임스페이스의coredns컨테이너입니다.
Kubernetes 메타데이터 사용
Important
Kubernetes 메타데이터를 수집하려면 관리 ID 인증 및 ContainerLogsV2가 필요합니다.
다음 설정으로 ConfigMap을 사용하여 Kubernetes 메타데이터를 사용하도록 설정합니다. 모든 메타데이터 필드는 metadata_collection이 사용하도록 설정된 경우 기본적으로 수집됩니다. include_fields의 주석 처리를 취소하여 수집할 개별 필드를 지정합니다.
[log_collection_settings.metadata_collection]
enabled = true
include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]
몇 분 후 KubernetesMetadata 열은 아래와 같이 ContainerLogV2 테이블에 대한 로그 쿼리에 포함됩니다.
Grafana 대시보드 설치
Important
Kubernetes 클러스터에 대한 모니터링 사용의 지침을 사용하여 Grafana를 사용하도록 설정한 경우 Grafana 인스턴스는 이미 Prometheus 메트릭을 위해 Azure Monitor 작업 영역에 액세스할 수 있어야 합니다. Kubernetes 로그 메타데이터 대시보드에는 로그 데이터가 포함된 Log Analytics 작업 영역에 대한 액세스 권한도 필요합니다. Grafana 인스턴스에 Log Analytics 작업 영역에 대한 모니터링 읽기 권한자 역할을 부여하는 방법에 대한 지침은 Azure Monitor에 대한 액세스 권한을 수정하는 방법을 참조하세요.
ContainerLogV2 대시보드의 Grafana 갤러리에서 대시보드를 가져옵니다. 그런 다음, 대시보드를 열고 데이터 원본, 구독, 리소스 그룹, 클러스터, 네임스페이스 및 레이블에 대한 값을 선택할 수 있습니다.
참고 항목
Grafana 대시보드를 처음 로드할 때 아직 선택되지 않은 변수로 인해 오류가 표시될 수 있습니다. 이런 일이 되풀이되지 않도록 하려면 변수 집합을 선택한 후 대시보드를 처음 열 때 기본값이 되도록 저장합니다.
여러 줄 로깅
여러 줄 로깅을 사용하도록 설정하면 이전에 분할된 컨테이너 로그가 함께 연결되어 단일 항목으로 ContainerLogV2 테이블에 전송됩니다. 연결된 로그 줄이 64KB보다 크면 Log Analytics 작업 영역 제한으로 인해 잘립니다. 이 기능은 ContainerLogV2 테이블에 단일 항목으로 표시되는 .NET, Go, Python 및 Java 스택 추적도 지원합니다. ConfigMap을 사용하여 컨테이너 인사이트에서 데이터 수집 구성에 설명된 대로 ConfigMap을 사용하여 여러 줄 로깅을 사용하도록 설정합니다.
참고 항목
이제 configmap에는 언어 사양 옵션이 포함되어 고객이 관심 있는 언어만 선택할 수 있습니다. 이 기능은 configmap의 stacktrace_languages 옵션에서 언어를 편집하여 사용하도록 설정할 수 있습니다.
다음 스크린샷은 Go 예외 스택 추적에 대한 여러 줄 로깅을 보여 줍니다.
여러 줄 로깅 사용 안 함
여러 줄 로깅 사용
Java 스택 추적
Python 스택 추적
