Cloud Visualizer
← 전체 목록
📊

Azure Monitor

관리Azure 리소스의 통합 모니터링 플랫폼

아키텍처 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

클라우드에 서비스를 올리고 나면 '지금 잘 돌아가고 있는가'를 어떻게 아는지가 문제가 됩니다. VM의 CPU가 치솟고 있는지, API 응답 시간이 느려지고 있는지, 특정 시간대에 에러가 급증했는지를 각 서비스의 콘솔에 들어가서 하나하나 확인하는 것은 서비스가 몇 개만 넘어가도 불가능합니다. 더 나쁜 것은 문제가 터진 뒤에야 알게 되는 상황입니다. 사용자가 먼저 '안 된다'고 알려주기 전에, 시스템 쪽에서 이상을 감지하고 대응하려면 흩어진 신호를 한곳에 모아서 볼 수 있어야 합니다.

왜 이런 방식이 등장했나요?

클라우드 이전 시대에도 서버 모니터링은 존재했습니다. Nagios, Zabbix 같은 도구로 서버의 CPU, 디스크, 네트워크를 감시했고, 임계값을 넘으면 이메일이 왔습니다. 그런데 클라우드로 넘어오면서 모니터링의 복잡도가 완전히 달라졌습니다. 서버가 수십 대에서 수백 대로 늘었고, 서버리스 함수와 컨테이너처럼 생명주기가 짧은 리소스가 등장했습니다. 인프라 메트릭만 봐서는 '왜 사용자 요청이 느린지'를 알 수 없었고, 애플리케이션 수준의 추적까지 필요해졌습니다. 이런 변화 속에서 메트릭, 로그, 트레이스를 한 플랫폼에서 수집하고, 수집된 데이터를 쿼리하고 경고를 걸고 자동 대응까지 연결하는 통합 관찰 플랫폼이라는 개념이 자리 잡았습니다. Monitor는 Azure 리소스에 대해 이 역할을 기본 제공하는 서비스로, 별도 에이전트 설치나 설정 없이도 기본 메트릭이 수집되기 시작합니다.

안에서 어떻게 동작하나요?

Monitor는 Azure 리소스가 내보내는 메트릭과 로그 두 종류의 데이터를 수집합니다. 메트릭은 CPU 사용률, 요청 수, 큐 깊이 같은 수치 데이터로, 짧은 간격으로 자동 수집되어 시계열 그래프로 바로 볼 수 있습니다. 로그는 텍스트 기반 이벤트 데이터로, Log Analytics 워크스페이스에 저장되며 KQL(Kusto Query Language)이라는 쿼리 언어로 검색합니다. 수집된 데이터 위에 경고 규칙을 걸 수 있습니다. 'CPU가 5분 동안 90%를 넘으면', '에러 로그가 분당 100건을 넘으면' 같은 조건을 설정하고, 조건이 충족되면 Action Group이 동작합니다. Action Group은 이메일, SMS, 웹훅, Azure Functions 호출 등을 실행해 사람에게 알리거나 자동 대응을 시작합니다. Application Insights는 이 위에서 애플리케이션 코드 수준의 요청 트레이싱, 종속성 호출 추적, 실패 진단까지 담당합니다.

무엇과 헷갈리나요?

Azure Monitor와 Application Insights는 별개 서비스가 아니라 같은 플랫폼의 다른 계층입니다. Monitor는 인프라 메트릭과 플랫폼 로그를 수집하는 기반이고, Application Insights는 그 위에서 애플리케이션 코드의 요청 흐름, 종속성 호출, 예외를 추적합니다. 'VM이 느린가'는 Monitor의 메트릭으로 보고, '왜 이 API 요청이 느린가'는 Application Insights의 트레이스로 봅니다. 한편 Grafana나 Datadog 같은 서드파티 모니터링 도구와 비교하면, Monitor는 Azure 리소스와의 통합이 가장 깊고 별도 설정 없이 기본 메트릭이 수집된다는 장점이 있습니다. 반면 멀티클라우드 환경이나 온프레미스를 함께 모니터링해야 하는 상황에서는 Azure 중심의 통합만으로 부족할 수 있습니다.

언제 쓰나요?

Azure에 어떤 리소스를 배포하든 Monitor는 가장 먼저 확인하게 되는 서비스입니다. 가상 서버를 띄우면 CPU와 메모리 그래프가 바로 보이고, 웹 애플리케이션을 배포하면 요청 수와 응답 시간이 자동으로 집계됩니다. 여기에 경고 규칙을 추가하면 문제를 사용자보다 먼저 감지할 수 있고, Action Group으로 Slack 웹훅이나 자동 스케일링을 연결하면 새벽에 일어나지 않아도 초기 대응이 이뤄집니다. 반면 Monitor가 수집하는 데이터의 보존 기간과 비용은 설계 단계에서 고려해야 합니다. 로그를 무제한 보관하면 비용이 빠르게 늘어나고, 너무 짧게 잡으면 장애 원인 분석에 필요한 데이터가 사라집니다. 또한 Monitor는 Azure 리소스에 대한 관찰에 최적화되어 있으므로, Azure 밖의 인프라까지 통합 관찰해야 하는 상황에서는 한계가 있을 수 있습니다.

인프라 모니터링애플리케이션 성능 관리로그 분석자동 경고
Official Docs

더 깊게 보기

현재 페이지의 개념 설명을 본 뒤 공식 문서로 바로 이동합니다.

AZURE