1. 작업 배경
서비스를 운영하다 보면 CPU나 메모리 사용률은 정상인데 실제로는 API 오류가 발생하거나 응답이 느려지는 경우가 있다.
기존에는 Prometheus와 Grafana를 통해 서버 상태를 모니터링하고, 장애가 발생하면 OpenSearch에서 로그를 직접 검색해 원인을 확인했다.
그런데 장애가 발생할 때마다 로그를 조회하고, 어떤 API에서 오류가 발생했는지 확인하고, 파드 상태까지 하나씩 살펴보는 과정이 생각보다 번거로웠다.
그래서 장애를 자동으로 감지하고, 관련 로그와 메트릭을 AI가 분석해 원인까지 알려주는 기능을 만들어봤다.
2. 장애 감지 및 텔레그램 알림
먼저 장애를 빠르게 인지하기 위해 모니터링 항목을 추가했다.
Gateway 모니터링
NGINX Gateway 로그를 기반으로 5xx 오류가 급증하거나 API 응답 시간이 비정상적으로 증가하는 상황을 감지하도록 했다.
외부 연동 API 모니터링
병원 시스템과 연동되는 외부 API도 주기적으로 호출해 정상 응답 여부를 확인하도록 구성했다.
1분 간격으로 API 상태를 점검하며, 일시적인 통신 오류로 알림이 반복되지 않도록 연속 실패 횟수를 기준으로 장애를 판단하도록 했다.
장애가 발생하면 텔레그램으로 알림을 보내고, 정상화되었을 때도 복구 알림이 전송되도록 구현했다.
3. AI를 활용한 장애 원인 분석
단순히 장애가 발생했다는 알림만으로는 결국 담당자가 로그를 다시 확인해야 한다.
이 과정을 줄이기 위해 장애 알림이 발생하면 관련 로그와 메트릭을 자동으로 수집하고, AI가 분석하도록 구성했다.
전체적인 흐름은 다음과 같다.
장애 감지 → 텔레그램 알림 → 로그 및 메트릭 수집 → AI 분석 → 텔레그램 분석 결과 전송
장애가 감지된 시점을 기준으로 직전 15분의 OpenSearch 로그와 Prometheus 메트릭을 조회한다.
주로 확인하는 항목은 다음과 같다.
- API 상태코드별 발생 건수
- 5xx 오류가 많이 발생한 API
- 애플리케이션 에러 로그
- 파드 재시작 여부
- CPU 및 메모리 사용 현황
수집한 정보를 AI에 전달하면 장애 상황을 요약하고, 발생 가능한 원인을 분석한다.
예를 들어 5xx 오류가 급증한 시점에 특정 API에서 오류가 집중되었는지, 파드가 재시작되었는지, DB 연결 오류가 발생했는지 등을 함께 확인하는 방식이다.
분석 결과는 기존 장애 알림이 발생한 텔레그램 채팅방으로 다시 전송한다.
기존에는 알림을 확인한 뒤 여러 모니터링 화면에 접속해서 로그를 찾아야 했지만, 이제는 텔레그램에서 장애 상황과 관련 정보를 먼저 확인할 수 있도록 했다.
다만 AI가 분석한 내용이 항상 정확한 원인은 아니기 때문에 최종적으로는 실제 로그를 확인해야 한다.
4. 앞으로 개선할 부분
현재는 일반적인 운영 환경에서 장애 감지와 AI 분석이 정상적으로 동작하는지 테스트한 상태다.
실제 장애 상황에서도 유의미한 분석 결과가 나오는지는 추가로 검증할 예정이다.
또한 로그를 무조건 많이 전달하는 것보다 원인 분석에 필요한 정보만 추려서 전달하는 것이 중요하다고 생각한다.
앞으로 실제 장애 사례를 기반으로 분석 정확도를 확인하고, 불필요한 로그나 알림은 줄이면서 필요한 정보가 우선적으로 전달되도록 개선할 계획이다.
아직 개선할 부분은 있지만, 반복적으로 로그를 조회하고 장애 원인을 찾는 과정을 어느 정도 자동화했다는 점에서 의미가 있었다.
장애 자체를 막을 수는 없더라도, 장애를 인지하고 원인을 파악하는 시간을 줄이는 방향으로 계속 개선해 보려고 한다.
'TIL' 카테고리의 다른 글
| Prometheus + OpenSearch에 AI 붙여서 운영 분석해보기 (0) | 2026.09.17 |
|---|---|
| 느린 Pod로 요청이 가지 않게 할 수 있을까? (0) | 2026.09.07 |
| Sequelize 트랜잭션 깜빡하고 안 닫으면 생기는 일 (0) | 2026.09.03 |
| Kubernetes Pod별 리소스 모니터링 구성 (0) | 2026.09.03 |
| Vite 외부 공격 요청을 보면서 정리한 보안 체크 5가지 (0) | 2026.08.31 |