WhaTap AI 같은 서비스 제작하기: 성능 지표·장애 로그·진단 가설 연결 제작법

핵심 요약

1. 서비스 지표와 로그를 함께 조회해 장애 원인을 조사할 단서와 후속 질문을 만드는 AI를 설계합니다. 2. Prometheus API·OpenSearch API·Claude API와 Apache ECharts를 기능별 후보로 활용합니다. 3. 지표 수집과 시간 정렬, 서비스 권한, 근거 연결과 가설 검증은 자체 로직이 담당합니다.

WhaTap AI의 기능에서 참고할 가치는 운영자가 지표와 로그 사이를 오가며 원인을 찾는 과정을 돕는 것입니다. 모니터링 AI 챗봇 개발에서는 이미 수집한 데이터의 범위와 빠진 부분을 명확히 보여줘야 합니다. 아래는 유사한 진단 지원 기능의 구현 구성입니다.

서비스 지표를 실제 수집 데이터에서 조회하기

입력은 서비스와 조회 기간, 확인할 지표입니다. Prometheus API로 CPU·메모리·응답시간 등 실제 수집된 지표를 조회할 수 있습니다. 이를 위해 대상 서비스의 수집 설정과 필요한 exporter가 먼저 준비돼야 합니다.

자체 코드는 서비스 이름과 지표 라벨의 관계를 관리하고 기간·집계 간격·단위를 검사합니다. 자연어 모니터링 지표 조회를 구현할 때도 허용된 지표와 쿼리 범위를 제한합니다. 출력은 기준 시각과 단위가 있는 시계열이며 수집되지 않은 구간을 0으로 바꾸지 않습니다.

의심 시점의 관련 로그 찾아보기

입력은 지표가 변한 시점과 서비스·요청 식별자입니다. OpenSearch API로 해당 기간의 오류와 관련 기록을 검색하는 구성을 사용할 수 있습니다. 자체 코드는 로그 수집 형식과 시간대, 서비스·요청 ID의 연결 규칙을 정합니다.

OpenSearch 로그 분석 챗봇은 조직별 조회 범위를 적용하고 민감한 값의 노출을 제한해야 합니다. 중복 로그와 수집 지연을 표시하면 이벤트 수를 잘못 해석하는 일을 줄일 수 있습니다. 출력은 원본 위치와 시각이 있는 관련 기록이며 로그가 없을 때 수집 상태도 함께 확인합니다.

지표와 로그로 진단 가설 만들기

입력은 선별한 시계열과 로그, 최근 변경 이력 등 확인된 정보입니다. Claude API로 관찰된 변화와 가능한 원인, 다음에 확인할 항목을 정리할 수 있습니다. 모델에는 근거가 있는 사실과 아직 검증하지 않은 해석을 구분하도록 요청합니다.

서버 응답 지연 원인 분석에서는 같은 시간에 두 지표가 올랐다는 사실만으로 원인을 확정하지 않습니다. 자체 로직은 설명에 사용한 지표 구간과 로그 ID를 연결하고 추가 조회가 필요한 항목을 보여줍니다. 출력은 근거가 있는 진단 가설과 질문이며 운영자가 검증한 결과를 기록할 수 있게 합니다.

ECharts 모니터링 대시보드 구성하기

입력은 검증한 집계 결과와 비교할 기간입니다. Apache ECharts로 지표 추이와 사건 시점을 표시할 수 있습니다. 자체 코드가 집계와 단위 변환을 처리하고 차트는 전달받은 데이터를 표현하도록 역할을 나눕니다.

차트에서 특정 구간을 선택하면 같은 시간대의 로그와 설명을 보여줍니다. 기간이 다른 데이터를 비교할 때는 집계 간격과 표본 수를 맞추고 결측 구간을 표시합니다. 출력은 원자료로 이동할 수 있는 대시보드이며 갱신 시각과 조회 조건도 함께 남깁니다.

진단과 운영 조치를 분리해 관리하기

AI 옵저버빌리티 기능의 목적은 조사 시간을 줄이는 데 있습니다. 진단 가설이 생성됐다는 이유만으로 서버 설정을 바꾸거나 프로세스를 재시작하지 않도록 조치 단계는 별도 권한과 승인으로 관리합니다. 조사 결과와 실제 조치의 효과를 연결하면 다음 검토에 활용할 수 있습니다.

평가에는 잘못된 시간 정렬, 지표 단위 오류, 로그 근거 누락과 검증되지 않은 원인 단정을 포함합니다. AI 스킬에는 조사 순서와 보고 형식을 담고 데이터 수집·조회·권한은 코드로 구현합니다. 모니터링할 서비스와 데이터 범위를 정리해 트램스 AI에 제작을 문의해 주세요: https://trams.co.kr/ai-si/contact/#inquiry