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

관측성 데이터가 메트릭·로그·트레이스·프로파일별로 분산되면, 장애 원인을 파악하기 위해 사람이 여러 도구를 오가며 맥락을 연결해야 합니다. LY Corporation의 Home SRE 팀은 이를 해결하기 위해 Grafana 플러그인인 SRELens를 개발했습니다. SRELens는 자연어 질문을 바탕으로 LLM 에이전트가 관측성 데이터를 조회하고, 도구 호출과 비용·권한·안전 정책을 백엔드에서 통제하며 원인 후보를 근거와 함께 제시합니다.

관측성 데이터가 분산되며 발생한 문제

• 메트릭은 Grafana·IMON, 로그는 LaaS·IU, 트레이스는 IMON 트레이스·Tempo, 프로파일은 별도 도구에서 확인해야 했습니다.
• 장애 분석 과정에서 시간 범위, 서비스명, 라벨, 트레이스 ID 등의 맥락을 여러 시스템에 반복해서 옮겨야 했습니다.
• 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 통합했습니다.
  • Mimir: 메트릭
  • Loki: 로그
  • Tempo: 트레이스
  • Pyroscope: 프로파일
  • OpenTelemetry Collector: 데이터 수집 및 전달
• 데이터가 한곳에 모여도 사용자가 적절한 데이터소스와 라벨, 쿼리 방법을 알아야 한다는 문제는 남았습니다.
• 예를 들어 서비스명이 데이터소스마다 service_name, resource.service.name 등 다른 필드로 표현될 수 있습니다.

오픈소스 PoC에서 확인한 한계

• 사용자 컨텍스트와 권한 전파
  • Grafana 인증 사용자 정보를 대화 기록, 사용량 한도, 조회 권한에 안정적으로 연결하기 어려웠습니다.
• 시스템 프롬프트 제어
  • 도구 호출 순서, 재시도, 위험 작업 제한 같은 운영 정책을 사용자 질의와 분리해 보호하기 어려웠습니다.
• 짧은 도구 호출 라운드
  • 메트릭·트레이스·로그를 순차적으로 확인해야 하는 장애 분석을 충분히 수행하지 못했습니다.
• 데이터소스별 라벨 차이
  • 올바른 데이터소스를 선택해도 라벨이나 필드가 다르면 검색 결과가 0건이 될 수 있었습니다.
• 운영 및 라이선스 제약
  • 사내 환경에 맞게 수정하고 배포하는 데 한계가 있었습니다.
• 이를 통해 단순한 자연어 질의 기능보다, LLM 에이전트의 행동을 운영 환경에 맞게 통제하는 것이 더 중요하다는 결론을 얻었습니다.

SRELens 아키텍처

• SRELens는 Grafana 애플리케이션 플러그인으로 동작합니다.
• 프런트엔드는 Grafana 내부에 채팅 UI를 제공합니다.
• 백엔드는 다음을 담당합니다.
  • LLM 호출
  • 시스템 프롬프트 합성
  • 도구 오케스트레이션
  • 사용량 및 비용 제한
  • 결과 크기와 재시도 제어
• 관측성 데이터 조회는 MCP 게이트웨이를 통해 수행합니다.
• 업스트림 MCP 도구 외에도 Grafana 패널 검색과 이미지 렌더링을 위한 로컬 도구를 제공합니다.
  • find_grafana_panel
  • render_grafana_panel
• 업스트림 도구와 로컬 도구는 CompositeClient를 통해 LLM에 일관된 인터페이스로 노출됩니다.

세 계층으로 분리한 프롬프트 설계

베이스 시스템 프롬프트

• 조직 전체에 적용되는 전역 행동 정책입니다.
• 다음과 같은 규칙을 포함합니다.
  • 도구 호출 순서
  • 결과가 없을 때의 폴백 전략
  • 결과가 잘렸을 때 집계 쿼리를 재실행하는 방법
  • 대시보드 생성·수정·삭제 등 위험 작업의 안전 규칙
  • 응답 형식과 분석 근거 제시 방식
• 관리자만 수정할 수 있으며, 별도 설정이 없으면 코드에 포함된 기본 프롬프트를 사용합니다.

데이터소스 프래그먼트

• 환경별 관측성 시스템 정보를 YAML 형태로 제공합니다.
• 주요 내용은 다음과 같습니다.
  • 우선 사용할 Mimir·Loki·Tempo 데이터소스 UID
  • 서비스명을 찾기 위한 라벨 후보
  • Loki 로그의 JSON 파싱 및 구조화 메타데이터 처리 방법
• SRE의 운영 지식을 미리 제공해 불필요한 탐색을 줄이고 분석 성공률과 속도를 높입니다.

사용자 프롬프트

• 담당 서비스, 선호 응답 형식, 자주 사용하는 대시보드 등 개인·팀의 맥락을 저장합니다.
• Redis에 저장되며 시스템 프롬프트의 추가 컨텍스트로 주입됩니다.
• 베이스 프롬프트를 덮어쓰지 않으므로 개인화가 조직 공통 안전 정책보다 우선할 수 없습니다.

백엔드 중심의 툴 오케스트레이션

• 프런트엔드가 시스템 프롬프트를 조립하지 않고, 백엔드 오케스트레이터가 모든 프롬프트 합성을 담당합니다.
• 에이전트는 다음 루프를 반복합니다.
  1. 사용자 질문을 LLM에 전달
  2. LLM이 요청한 MCP 또는 로컬 도구 실행
  3. 도구 결과를 다시 LLM에 전달
  4. 최종 분석이 나올 때까지 반복
• 운영 안정성을 위해 코드 수준의 가드레일을 적용했습니다.
  • 최대 10라운드로 도구 호출 제한
  • 동일 도구·동일 인자의 중복 호출 차단
  • 도구별 재시도 최대 2회
  • 개별 도구 결과 크기 제한
  • 전체 요청이 커질 경우 오래된 도구 결과를 플레이스홀더로 치환
  • tool_call_id를 유지해 호출과 결과의 연결 보장
  • 결과가 없으면 라벨, 시간 범위, 데이터소스를 바꿔 재시도하도록 유도

비용·요청량 및 장애 대응 정책

• 사용자별 일일 토큰 한도를 적용합니다.
• 분당 요청 수를 제한하고, 한도 초과 시 HTTP 429를 반환합니다.
• 응답 후 OpenAI가 반환한 실제 프롬프트·출력 토큰 사용량을 사용자별 일일 버킷에 기록합니다.
• 사용량은 Asia/Seoul 기준 자정에 초기화됩니다.
• Redis는 대화 기록, 사용자 프롬프트, 쿼터 저장에 사용됩니다.
• Redis 장애가 발생해도 단일 채팅 요청은 계속 처리할 수 있도록 설계했습니다.
  • 대화 기록 및 개인화 기능은 제한될 수 있습니다.
  • SRELens 전체가 동시에 중단되지는 않습니다.

실제 장애 분석 방식의 변화

• 사용자는 “특정 시간대에 왜 에러가 늘었는가”처럼 자연어로 질문할 수 있습니다.
• SRELens는 하나의 분석 흐름에서 메트릭, 로그, 트레이스를 연결해 확인합니다.
• 예시 시나리오에서는 베타 환경의 오류 급증을 분석하면서 특정 API 요청인 CopyMedia 호출 증가와 관련된 원인까지 범위를 좁혔습니다.
• 기존처럼 대시보드, 로그 검색 시스템, 트레이스 도구를 오가며 사람이 상관관계를 직접 맞출 필요가 줄어듭니다.
• 분석 결과는 단순한 결론이 아니라 조회된 관측성 데이터와 근거를 함께 제시하는 것을 목표로 합니다.

운영 환경에서 LLM 기반 장애 분석을 도입할 때는 자연어 인터페이스보다 통제 구조를 먼저 설계하는 것이 중요합니다. 조직 정책과 환경별 데이터소스 지식을 프롬프트 계층으로 분리하고, 도구 호출·권한·비용·재시도를 백엔드 코드로 제한해야 안정적이고 재현 가능한 분석 도구를 만들 수 있습니다.