앞선 글에서는 API 요청 수를 지표로 수집했지만, 이 수치만으로는 서비스의 정상 여부를 판단하기 어렵다는 한계가 있습니다. 예를 들어 요청 수는 꾸준히 늘고 있지만, 그 중 절반이 500 에러라면 단순 요청 수만 봐서는 문제를 인지하지 못할 수 있습니다.이럴 때는 HTTP 응답 상태 코드별로 요청 수를 분류해 지표를 수집하면, 에러 비율이나 특정 상태 코드의 급증 여부를 통해 보다 정밀한 모니터링이 가능해집니다. 1. MetricInterceptor 수정하기앞선 글에서 만들었던 MetricInterceptor는 단순히 API 요청 수만 기록하도록 구현되어 있었습니다. 이제 여기에 HTTP 응답 상태 코드를 함께 수집할 수 있도록 로직을 확장해보겠습니다. [metric.interceptor.ts]impo..

모니터링은 서비스의 상태와 이상 징후를 파악하고, 문제 발생 시 빠르게 대응하기 위한 인프라 운영에 필수적인 부분입니다. 이러한 모니터링을 위해 가장 필요한 것은 지표(Metric)입니다. 예를 들어, API 요청 수, 응답 시간, 에러 비율, CPU 사용량, 메모리 사용량 등이 대표적인 지표에 해당합니다.앞선 글에서 설명한 것처럼 AWS에서는 CloudWatch를 통해 기본적인 지표들을 바로 확인할 수 있으며, EC2에 애플리케이션을 배포한 경우 CloudWatch Agent를 설치하여 추가적인 시스템 지표도 수집할 수 있습니다.하지만, API 요청 수나 응답 시간, 레이턴시와 같은 애플리케이션 레벨 지표는 CloudWatch Agent를 연동하더라도 수집할 수 없습니다. CloudWatch Agent..

모니터링은 안정적인 인프라 운영에 매우 중요한 부분입니다. 서비스에 문제가 발생하면 사용자는 서비스를 이용할 수 없게 되고, 그 영향이 연관된 다른 서비스로 번지며 더 큰 장애로 이어질 수 있습니다. 더 나아가, 발생한 문제를 수습하는 데는 많은 시간과 비용이 들기 때문에 사후 대응보다는 사전 탐지와 예방이 훨씬 중요합니다. 이를 위해 우리는 모니터링을 통해 시스템의 상태를 지속적으로 관찰하고, 문제가 발생하기 전의 이상 징후를 빠르게 파악하여 미리 대응할 수 있어야 합니다.이번 글에서는 AWS에서 EC2 인스턴스를 모니터링하기 위해 CloudWatch Agent를 설정하는 방법과, 수집된 데이터를 바탕으로 CloudWatch 대시보드를 구성하는 방법에 대해 단계별로 설명합니다. 1. CloudWatch..