AZ-400 시험에서 모니터링 파트는 '서비스가 살아있는지'가 아니라 '왜 그렇게 작동하는지'를 어떻게 파악하느냐를 묻습니다. 단순한 알림 설정이 아니라, 메트릭·로그·트레이스라는 세 축으로 시스템을 들여다보는 옵저버빌리티 설계가 핵심입니다. Azure Monitor, Application Insights, Log Analytics의 역할 분담과 KQL, SLO·DORA 메트릭까지 이 글에서 정리합니다.
모니터링과 옵저버빌리티의 차이
병원 응급실에서 혈압·맥박 수치가 정상 범위를 벗어나면 알람이 울립니다. 이것이 모니터링입니다. 반면 의사가 "이 환자가 왜 이 상태에 이르렀는가"를 파악하려면 72시간 투약 기록과 혈액검사 추이를 교차 분석해야 합니다. 이것이 옵저버빌리티입니다.
소프트웨어도 같습니다. 모니터링은 알려진 실패 모드를 감지하고, 옵저버빌리티는 알려지지 않은 문제를 시스템 내부 상태에서 추론할 수 있게 합니다. 그 기반은 세 신호입니다.
: 시간 흐름에 따른 숫자 요약. CPU, 요청 수, 응답 시간. 현재 상태 파악에 최적. : 특정 시점에 무슨 일이 일어났는지의 기록. 비정형이지만 맥락이 풍부. : 하나의 요청이 여러 서비스를 거치는 여정. "이 요청이 왜 3초 걸렸나"를 추적.
Azure에서 이 세 신호를 통합 관리하는 플랫폼이 Azure Monitor입니다.
!모니터링 vs 옵저버빌리티
Azure Monitor 구조
자동차 계기판에는 속도계, 연료 게이지, 경고등이 한 화면에 모여 있습니다. 운전자가 각 부품 제조사 앱을 따로 열지 않아도 되는 것처럼, Azure Monitor는 Azure 리소스 전체의 신호를 한 곳에서 관리합니다.
Azure Monitor Metrics는 시계열 데이터를 93일간 보관합니다. VM CPU, Storage Account 트랜잭션, App Service HTTP 요청 같은 플랫폼 메트릭은 자동 수집됩니다. Metrics Explorer에서 시각화하거나 Alert 규칙의 신호 소스로 바로 연결할 수 있습니다.
Azure Monitor Logs는 Log Analytics 워크스페이스에 데이터를 저장합니다. Diagnostic Settings으로 리소스 로그를 워크스페이스로 보내면 KQL(Kusto Query Language)로 분석합니다.
Azure Workbooks는 KQL 쿼리, 메트릭 차트, 텍스트 설명을 한 페이지에 혼합하는 인터랙티브 리포트 도구입니다. SLA 보고서나 사후 분석(Post-Mortem) 문서로 활용됩니다.
Application Insights — 분산 추적
공항 수하물 추적 시스템을 상상해보세요. 가방 하나에 바코드가 붙고, 체크인부터 화물칸까지 모든 이동 경로가 기록됩니다. 가방이 분실되면 마지막 스캔 위치를 바로 찾습니다. Application Insights 분산 추적이 이와 같습니다.
마이크로서비스에서 하나의 HTTP 요청은 API Gateway → Order Service → Inventory Service → Database를 거칩니다. Application Insights는 각 홉에 동일한 를 부여해 전체 여정을 하나의 트레이스로 연결합니다. Application Map에서는 서비스 간 의존성과 각 구간의 실패율·응답 시간을 시각적으로 확인할 수 있습니다.
트래픽이 많은 서비스에서 모든 요청을 로깅하면 비용이 폭증합니다. Adaptive Sampling은 초당 약 5개로 수집량을 자동 조절합니다. 장애 직후 실시간 진단이 필요할 때는 Live Metrics Stream으로 지연 없이 현재 상태를 관찰합니다.
별도 알림 없이도 Smart Detection은 응답 시간 이상 증가·실패율 급등·의존성 저하를 자동 감지해 알립니다. 기준선(Baseline)을 학습하므로 임계값 설정이 필요 없습니다.
알림 규칙과 Action Groups
소방서 자동 신고 시스템을 생각해보세요. 화재 감지기가 연기를 감지하면 소방서에 자동으로 신호가 전달되고 소방차가 출동합니다. Azure Monitor Alert 규칙과 Action Groups가 이 구조입니다.
Alert 규칙은 세 요소로 구성됩니다. 는 Metrics 값, Log Analytics 쿼리 결과, Activity Log 이벤트 중 선택합니다. 은 임계값 초과, 쿼리 결과 행 수, 상태 변경 등입니다. 은 이메일·SMS, Azure Function 호출, Logic App 트리거, ITSM 연동 중 선택합니다.
트래픽은 낮에 높고 새벽에 낮습니다. Dynamic Thresholds는 과거 패턴을 학습해 시간대별 정상 범위를 자동 조정함으로써 불필요한 알림과 놓치는 이상을 동시에 줄입니다.
SLO, SLI, Error Budget, DORA 메트릭
팀이 "99.9% 가용성을 보장한다"고 선언했다면, 그 약속을 지키고 있는지 어떻게 측정합니까? 영업팀이 매주 실적을 집계하듯, 엔지니어링 팀도 서비스 신뢰도를 정량적으로 추적해야 합니다.
SLI(Service Level Indicator)는 측정값입니다. "지난 30일 성공 응답 비율"이 SLI이고, SLO(Service Level Objective)는 그 목표인 "99.9% 이상"입니다. Log Analytics KQL로 직접 계산할 수 있습니다. SLO 99.9%는 한 달에 약 43분의 다운타임만 허용하는데, 이 허용 범위가 Error Budget입니다. 소진되면 새 기능 배포를 중단하고 신뢰도 개선에 집중하는 것이 SRE 원칙입니다.
DORA(DevOps Research and Assessment) 메트릭은 배포 프로세스 건강도를 측정합니다. Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR(Mean Time to Restore) 네 지표를 Log Analytics와 Azure DevOps 데이터를 연결해 추적합니다.
시험 핵심 정리
AZ-400 모니터링 섹션은 각 도구가 어떤 문제를 해결하는지를 묻습니다.
"여러 서비스 간 요청 흐름 추적" -- Application Insights 분산 추적 + Application Map "플랫폼 메트릭 시계열 저장·시각화" -- Azure Monitor Metrics + Metrics Explorer "로그 쿼리로 오류 패턴 분석" -- Log Analytics + KQL "설정 없이 이상 패턴 자동 감지" -- Application Insights Smart Detection "알림 발생 시 Function 자동 호출" -- Action Groups (Azure Function 연결) "야간/주간 트래픽 차이를 반영한 알림" -- Dynamic Thresholds "SLI 계산 + Error Budget 추적" -- Log Analytics KQL 쿼리 "DORA 메트릭 중 복구 시간" -- MTTR (Azure DevOps + Log Analytics 연동) "여러 서비스 의존성 지연 시각화" -- Application Insights Application Map "팀 공유용 인터랙티브 모니터링 리포트" -- Azure Monitor Workbooks
Azure Monitor = 플랫폼 전체 메트릭·로그 허브, Application Insights = 분산 추적·Smart Detection, Log Analytics + KQL = 모든 데이터를 엮는 쿼리 엔진.