Loki는 로그 집계 시스템
Grafana Labs에서 만들었고, Prometheus 스타일의 로그 시스템이다.
🔥 특징
- 메트릭 지향이 아니라 로그 지향
- 기존 로그 수집 시스템(ELK Stack: Elasticsearch, Logstash, Kibana)과 비교하면 리소스 사용량이 적음
- 인덱스 최소화 → 메타데이터(label)만 인덱싱하고, 실제 로그 내용은 그대로 저장
- Prometheus와 비슷한 라벨링 시스템 사용 → Prometheus 메트릭과 연계해서 사용하면 강력함
- 주로 Grafana에서 시각화하고 쿼리할 때 사용
🔧 아키텍처 구성
- Promtail → 로그를 수집해서 Loki에 전송하는 에이전트
- Loki → 로그 저장소 + 인덱싱 서버
- Grafana → Loki에서 수집된 로그를 조회하고 시각화
🚀 장점
- 설치, 운영이 쉬움
- 비용 저렴 (Elasticsearch처럼 고스펙 필요 없음)
- 메트릭 & 로그를 동일한 라벨로 연계 가능
⚠️ 단점
- 텍스트 기반 검색 성능이 Elasticsearch보다 떨어짐 (인덱스를 최소화했기 때문)
- 복잡한 검색/분석엔 한계가 있음
- Kibana 수준의 검색 UI는 아님 → 대부분 Grafana에서 조회
1️⃣ Loki의 전체 구조
[Application Logs] → [Promtail / Fluent Bit 등 에이전트] → [Loki] → [Grafana]
🔸 주요 구성 요소
구성 요소 |
역할 |
Promtail |
로그를 수집하고 Loki에 전송 (Filebeat 같은 역할) |
Loki |
로그를 저장, 인덱스는 최소한의 label만 관리 |
Grafana |
Loki에 저장된 로그를 조회, 시각화 |
2️⃣ 데이터 흐름 예시
예시 상황
- Pod 안에서 로그 발생
- Promtail이 로그 파일을 읽음 → 해당 로그에 다음과 같은 label을 붙임:
2025-04-02 10:21:33 INFO 요청 처리 성공 userId=123
2025-04-02 10:21:34 ERROR 데이터베이스 연결 실패
- Promtail → Loki로 전송
[
{
"timestamp": "2025-04-02 10:21:33",
"labels": {
"namespace": "prod",
"app": "my-service"
},
"line": "2025-04-02 10:21:33 INFO 요청 처리 성공 userId=123"
},
{
"timestamp": "2025-04-02 10:21:34",
"labels": {
"namespace": "prod",
"app": "my-service"
},
"line": "2025-04-02 10:21:34 ERROR 데이터베이스 연결 실패"
}
]
-
Grafana에서 쿼리 예를 들어, 이런 식으로 쿼리할 수 있음
{namespace="prod", app="my-service"} |= "ERROR"
→ 결과: 2025-04-02 10:21:34 ERROR 데이터베이스 연결 실패
3️⃣ Loki의 쿼리 방식
Loki는 LogQL이라는 쿼리 언어 사용.
예시
쿼리 |
의미 |
{app="my-service"} |
app이 my-service인 로그 모두 조회 |
`{app="my-service"} |
= "ERROR"` |
`{app="my-service"} |
~ "userId=[0-9]+"` |
sum by (level) (rate({app="my-service"}[5m])) |
5분 동안 발생한 로그 개수를 level별로 집계 |
4️⃣ Loki의 실제 사용 시 좋은 케이스
✅ Kubernetes 환경에서 메트릭과 로그를 동시에 보고 싶을 때
(에러 알람 → 해당 시간대 로그 바로 확인 가능)
✅ ELK처럼 무겁고 비싼 시스템 운영이 부담스러울 때
✅ 로그 양은 많지만 검색이 그렇게 복잡하진 않을 때
📌 정리
✅ 장점 |
❌ 단점 |
설치, 운영 쉬움 |
로그 내용 검색 속도 느림 (인덱스 최소화) |
비용 저렴 |
고급 검색 기능 약함 |
Prometheus와 연계 탁월 |
복잡한 검색은 비효율 |