line·2026년 7월 31일·5분 읽기큐레이션 요약

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

원문 읽기(새 탭에서 열림)

grafana옵저버빌리티모델 컨텍스트 프로토콜redis+3

gitlab·2026년 4월 28일원문

대규모 환경에서 CI/CD 관측성을 구축하는 방법 (새 탭에서 열림)

GitLab 셀프 매니지드 환경에서 CI/CD 가시성을 확보하는 것은 대규모 데브옵스 플랫폼의 성능 최적화와 안정적인 운영을 위한 필수 과제입니다. 이 글은 Prometheus와 Grafana, 그리고 전용 익스포터를 활용하여 원시 파이프라인 데이터를 실시간 대시보드로 변환하고 의사결정에 필요한 핵심 통찰을 얻는 기술적 방법론을 제시합니다. 이를 통해 기업은 인프라 투자 효율성을 높이고 병목 현상을 체계적으로 해결할 수 있는 데이터 기반의 관리 체계를 구축할 수 있습니다. ### 실시간 통찰을 위한 다층적 대시보드 구성 효과적인 CI/CD 옵저버빌리티를 위해 다음과 같은 네 가지 핵심 대시보드를 구성하여 운영 가시성을 확보합니다. * **파이프라인 개요 대시보드:** 전체 실행 횟수, 시간 흐름에 따른 성공/실패율, 평균 소요 시간 추이를 시각화합니다. 상태별 색상 코딩을 통해 플랫폼 팀이 성능 저하를 즉각적으로 감지할 수 있도록 합니다. * **작업(Job) 성능 대시보드:** 개별 작업의 실행 시간 분포(히스토그램)와 가장 느린 상위 10개 작업을 분석합니다. 프로젝트 및 스테이지별 실패 히트맵을 통해 최적화가 필요한 병목 지점을 특정합니다. * **러너 및 인프라 대시보드:** Node Exporter의 호스트 지표(CPU, 메모리, 디스크)와 파이프라인 대기 시간을 결합하여 분석합니다. 인프라 포화도와 작업 지연의 상관관계를 파악하여 러너 스케일링이나 인스턴스 업그레이드 등의 용량 계획 수립에 활용합니다. * **배포 빈도 대시보드:** 환경별 배포 횟수와 소요 시간을 추적하여 DORA 지표를 관리합니다. 엔지니어링 리더십은 이를 통해 릴리스 속도와 메인 브랜치 대비 커밋 지연 상태(Environment Drift)를 점검할 수 있습니다. ### 옵저버빌리티 구현을 위한 핵심 기술 스택 GitLab의 원시 데이터를 수집하고 시각화하기 위해 두 가지 주요 익스포터와 컨테이너 기반 인프라를 사용합니다. * **GitLab CI Pipelines Exporter:** GitLab API를 통해 파이프라인 소요 시간, 작업 상태, 배포 정보 등 CI/CD 관련 핵심 메트릭을 수집합니다. * **Node Exporter:** 러너가 실행되는 호스트의 하드웨어 및 OS 지표를 수집하여 인프라 수준의 통찰을 제공합니다. * **Grafana 파일 기반 프로비저닝:** 모든 대시보드를 코드로 관리하고 자동으로 배포하여 여러 환경에서 일관된 모니터링 환경을 유지합니다. 프로젝트나 브랜치별 필터링을 위한 변수 설정이 가능합니다. ### 엔터프라이즈급 Kubernetes 배포 아키텍처 대규모 환경에서는 확장성과 보안을 위해 Kubernetes 클러스터에 각 컴포넌트를 분리된 Deployment로 배포하는 것이 권장됩니다. * **네임스페이스 및 보안 관리:** `gitlab-observability`와 같은 전용 네임스페이스를 생성하고, GitLab API 접근을 위한 Personal Access Token(`read_api` 권한)을 Kubernetes Secret으로 안전하게 관리합니다. * **익스포터 배포:** `gitlab-ci-pipelines-exporter`를 Deployment로 구성하고, ConfigMap을 통해 수집 대상 프로젝트 및 설정을 주입합니다. * **데몬셋 활용:** `Node Exporter`는 DaemonSet으로 배포하여 클러스터 내 모든 노드의 메트릭을 빠짐없이 수집합니다. * **Prometheus 통합:** 수집된 모든 메트릭은 Prometheus로 집계되며, 이를 Grafana의 데이터 소스로 연결하여 시각화 체계를 완성합니다. 대규모 CI/CD 환경을 운영하는 조직이라면 단순한 로그 확인을 넘어, 이와 같은 통합 옵저버빌리티 스택을 구축할 것을 권장합니다. 특히 인프라 비용 최적화와 개발 생산성 향상을 목표로 한다면, DORA 메트릭과 인프라 지표를 연계한 분석이 병목 현상 해결의 결정적인 열쇠가 될 것입니다. 중간 규모 이하의 환경이나 PoC 단계에서는 Docker Compose를 통해 빠르게 프로토타입을 구축해본 후 Kubernetes로 확장하는 전략이 효과적입니다.

grafana쿠버네티스옵저버빌리티CI/CD+4

slack·2026년 3월 31일·3분 읽기큐레이션 요약

커스텀에서 오픈으로: Prometheus를 활용한 확장 가능한 네트워크 프로빙 및 HTTP/3 준비성

Slack은 HTTP/3 도입 과정에서 기존 모니터링 도구가 QUIC/UDP 기반 엔드포인트를 측정하지 못하는 관측성 공백을 발견했다. 이를 해결하기 위해 Prometheus Blackbox Exporter에 `quic-go` 기반 HTTP/3 프로빙 기능을 추가하고 오픈소스로 공개했다. 그 결과 HTTP/1.1, HTTP/2, HTTP/3를 Grafana에서 통합 관찰하고 더 정확한 알림과 장애 분석이 가능해졌다. ### 기존 모니터링 도구의 한계 - Slack은 AWS Availability Zone 간 내부 트래픽과 인터넷에서 인프라로 유입되는 외부 트래픽을 상용 SaaS 및 자체 도구로 측정해 왔다. - HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용한다. - 기존 SaaS 관측성 도구 대부분은 HTTP/3 프로빙을 기본 지원하지 않았다. - 핵심 모니터링 도구인 Prometheus Blackbox Exporter(BBE)에도 QUIC 네이티브 지원이 없었다. - 수십만 개의 HTTP/3 엔드포인트를 측정할 수 없어 HTTP/2로의 회귀, 실제 왕복 시간(RTT), 클라이언트 관점의 성능 변화를 파악하기 어려웠다. ### `quic-go` 기반 HTTP/3 프로브 구현 - 인턴 Sebastian Feliciano가 BBE에 QUIC 지원을 구현하고 오픈소스로 기여했다. - Go용 QUIC 라이브러리로 널리 사용되는 `quic-go`를 선택했다. - HTTP/3 전송 계층을 다음과 같이 구성해 기존 HTTP 클라이언트에 연결했다. ```go http3Transport := &http3.Transport{ TLSClientConfig: tlsConfig, QUICConfig: &quic.Config{}, } client = &http.Client{ Transport: http3Transport, } ``` - BBE의 기존 설정 방식과 아키텍처를 유지해 새로운 프로브도 기존 기능과 조합할 수 있도록 설계했다. - 이를 통해 HTTP/3 엔드포인트에 대해 설정 가능한 Prometheus 프로브가 제공됐다. ### 오픈소스 기여와 사내 통합 - 새로운 기능을 Prometheus BBE에 upstream 기여해 다른 조직도 사용할 수 있게 했다. - 오픈소스 PR의 병합을 기다리는 동안, Slack은 새 기능을 활용하는 사내 프로빙 시스템도 별도로 설계했다. - 결과적으로 외부 공개 기능과 Slack 인프라에 맞춘 운영 시스템을 함께 확보했다. ### 통합 관측성과 운영 개선 - Grafana에서 HTTP/1.1, HTTP/2, HTTP/3 지표를 하나의 화면에서 확인할 수 있게 됐다. - 프로토콜별 성능을 비교하고 다른 텔레메트리와 상관관계를 분석하기 쉬워졌다. - HTTP/3 엔드포인트의 상태와 성능을 기반으로 더 정확하고 신뢰성 높은 알림을 만들 수 있게 됐다. - 장애 발생 시 관련 지표를 한곳에서 확인해 원인 분석과 디버깅 속도를 높였다. ### 향후 확장 방향 - **SNI 라우팅 테스트** - 공유 IP를 사용하는 CDN이나 멀티테넌트 로드밸런서에서 요청한 호스트명이 올바른 백엔드로 라우팅되는지 검증한다. - 올바른 TLS 인증서가 반환되는지도 확인해 잘못된 라우팅을 방지할 수 있다. - **종단 간 네트워크 경로 시각화** - 단순한 성공/실패 확인을 넘어 모니터링 에이전트부터 서비스까지의 네트워크 홉을 시각화한다. - 지연 증가나 패킷 손실이 어느 구간에서 발생했는지 파악할 수 있다. ### 실무적인 시사점 - 새로운 프로토콜이나 인프라로 마이그레이션하기 전에 먼저 관측성을 확보해야 한다. - 기존 도구에 기능이 없을 때 직접 구현하고 오픈소스로 공유하면 조직과 커뮤니티 모두의 비용을 줄일 수 있다. - HTTP/3 도입을 검토하는 팀이라면 Prometheus Blackbox Exporter의 QUIC 프로브를 활용해 마이그레이션 전후 성능과 장애를 지속적으로 비교하는 것이 좋다.

원문 읽기(새 탭에서 열림)

grafana옵저버빌리티Goprometheus+4

line·2026년 3월 19일원문

신뢰성 향상을 위한 SLI/SLO 활용 1편 - SLI/SLO 프레임워크 및 서비스 상태 확인 도구 LINE Status 개발기 (새 탭에서 열림)

서비스 신뢰성을 관리하기 위한 공통 언어로서 SLI/SLO를 전사적으로 확산하기 위해, 반복되는 도입 과정을 표준화한 'SLI/SLO 프레임워크'를 정립하고 이를 시각화하는 'LINE Status' 도구를 개발했습니다. 단순한 장애 여부가 아닌 사용자 경험(CUJ) 관점에서 서비스 상태를 정의함으로써, 기술적 지표에 매몰되지 않고 조직 전체가 동일한 기준으로 서비스 품질을 파악하고 의사소통할 수 있는 기반을 마련했습니다. 이러한 체계는 운영 자동화와 데이터 기반의 거버넌스 구축을 가능하게 하여 장기적인 서비스 신뢰성 향상을 이끌어냅니다. **SLI/SLO 프레임워크의 5단계 구조** * **CUJ 선정 및 SLI 정의:** 서비스의 본질적인 사용자 경험을 파악하여 핵심 여정(Critical User Journey)을 선정하고, 이를 측정 가능한 지표인 SLI로 구체화합니다. * **계측 및 메트릭 설계:** Prometheus나 OpenTelemetry의 표준 네이밍 규칙을 적용하여 CUJ에 적합한 메트릭을 설계하고 구현합니다. * **대시보드 및 기록 규칙 구성:** Grafana를 통해 SLO 달성 여부를 직관적으로 확인하며, 복잡한 연산은 Recording Rules로 사전 처리하여 조회 효율을 높입니다. * **SLO 및 알람 설정:** 28일 롤링 윈도우 기반으로 초기 SLO를 설정하고, 단계적으로 목표치를 확정하며 대응을 위한 Runbook을 정의합니다. * **에러 예산 기반 운영:** 릴리스 속도와 안정성 사이의 균형을 맞추고, 정기적인 리뷰를 통해 목표를 점검하며 거버넌스를 확립합니다. **사용자 경험 중심의 LINE Status 도구** * **CUJ 기반 상태 정의:** 단순한 서버 장애 유무가 아니라, 사용자가 서비스를 원활히 이용하고 있는지(User Happiness)를 기준으로 상태를 판단합니다. * **기능 중심의 명칭 노출:** "API 500 에러"와 같은 기술 용어 대신 "메시지 전송", "읽음 표시" 등 사용자가 체감하는 기능 단위로 상태를 표현하여 직관성을 높였습니다. * **자동화된 상태 관리:** 각 서비스의 SLI/SLO 알림을 웹훅(Webhook)으로 수집하여 실시간으로 상태를 갱신하고, 이벤트 발생 이력을 DB에 저장해 추적합니다. * **시각적 편의 기능:** AI를 활용한 한 줄 분석 요약, 직관적인 신호등 색상 표현, 타임라인 기반의 이벤트 히스토리 페이지 등을 제공합니다. **AI 활용과 프레임워크의 연결 효과** * **바이브 코딩과 명확한 기획:** 프런트엔드 개발 경험이 부족하더라도 AI를 적극 활용하여 UI를 구현했으며, 마크다운 형식의 구체적인 요구사항 정의가 결과물의 완성도를 결정함을 확인했습니다. * **공통 창구 제공:** 개발자와 운영자가 각자의 대시보드를 보는 대신, LINE Status라는 단일 창구를 통해 사용자 경험에 미치는 영향을 즉각적으로 파악할 수 있습니다. * **확산 가능한 운영 기반:** 프레임워크를 통해 서비스를 정의하고 그 결과를 LINE Status에 등록하는 일련의 과정을 통해, 특정 인원에 의존하지 않는 지속 가능한 신뢰성 관리 체계를 구축했습니다. **실용적인 결론** 성공적인 SLI/SLO 도입을 위해서는 기술적 측정보다 **'사용자 경험(CUJ)의 명확한 정의'**와 **'조직 간의 공통 언어 수립'**이 선행되어야 합니다. 또한, 표준화된 템플릿과 자동화된 상태 확인 도구를 결합함으로써 커뮤니케이션 비용을 줄이고 데이터에 기반한 의사결정 속도를 높일 수 있습니다.

grafana데이터베이스 설계APIprometheus+3