TL;DR
LY Corporation Home SRE 팀은 Grafana 안에서 메트릭·로그·트레이스·프로파일을 자연어로 묶는 SRELens를 만들었습니다.
원문이 밝힌 유일한 수치는 한도 초과 시 HTTP 429 반환입니다.
실무에서는 데이터소스 라벨과 프롬프트 정책, 도구 호출 한도를 분리해 통제해야 합니다.
LY Corporation Home SRE 팀은 왜 이 도구를 만들었나
이 글은 LY Corporation의 techblog.lycorp.co.jp에 실린 「Grafana에서 자연어로 장애 원인을 분석하기: LLM 에이전트 기반 SRELens 개발기」를 바탕으로 정리합니다. 원문은 Home SRE 팀이 장애 분석에서 겪는 맥락 이동 비용을 먼저 보여 줍니다. 메트릭은 Grafana나 IMON에서 보고, 로그는 LaaS와 IU에서 찾고, 트레이스는 IMON Trace나 Tempo에서 확인해야 했습니다.
프로파일은 또 다른 도구를 열어야 했습니다.
문제는 데이터가 없어서가 아니었습니다. 신호는 충분했지만, 신호가 서로 다른 화면에 흩어져 있었습니다. 그래서 사람은 시간 범위, 서비스명, 라벨, 트레이스 ID를 계속 옮겨 적어야 했습니다.
원문은 이 비용이 장애 대응 속도를 깎는다고 설명합니다.
팀은 자체 호스팅형 LGTM-P 스택을 구축해 데이터를 한 흐름으로 모았습니다. 그다음 Grafana 안에서 이 데이터를 이어서 보려 했습니다. 하지만 데이터가 모여도 분석이 자동으로 쉬워지지는 않았습니다.
조회 규칙과 라벨 차이를 사람이 여전히 알아야 했기 때문입니다.
SRELens는 이 간극을 줄이기 위해 나온 Grafana 애플리케이션 플러그인입니다. 사용자는 자연어로 질문하고, 대규모 언어 모델 기반 에이전트가 실제 관측성 데이터를 조회합니다. 그다음 근거와 함께 분석 결과를 제시합니다.
원문에서 확인된 수치는 HTTP 429 하나입니다
원문에서 문자 그대로 확인되는 수치는 다음 하나입니다.
- HTTP 429: 한도 초과 시 SRELens가 반환하는 응답 코드입니다.
한도 초과 시 HTTP 429 반환
이 값은 에이전트가 마음대로 더 시도하지 못하게 막는 경계선입니다. 원문은 사용량 한도를 코드로 드러내고 있습니다.
데이터 소스를 통합해도 맥락 비용은 남습니다
원문은 데이터가 한곳에 모여도 조회 방법을 사람이 알아야 한다고 말합니다. 같은 서비스 이름도 데이터 소스마다 라벨이 다를 수 있습니다. 메트릭에서는 service_name을, Tempo에서는 resource.service.name을 써야 할 수 있습니다.
로그도 단순하지 않습니다. Loki에서는 로그 본문을 JSON으로 파싱해야 할 수 있고, 구조화된 메타데이터를 직접 필터해야 할 수 있습니다. 즉, 통합 저장소는 출발점일 뿐입니다.
분석의 핵심은 데이터 간 연결 규칙입니다.
이 지점에서 SRELens의 의미가 분명해집니다. 이 도구는 데이터를 모으는 장치가 아니라, 숙련된 SRE의 조회 습관을 자연어 질문 흐름으로 바꾸는 장치입니다. 원문이 말하는 핵심은 도구 수가 아니라 운영 지식의 전달 방식입니다.
운영 환경에서는 프롬프트와 도구 권한을 분리해야 합니다
원문은 오픈소스 PoC로 가능성은 확인했지만, 운영 환경에는 한계가 있었다고 설명합니다. 사용자 컨텍스트 전파와 권한 관리가 안정적이어야 했고, 시스템 프롬프트도 조직 규칙대로 통제돼야 했습니다. 도구 호출 라운드도 짧으면 안 됐습니다.
그래서 SRELens는 백엔드를 단순 중계기로 두지 않았습니다. 백엔드는 LLM 에이전트, 프롬프트 합성, 도구 호출 제어, 사용량 제한을 맡습니다. 프런트엔드는 Grafana 안의 채팅 UI를 제공합니다.
관측성 데이터 조회는 MCP 게이트웨이로 연결합니다. 저장소로는 Redis를 사용해 대화 기록과 사용량 카운터를 다룹니다. 관측성 백엔드는 Mimir, Loki, Tempo, Pyroscope입니다.
프롬프트도 세 레이어로 나눴습니다. 베이스 프롬프트는 조직 공통 정책을 담습니다. 대시보드 생성·수정·삭제 같은 위험 작업은 여기서 막습니다.
결과가 비었을 때의 폴백과, 결과가 잘렸을 때 다시 집계 쿼리를 날리는 규칙도 들어갑니다. 데이터소스 프래그먼트는 어디를 볼지 정합니다. 사용자 프롬프트는 개인 맥락을 더합니다.
이 구조는 정책과 개인 취향이 섞여 버리는 일을 줄입니다.
실무에서는 이 분리가 중요합니다. 조직 정책은 관리자만 바꾸게 두고, 데이터소스별 라벨은 설정으로 관리하고, 사용자별 사용량은 별도 경계로 다뤄야 합니다. 원문처럼 한도 초과 시에는 HTTP 429로 경계를 드러내는 방식이 깔끔합니다.
자주 묻는 질문
SRELens는 무엇을 하는 도구입니까?
SRELens는 Grafana 안에서 자연어로 관측성 데이터를 묶어 분석하는 플러그인입니다. 원문은 메트릭·로그·트레이스·프로파일을 함께 조회하고, 근거까지 제시한다고 설명합니다.
기존 도구에 대규모 언어 모델을 붙이면 충분하지 않았습니까?
충분하지 않았습니다. 원문은 사용자 컨텍스트 전파, 프롬프트 통제, 도구 호출 라운드, 라벨 차이 때문에 자체 구현이 필요했다고 밝힙니다.
실무에서 가장 먼저 점검할 부분은 무엇입니까?
데이터소스 라벨과 프롬프트 정책, 사용량 한도부터 분리해야 합니다. 같은 서비스명도 데이터소스마다 표현이 다를 수 있으므로, 조회 규칙을 설정으로 고정해야 합니다.