Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기

LY Corporation Home SRE 팀이 장애 분석 시 메트릭·로그·트레이스가 각각 다른 화면에 흩어져 있는 문제를 해결하기 위해 Grafana 플러그인 SRELens를 개발했다. SRELens는 LLM 에이전트가 자연어 질의를 받아 실제 관측성 데이터를 조회하고, 근거와 함께 장애 원인 후보를 정리해 주는 도구다. LGTM-P 스택(Loki·Grafana·Tempo·Mimir·Pyroscope)과 FlavaMCP 게이트웨이를 통합해 단일 채팅 인터페이스에서 멀티시그널 분석이 가능하다.

핵심 포인트

메트릭·로그·트레이스를 각기 다른 화면에서 오가야 하는 분석 비용을 Grafana 채팅 UI 단일 창구로 줄였다
시스템 프롬프트를 베이스 프롬프트·데이터소스 프래그먼트·사용자 프롬프트 3개 레이어로 분리해 조직 정책과 개인화를 충돌 없이 적층한다
툴 오케스트레이터를 백엔드에만 두어 사용자가 프롬프트 정책을 우회하지 못하게 한다
max rounds·duplicate call block·tool retry limit 등 안전 장치로 비용 폭주와 무한 루프를 차단한다
데이터소스마다 라벨이 다른 문제(Prometheus의 service_name vs Tempo의 resource.service.name)를 데이터소스 프래그먼트로 압축해 LLM이 올바른 라벨을 선택하게 유도한다
근거 없는 결론을 내리지 않고 "로그 조회 불가" 같은 상태를 명시적으로 드러내는 설계가 장애 대응의 신뢰성을 높인다

상세 정리

배경: 장애 분석 시 Grafana(메트릭)→LaaS/IU(로그)→IMON 트레이스→Pyroscope(프로파일) 순으로 4개 화면을 전환하며 시간 범위·서비스명·트레이스 ID를 반복 입력하는 비용이 핵심 문제였다
LGTM-P 스택: OpenTelemetry Collector를 중심으로 메트릭은 Mimir, 로그는 Loki, 트레이스는 Tempo, 프로파일은 Pyroscope로 분산 수집. 데이터는 한곳에 모였지만 데이터소스 선택·라벨·시간 범위 조합 지식은 여전히 사람 의존
오픈소스 PoC 한계: 사용자 컨텍스트 전파·시스템 프롬프트 제어·도구 호출 라운드 제한·데이터소스 라벨 차이·운영/라이선스 부담 5가지를 직접 제어하기 어려워 자체 구현 결정
아키텍처: 프런트엔드(TypeScript+React+Grafana UI), 백엔드(Go+Grafana Plugin SDK), LLM(OpenAI 툴 호출 GPT 계열), MCP 게이트웨이(FlavaMCP), 저장소(Redis), 관측성 백엔드(LGTM-P). CompositeClient로 MCP 툴과 로컬 Grafana 툴(패널 검색·렌더링)을 통합
3레이어 프롬프트 설계: 베이스 프롬프트(관리자 전용, 도구 호출 순서·안전 규칙·폴백 전략), 데이터소스 프래그먼트(SRE 운영 지식 YAML 압축, 데이터소스 UID·라벨 후보·쿼리 관습), 사용자 프롬프트(Redis 저장, 담당 서비스·선호 형식). 사용자 프롬프트는 베이스 위에 덧붙을 뿐 덮어쓰지 않음
백엔드 오케스트레이터 루프: 사용자 질문→LLM→도구 호출→결과→LLM→최종 답변 반복. 프런트엔드는 사용자·어시스턴트 메시지만 전송, 시스템 프롬프트 합성은 백엔드 전담으로 우회 차단
안전 장치: max 10라운드 제한, 호출 해시 기반 중복 호출 차단, 도구별 재시도 2회 제한, 개별 툴 결과 크기 제한+잘림 마커, 전체 히스토리 크기 제한, 결과 없을 때 라벨·시간범위·데이터소스 교체 재시도 힌트
비용 제어: 사용자별 일일 토큰 한도+분당 요청 수 제한(사후 반영 방식), 한도 초과 시 HTTP 429 반환, Redis 장애 시 단일 채팅은 계속 처리(graceful degradation)
실제 사례 1(에러 스파이크): "09:50~10:05 beta 환경 오류 급증 원인" 질의로 CopyMedia 요청 급증→존재하지 않는 대상 복사→404/409 대량 발생 연결. 인프라 장애가 아닌 요청 패턴 문제임을 메트릭·트레이스 교차 분석으로 특정
실제 사례 2(포이즌 필): Tempo의 {resource.service.name="stream-processor-beta" && status=error}와 Loki의 구조화 메타데이터 필터({service_name=...} | detected_level="ERROR")를 연속 실행해 재시도 체인과 업스트림 필드 결함을 연결 확인
실제 사례 3(모른다 말하기): 로그가 Loki에 미수집된 상황에서 "Loki 로그 기반 근거 확보 불가"를 명시하고 트레이스 기반 가설만 제시. 없는 근거를 지어내지 않는 설계
개발 도전: 관측성 응답 수백 KB 초과 문제는 집계 쿼리 우선(count_over_time·topk·sum by) 유도+잘림 마커로 해결. LLM 응답도 신뢰 불가 입력으로 처리해 HTML 직접 렌더링 금지·Mermaid 정제·URL 허용 스킴 제한
UX: SSE로 tool_call·image·link·done·error 이벤트 분리 스트리밍, Stop 버튼으로 생성 중단, render_grafana_panel로 패널 PNG를 채팅 내 표시, 대화 기록 Redis 30일 TTL