Cilium Log Monitoring with Grafana Loki + Grafana Alloy [Cilium Study 2주차]
Cilium Log Monitoring with Grafana Loki + Grafana Alloy [Cilium Study 2주차]
저번 시간에는 Prometheus를 사용해 Cilium/Hubble의 상태를 수집했고, Grafana를 통해 Metric 시각화를 했습니다. 하지만 문제가 발생한 직후 원인을 빠르게 파악하기 위해서는 L3/L4/L7 레벨에서 무엇이, 언제, 어디서, 왜 일어났는지에 대한 로그와 해당 로그를 간편하게 조회할 수 있는 시스템이 필요합니다.
이번 글에서는 Grafana Loki와 Grafana Alloy에 대해 알아보고, 더 나아가 해당 툴을 사용해 Cilium/Hubble Log Pipeline을 구성하는 방법에 대해 알아보겠습니다.
TL;DR
- Loki는 로그 본문 전체를 인덱싱하지 않고 각 스트림의 label 메타데이터만 인덱싱합니다. 그래서 인덱스가 작고 청크 압축률이 높아 Elasticsearch 대비 저장 비용이 낮습니다.
- 읽기 경로와 쓰기 경로를 따로 확장할 수 있고, 모놀리식과 마이크로서비스 모드를 모두 지원합니다. 테넌트는
X-Scope-OrgID헤더로 구분합니다.- LogQL은 PromQL과 문법이 비슷해
rate()나count_over_time()으로 로그를 메트릭처럼 집계할 수 있습니다.
1. Grafana Loki란?
Application boundary
App 1 로그와 label metadata를 생성한다.
App 2 같은 수집 경로로 로그를 내보낸다.
collect logs
Agent 애플리케이션 로그를 읽고 label을 붙여 Loki write endpoint로 전송한다.
write stream
Grafana Loki log body는 저장하고 label metadata를 index해 tenant별 stream을 관리한다.
Grafana / LogCLI가 Loki에 LogQL 요청; Loki가 결과 반환
Grafana 대시보드와 LogQL query로 로그를 탐색한다.
LogCLI CLI에서 같은 Loki query API를 호출한다.
Loki의 Read와 Write 경로는 독립적으로 확장할 수 있고 multi-tenant 요청은 tenant header로 분리한다.
Grafana Loki는 Prometheus에서 영감을 받아 개발된 수평 확장성과 고가용성을 갖춘 멀티테넌트 로그 집계 시스템입니다. 기존 로깅 시스템과 달리 Loki는 로그 전체 내용을 인덱싱하지 않고, 각 로그 스트림의 레이블(Label) 메타데이터만 인덱싱합니다. 이 설계 덕분에 작은 인덱스와 고도로 압축된 청크(Chunk) 구조로 저장이 가능하여 저장 비용이 저렴하고 운영이 간편합니다.
1.1. Grafana Loki 특징
| 특징 | 설명 |
|---|---|
| 비용 효율성 | 로그 본문 전체를 인덱싱하지 않고, 각 로그 스트림의 레이블(Label) 메타데이터만 인덱싱. 작은 인덱스와 고도로 압축된 청크 저장 구조로 운영 비용 절감. Elasticsearch 같은 풀텍스트 검색 시스템 대비 저장소 요구량이 훨씬 적음. |
| 확장성 | 소규모(개발, PoC) 환경부터 페타바이트 규모의 대규모 환경까지 대응 가능. 읽기(Read)와 쓰기(Write) 경로를 독립적으로 확장할 수 있음. 모놀리식(단순 확장 가능 모드)과 마이크로서비스(분산 모드) 모두 지원. |
| 멀티테넌시 지원 | 하나의 Loki 인스턴스에서 여러 팀과 환경을 분리 운영 가능. 테넌트 ID를 통해 데이터와 요청을 논리적으로 분리. API 요청 시 X-Scope-OrgID 헤더로 테넌트 지정. |
| 유연한 저장소 백엔드 | Amazon S3, Google Cloud Storage, MinIO 등 객체 스토리지에 청크 저장 가능. 로컬 파일시스템 저장도 가능(개발 및 테스트 환경에 적합). 압축 및 청크 단위 저장 구조로 장기 보존에 효율적. |
| LogQL | PromQL과 유사한 Query 언어. 로그 필터링, 라벨 기반 집계, 시간 범위 지정 가능. rate(), count_over_time() 등으로 로그를 메트릭처럼 분석 가능. |
| Grafana 연동 | Grafana에서 Loki 데이터 소스를 추가하여 실시간 로그 조회. 메트릭과 트레이스와 함께 로그를 시각화하고 상관 분석 가능. Explore 모드, 대시보드 패널, Alert Rule 모두 활용 가능. |
| 알림(Alerts) | Ruler 컴포넌트를 통해 로그 Query결과에 기반한 경보 생성. Prometheus Alertmanager와 연계하여 Slack, Email, PagerDuty 등 다양한 채널로 알림 전송 가능. 특정 키워드, 에러율, 이벤트 패턴 감지 가능. |
1.2. Grafana Loki 구성 요소
Write Path
Log stream Agent 또는 Grafana Alloy가 label과 log line을 보낸다.
validate and rate limit
Distributor tenant 요청을 검증하고 Ingester로 복제한다.
replicate
Ingester in-memory chunk과 WAL을 유지하다가 flush 시점에 저장한다.
flush index and chunks
Object Store Index와 Chunks를 장기 저장한다.
Read Path
LogQL query Grafana 또는 API client가 tenant query를 보낸다.
split and cache
Query Frontend 긴 query를 분할하고 Results cache를 사용해 Querier 부하를 조절한다.
schedule
Querier Ingester의 최신 chunk와 Object Store의 Index/Chunks를 읽어 결과를 합친다.
return logs
Query result LogQL 결과를 Grafana 또는 호출한 client에 반환한다.
Memcaches: R, I, C Results, Index, Chunks 캐시. 위 Read Path의 Query Frontend와 Querier가 cache lookup과 cache result에 사용합니다.
Ruler 위 Ingester와 Object Store의 최신 chunk 및 장기 Index/Chunks를 읽어 alert rule을 평가하고 alert destination으로 결과를 전송합니다.
Compactor and Consul Compactor는 retention과 index 정리, Consul은 cluster coordination을 지원합니다.
Write와 Read를 독립적으로 확장할 수 있으며 Loki는 log body보다 label metadata를 중심으로 index한다.
Loki는 모듈형 시스템으로, 단일 바이너리(All-in-One)로도 실행할 수 있고, Read/Write/Backend 역할로 나누어 단순 확장형(Simple Scalable) 또는 마이크로서비스(Microservice) 형태로 구성할 수도 있습니다. 각 구성 요소에 대한 설명은 아래 표와 같습니다.
| 구성요소 | 역할 | 주요 기능/세부 설명 |
|---|---|---|
| Distributor | Write 경로의 첫 단계 | - 클라이언트로부터 로그 스트림을 수신 - Validation: 레이블 유효성, 타임스탬프 범위, 로그 길이 검증 - Preprocessing: 레이블 정렬(Caching 및 Hashing 최적화) - Rate Limiting: 테넌트별 전송 속도 제한 - Replication: 일관성 해시 기반 N개의 Ingester로 데이터 전송(기본 3) - 무상태(stateless) 구성으로 확장 용이 |
| Ingester | 데이터 수집,저장,전송 | - In-memory Chunk 생성 및 압축 - 주기적으로 **장기 저장소(S3/GCS/Azure Blob 등)**로 전송 - Write Ahead Log(WAL) 지원으로 비정상 종료 시 데이터 보존 - 상태(State): PENDING, JOINING, ACTIVE, LEAVING, UNHEALTHY- 중복 데이터 저장 방지(해시 기반) |
| Query Frontend | 읽기 성능 최적화 | - Querier API 엔드포인트 제공 - 대규모 Query Split & 병렬 실행 - FIFO 기반 Query 큐잉으로 테넌트별 공정성 보장 - 메트릭/로그 Query Caching(Memcached/Redis/In-memory) - 대규모 Query OOM 방지 |
| Query Scheduler | 고급 큐잉 처리 | - Query Frontend에서 분할된 Query를 테넌트별 큐에 저장 - Querier가 Pull 방식으로 작업 처리 - 고가용성을 위해 2개 이상의 복제 권장 |
| Querier | LogQL Query 실행 | - Ingester(메모리 데이터) + 장기 저장소 병합 조회 - 중복 로그 제거(동일 타임스탬프,레이블,메시지) - 직접 API 처리 가능(단일 실행 모드) |
| Index Gateway | 메타데이터 Query 처리 | - 인덱스 기반 메타데이터 조회 - Chunk 참조 반환 및 Query 샤딩 지원 - 단순 모드/Hash Ring 모드 운영 가능 |
| Compactor | 인덱스/로그 압축,보존 관리 | - 다중 인덱스 파일을 일 단위 단일 파일로 병합 - 인덱스 조회 효율성 향상 - 로그 보존(Deletion) 정책 적용 |
| Ruler | 룰 기반 알림 처리 | - LogQL 기반 룰/알림 평가 - Object Storage 또는 로컬 저장소 사용 가능 - Query Frontend를 통한 원격 룰 평가 모드 지원 |
| Bloom Planner / Builder / Gateway (실험 기능) | Bloom 필터 기반 검색 최적화 | - Planner: Bloom 생성 작업 계획 수립 - Builder: Bloom 블록 생성 및 메타데이터 관리 - Gateway: Bloom 기반 Chunk 필터링 - 대규모 환경에서 특정 레이블 검색 속도 향상 |
1.3. Grafana Loki Storage 구조
Loki는 모든 데이터를 Amazon S3, Google Cloud Storage(GCS), Azure Blob Storage 같은 단일 오브젝트 스토리지 백엔드에 저장합니다. Loki 2.0 이후 Index Shipper 모드를 기본으로 사용하며, 인덱스(Index) 파일과 청크(Chunk) 파일 모두를 동일 스토리지에 보관합니다.
주요 파일 타입
- Index: 특정 라벨 세트의 로그 위치를 가리키는 목차 역할
- Chunk: 특정 라벨 세트 + 시간 범위의 로그 라인 데이터 묶음 (압축 저장)
1.4. Grafana Loki Wirte Path
- Distributor가 HTTP POST(Log Stream)를 수신
- Consistent Hash Ring 기반으로 Ingester 노드 선택
- 데이터 복제(기본 3개 Ingester)
- Ingester가 In-memory Chunk에 데이터 추가
- 주기적으로 압축,저장소 전송
- 과반수(Quorum) Ingester 승인 시 클라이언트에 성공 응답
1.5. Read Path (읽기 경로)
- Query Frontend가 LogQL Query 수신
- Query를 하위 작업으로 분할해 Query Scheduler에 전달
- Querier가 Ingester 메모리 + Object Storage에서 데이터 조회
- 중복 제거 및 결과 병합
- 최종 응답 반환
2. Grafana Alloy란?
Grafana Alloy는 OpenTelemetry Collector를 기반으로 한 고성능, 유연한, 벤더 중립형(vendor-neutral) 수집기(Collector)로, 로그(Log), 메트릭(Metrics), 트레이스(Traces), 프로파일링(Profiling) 데이터를 단일 파이프라인에서 수집, 처리, 전송할 수 있도록 설계되었습니다. Promtail, Grafana Agent의 기능을 통합하면서도, 엔터프라이즈 환경에서의 확장성과 관리성까지 고려한 차세대 수집기입니다.
Applications and infrastructure
Application telemetry .NET, Java, Go 애플리케이션이 logs, metrics, traces, profiling 데이터를 보낸다.
Infrastructure signals Kubernetes, Kafka, Hubble 같은 인프라가 수집 대상이 된다.
telemetry 수집
Push telemetry
Client push SDK 또는 exporter가 Alloy endpoint로 telemetry를 전송한다.
Pull telemetry
Target scrape Alloy가 Prometheus target이나 Kubernetes endpoint를 주기적으로 읽는다.
Collect and Transform
Grafana Alloy 수집한 신호를 transform하고 pipeline 규칙에 따라 목적지별로 write한다.
route telemetry
Storage backends
Grafana Cloud 또는 신호별 backend metrics: Mimir / Prometheus, logs: Loki, traces: Tempo, profiles: Pyroscope
Optional downstream collectors
다른 Alloy / OpenTelemetry Collector 필요하면 중간 collector로 보내 추가 처리 후 호환 storage backend에 저장한다.
Alloy는 Collect, Transform, Write를 맡는 수집 계층입니다. 알림 규칙 평가는 downstream backend 또는 alerting system의 역할입니다.
2.1. Grafana Alloy의 특징
| 특징 | 설명 |
|---|---|
| All-in-One Observability Collector | 애플리케이션과 인프라 모두에 대한 모든 원격 측정 데이터(로그, 메트릭, 트레이스, 프로파일링) 수집 가능. |
| OpenTelemetry 호환 | OpenTelemetry, Prometheus, Loki, Pyroscope 등 오픈소스 표준과 완벽 호환. |
| 유연한 파이프라인 | 120개 이상의 컴포넌트를 조합해 데이터 수집 -> 변환 -> 전송 파이프라인 구성. |
| 엔터프라이즈 확장성 | 클러스터링 지원으로 워크로드 분산과 수평 확장 가능, Fleet Management로 다중 배포 관리. |
| GitOps 친화성 | Git, S3, HTTP 등에서 구성(Pipeline Config) 자동 가져오기 가능. |
| 보안 및 비밀 관리 | HashiCorp Vault, Kubernetes Secrets 연동 지원, 인증 정보 안전 관리. |
2.2. Grafana Alloy 주요 기능
| 기능 | 설명 |
|---|---|
| 사용자 정의 컴포넌트(Custom Components) | 여러 기존 컴포넌트를 하나의 컴포넌트로 묶어 간단히 재사용 가능. 커뮤니티 제공, Grafana 패키지 또는 직접 제작 가능. |
| 재사용 가능한 컴포넌트(Reusable Components) | 한 컴포넌트의 출력을 여러 다른 컴포넌트의 입력으로 활용 가능. |
| 컴포넌트 체이닝(Chained Components) | 컴포넌트를 순차적으로 연결해 파이프라인 구성 가능. |
| 단일 작업 컴포넌트(Single Task per Component) | 각 컴포넌트는 하나의 특정 작업에만 집중하도록 설계되어 가독성과 유지보수성 향상. |
| GitOps 호환성(GitOps Compatibility) | Git, S3, HTTP 등 다양한 소스에서 설정을 가져와 자동 반영 가능. |
| 클러스터링 지원(Clustering Support) | 클러스터링으로 워크로드를 분산하고 고가용성을 제공. 수평 확장 환경에 최적화. |
| 보안 기능(Security) | HashiCorp Vault, Kubernetes Secrets 연동을 통한 인증 정보와 비밀 안전 관리. |
| 디버깅 및 UI 지원(Debugging Utilities) | 설정 문제 해결을 위한 내장 UI 및 진단 기능 제공. |
2.3. Grafana Alloy 동작 방식 (OpenTelemetry Collector로서의 역할)
Grafana Alloy는 OpenTelemetry Collector 아키텍처를 기반으로 하며, Collect -> Transform -> Write 3단계로 동작합니다.
2.3.1. Collect
- 120개 이상의 컴포넌트를 활용해 애플리케이션, 데이터베이스, OpenTelemetry Collector 등 다양한 소스에서 원격 측정 데이터 수집.
- Pull 방식(데이터를 Alloy가 가져옴)과 Push 방식(데이터를 Alloy에 전송) 모두 지원.
- Prometheus, OpenTelemetry, Loki, Pyroscope 등 다양한 데이터 생태계와 호환.
2.3.2. Transform
- 수집된 데이터를 전송하기 전에 가공 및 필터링 가능.
- 예: 메타데이터 삽입, 불필요한 데이터 제거, 포맷 변환 등.
- 경량 필터링부터 복잡한 데이터 파이프라인까지 유연하게 구성 가능.
2.3.3. Write
- 가공된 데이터를 OpenTelemetry 호환 데이터베이스, Grafana 스택, Grafana Cloud 등으로 전송.
- 알림 규칙을 지원하는 데이터베이스에 직접 쓰기 가능.
- 장기 보관, 분석, 경보 시스템과 손쉽게 연계.
Tip: Grafana Alloy는 Promtail, Grafana Agent, OpenTelemetry Collector의 기능을 결합하면서도 엔터프라이즈 수준의 확장성과 관리성을 제공하므로, 단일 도구로 Observability 파이프라인을 단순화할 수 있습니다.
3. Reference
- grafana.com - latest
- grafana.com - latest
- grafana.com - overview
- grafana.com - architecture
- grafana.com - architecture
궁금하신 점이나 추가해야 할 부분은 댓글이나 아래의 링크를 통해 문의해주세요.
Written with KKamJi
This post is licensed under CC BY 4.0 by the author.