Azure Monitor

팀이 Azure에 서비스를 배포하고 나면 '지금 제대로 돌아가고 있나'를 확인하는 수단이 당장 필요합니다. 처음에는 각 리소스 콘솔에 들어가 CPU 그래프를 눈으로 확인하거나, 에러가 접수된 뒤에야 로그를 뒤집어 보게 됩니다. 리소스가 서너 개일 때는 버틸 수 있지만, App Service, AKS, SQL Database, Service Bus가 함께 동작하는 순간 각 콘솔을 순서대로 열어보는 것만으로도 수십 분이 걸립니다. 그리고 사용자가 '안 된다'고 먼저 알려온 뒤에야 장애를 인지하는 상황이 반복됩니다. 시스템이 스스로 이상 신호를 감지해서 알려주지 않으면, 팀은 항상 한발 늦은 대응을 할 수밖에 없습니다.

온프레미스 시절의 서버 모니터링은 물리 서버 수십 대를 대상으로 CPU, 디스크, 네트워크 상태를 에이전트로 수집하는 방식이었습니다. 임계값을 넘으면 이메일이 오고, 운영팀이 확인하는 구조였습니다. 이 방식은 서버 수가 적고 생명주기가 긴 인프라에서는 충분했습니다. 클라우드로 전환되면서 상황이 달라졌습니다. 리소스는 수백 개 단위로 늘어났고, 서버리스 함수나 컨테이너처럼 수초 만에 생성되었다 사라지는 인스턴스가 등장했습니다. 인프라 메트릭만 봐서는 '왜 사용자 요청이 느린지'를 알 수 없었고, 요청 하나가 여러 서비스를 거치는 분산 환경에서는 어느 구간에서 지연이 발생했는지를 추적하려면 애플리케이션 수준의 트레이싱까지 필요해졌습니다. 클라우드 제공사들은 이 요구에 맞춰 메트릭, 로그, 트레이스를 한 플랫폼에서 수집하고 경고와 자동 대응까지 연결하는 통합 관찰 서비스를 기본 제공하기 시작했고, Azure Monitor가 그 역할을 맡았습니다.

Monitor는 Azure 리소스가 내보내는 데이터를 두 갈래로 수집합니다. 메트릭은 CPU 사용률, 초당 요청 수, 큐 깊이 같은 수치형 시계열 데이터로, 리소스를 만드는 순간부터 자동으로 수집됩니다. 로그는 텍스트 기반 이벤트로, 진단 설정을 켜면 Log Analytics 워크스페이스로 흘러 들어가고 KQL(Kusto Query Language)로 검색할 수 있습니다. 수집된 데이터 위에 경고 규칙을 걸면 Monitor가 조건을 주기적으로 평가합니다. 'CPU가 5분 동안 90%를 넘으면', '에러 로그가 분당 100건을 초과하면' 같은 조건이 충족되는 순간 Action Group이 작동합니다. Action Group은 이메일, SMS, 웹훅, Functions 호출 같은 동작을 묶어 두는 단위로, 경고 하나에 여러 Action Group을 연결할 수 있습니다. Application Insights는 이 위에서 애플리케이션 코드 수준까지 내려갑니다. SDK나 자동 계측을 통해 요청 하나가 어떤 서비스를 거쳤는지, 어느 구간에서 얼마나 걸렸는지, 어떤 예외가 발생했는지를 분산 트레이스로 기록합니다.

Azure Monitor와 Application Insights는 별개 서비스처럼 보이지만 같은 플랫폼의 다른 계층입니다. 둘 다 관찰과 경고를 다루지만, Monitor는 인프라와 플랫폼 수준의 메트릭·로그를 담당하고, Application Insights는 애플리케이션 코드 안에서 일어나는 요청 흐름, 종속성 호출, 예외를 추적합니다. 'VM 전체가 느린가'는 Monitor 메트릭으로 판단하고, '이 API 요청이 왜 2초가 걸렸나'는 Application Insights 트레이스로 분석합니다. 멀티클라우드나 온프레미스 인프라까지 하나의 관찰 화면으로 통합해야 하는 상황에서는 Azure Monitor만으로 부족할 수 있습니다. Monitor는 Azure 리소스와의 통합 깊이가 가장 높고 별도 설정 없이 기본 메트릭이 수집된다는 장점이 있지만, Azure 바깥 인프라를 동일 수준으로 다루기는 어렵습니다. 조직의 관찰 범위가 Azure에 집중되어 있다면 Monitor가 가장 자연스러운 선택이고, 여러 클라우드를 균일하게 봐야 한다면 관찰 전략을 별도로 설계해야 합니다.

운영팀이 처음 Azure 환경에서 '장애 감지를 체계화하자'는 논의를 시작할 때 Monitor가 등장합니다. 리소스를 배포한 뒤 CPU나 응답 시간에 경고 규칙 하나를 다는 것이 첫 단계이고, 점차 Log Analytics 쿼리로 에러 패턴을 탐색하거나 Application Insights로 요청 트레이스를 분석하는 방향으로 확장됩니다. 다음 신호가 보이면 Monitor 활용을 더 깊이 검토할 시점입니다. 장애 보고를 사용자에게서 먼저 받고 있을 때, 에러 급증이나 응답 지연이 어느 리소스에서 시작됐는지 추적하는 데 30분 이상 걸릴 때, 야간 배포 이후 이상 여부를 수동으로 확인해야 할 때가 그 신호입니다. 한 가지 고려할 점은 로그 보존 비용입니다. Log Analytics에 쌓이는 로그는 수집량과 보존 기간에 비례해 과금되므로, 진단 설정을 켤 때 어떤 로그를 얼마나 보관할지를 미리 정해두지 않으면 비용이 예상보다 빠르게 늘어날 수 있습니다.