Azure Monitor 와 Log Analytics (메트릭, 로그, KQL, 경고)
Azure Monitor 의 데이터 종류(메트릭, 로그, 활동 로그), 진단 설정과 데이터 수집 규칙, Azure Monitor Agent, Log Analytics 작업 영역 설계와 테이블 플랜(Analytics, Basic, Auxiliary), 보존 기간, 자주 쓰는 KQL, 경고와 작업 그룹, Application Insights, 로그 비용 줄이는 법을 정리합니다.
데이터의 종류
| 데이터 | 어디서 | 기본 보관 | 비고 |
|---|---|---|---|
| 플랫폼 메트릭 | 모든 리소스가 자동으로 | 93일 | 무료, 1분 단위. 빠른 경고에 적합 |
| 활동 로그 | 구독의 제어 평면 작업 (누가 무엇을 만들고 지웠나) | 90일 | 무료. 길게 보관하려면 작업 영역으로 |
| 리소스 로그 | 각 서비스 내부 로그 (예: Key Vault 접근, SQL 감사) | 수집 안 됨 | 진단 설정을 만들어야 쌓임 |
| 게스트 OS 로그, 성능 | VM 안 | 수집 안 됨 | Azure Monitor Agent + 데이터 수집 규칙 |
| 앱 텔레메트리 | 코드 (OpenTelemetry) | 작업 영역 설정 따라 | Application Insights |
가장 흔한 실수는 리소스 로그가 자동으로 쌓인다고 생각하는 것입니다. 진단 설정이 없으면 장애가 난 뒤에 볼 로그가 없습니다. Azure Policy 의 "진단 설정 배포" 이니셔티브로 모든 리소스에 강제하는 것이 좋습니다.
az monitor diagnostic-settings create -n to-law \
--resource $(az keyvault show -n kv-shop-prod --query id -o tsv) \
--workspace $(az monitor log-analytics workspace show -g rg-mgmt -n law-prod-krc --query id -o tsv) \
--logs '[{"categoryGroup":"audit","enabled":true}]' --export-to-resource-specific true
에이전트와 데이터 수집 규칙
VM 과 Arc 서버의 로그는 Azure Monitor Agent(AMA) 와 데이터 수집 규칙(DCR) 으로 모읍니다. 예전 Log Analytics 에이전트(MMA, OMS)는 2024-08-31 에 퇴역했으므로 남아 있다면 AMA 로 옮깁니다. DCR 은 "어떤 VM 에서, 어떤 로그와 카운터를, 어떤 변환(KQL)을 거쳐, 어느 테이블로" 를 정의하고, 여러 VM 에 연결해 씁니다. 수집 시점 변환으로 필요 없는 열과 행을 버리면 비용이 크게 줄어듭니다.
Log Analytics 작업 영역 설계
작업 영역은 적을수록 관리와 질의가 쉽습니다. 보통 리전별, 환경별로 하나 정도로 시작하고, 데이터 주권, 접근 분리, Sentinel 운영 요구가 있을 때만 나눕니다. 접근 제어는 작업 영역 권한 대신 리소스 컨텍스트 권한을 쓰면, 사용자가 자기 리소스의 로그만 보게 할 수 있습니다.
테이블 플랜과 보존
| 플랜 | 용도 | 수집 비용 | 질의 | 경고 | 분석 보존 |
|---|---|---|---|---|---|
| Analytics | 상시 모니터링, 실시간 탐지 | 표준 | 요금 포함, 빠름 | 모든 경고 | 30일 (Sentinel, App Insights 는 90일), 최대 2년 |
| Basic | 문제 해결, 사고 대응 | 낮음 | 질의당 과금 | 단순 로그 경고만 | 해당 없음 |
| Auxiliary / Lake | 대량 상세 로그, 감사, 규정 | 아주 낮음 | 질의당 과금, 느림 | 불가 | 해당 없음 |
모든 플랜은 총 보존 최대 12년이고, 분석 보존이 끝난 데이터는 장기 보존으로 남아 검색 작업(search job)이나 복원으로 다시 꺼냅니다. 방화벽 상세 로그, 흐름 로그처럼 많지만 가끔 보는 데이터는 Basic 이나 Auxiliary 로 보내 비용을 낮춥니다.
자주 쓰는 KQL
// 최근 1시간 동안 실패한 ARM 작업 (누가, 무엇을)
AzureActivity
| where TimeGenerated > ago(1h) and ActivityStatusValue == "Failure"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Properties_d.statusMessage
| order by TimeGenerated desc
// VM 별 CPU 평균 상위 10개 (AMA 의 성능 카운터)
Perf
| where TimeGenerated > ago(30m) and ObjectName == "Processor" and CounterName == "% Processor Time"
| summarize avgCpu = avg(CounterValue) by Computer
| top 10 by avgCpu
// 어떤 테이블이 돈을 쓰나: 지난 7일 테이블별 수집량(GB)
Usage
| where TimeGenerated > ago(7d) and IsBillable
| summarize GB = sum(Quantity) / 1000 by DataType
| order by GB desc마지막 질의는 로그 비용이 갑자기 늘었을 때 가장 먼저 돌립니다. 보통 디버그 수준 앱 로그나 방화벽 로그 한두 개가 대부분을 차지합니다.
경고
| 경고 종류 | 기준 | 맞는 경우 |
|---|---|---|
| 메트릭 경고 | 메트릭 임계값, 동적 임계값 | 빠른 감지(분 단위), CPU, 응답 시간, 429 수 |
| 로그 검색 경고 | KQL 결과 | 여러 신호 조합, 특정 에러 문자열 |
| 활동 로그 경고 | 제어 평면 이벤트 | 리소스 삭제, 역할 할당 변경 |
| 서비스 상태 경고 | Azure 장애, 계획된 유지 관리 | 내 리전, 내 서비스 영향 알림 |
경고는 작업 그룹(메일, SMS, 웹훅, Logic Apps, ITSM)으로 알립니다. Azure 의 권장 기본 경고(recommended alerts)를 켜면 VM, AKS 같은 리소스에 기본 규칙이 만들어집니다. 경고가 너무 많으면 아무도 보지 않으므로, 사용자 영향(가용성, 지연)부터 겁니다.
Application Insights
Application Insights 는 앱의 요청, 의존성 호출, 예외, 트레이스를 모읍니다. 클래식(독립형) 리소스는 퇴역했고 지금은 작업 영역 기반만 있습니다. 새 계측은 Azure Monitor OpenTelemetry Distro 를 씁니다.
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor(connection_string="InstrumentationKey=...;IngestionEndpoint=...")샘플링을 켜서 요청이 많을 때 비용을 조절하고, 분산 추적의 연결이 끊기지 않게 서비스 사이에 traceparent 헤더가 전달되는지 확인합니다.
비용 줄이기
Usage테이블로 큰 테이블을 찾고, DCR 변환이나 진단 설정 범주 줄이기로 수집량 자체를 줄입니다.- 자주 안 보는 테이블은 Basic, Auxiliary 플랜으로 바꿉니다.
- 하루 수집량이 일정 수준 이상이면 약정 계층(commitment tier) 이 종량제보다 쌉니다.
- 일일 상한(daily cap)은 비용 사고를 막지만, 넘으면 그날 로그가 끊기므로 운영 작업 영역에서는 경고와 함께 신중히 씁니다.