2주 차에는 이론보다 실습을 위주로 진행됐다.
실습을 진행하니 어떻게 동작하는지 더 이해하기 쉽다는 느낌을 받았지만 아직 기본적인 지식이 부족하다는 것을 많이 느끼고 있기에 기초를 잘 쌓는 공부를 진행해야 할 것 같기에 기본 개념과 실습에 사용된 기초 내용을 정리해 보았다.
🖥️모니터링을 왜 해야하는가?
서비스가 단순한 테스트나 개인 프로젝트가 아니라 다수의 사용자, 실시간 서비스, 배포 환경에서 돌아가기 시작하면
"오류 나면 고치자"가 아니라
👉 문제 생기기 전에 알자,
👉 성능이 저하되면 원인을 추적하자 라는 모니터링 개념이 중요해진다.
그럼 이제 모니터링 즉, 관측(Observability)에 대해 알아보자.
🧠 이론적 배경: Observability란?
✅ 관측(Observability)의 개념
Observability(관측 가능성)는 시스템 내부 상태를 외부에서 관찰 가능한 출력을 통해 추론할 수 있는 능력을 의미합니다.
관측의 3대 핵심 요소는 다음과 같다.
[요소설명]
로그 (Logs) | 애플리케이션 동작 중 발생하는 이벤트 기록. 주로 텍스트 기반이며, 문제 발생 시 원인을 추적하는 데 유용 |
메트릭 (Metrics) | 수치 기반 성능 데이터. 예: CPU 사용률, 메모리 사용률, 지연 시간 등 |
트레이스 (Traces) | 시스템에서의 요청 흐름 추적. A → B → C 서비스 호출 관계 파악 |
⚙️ 구성 요소 개요
Grafana + Loki 스택을 이용한 모니터링 시스템은 다음과 같은 구성 요소로 이루어져 있다.
각각의 요소는 로그 또는 메트릭 수집, 저장, 시각화를 담당한다.
구성 요소 | 역할 및 이론적 의미 |
FastAPI | 로그와 메트릭을 생성하는 실제 애플리케이션. /metrics 엔드포인트 제공 |
Nginx | 리버스 프록시 서버. 클라이언트 요청을 내부 서비스로 안전하게 중계 |
Promtail | 로그 수집기. 로그 파일을 읽고, 라벨을 붙여 Loki로 Push |
Loki | 로그 저장소. Prometheus 스타일 쿼리를 사용한 로그 조회 가능 |
Prometheus | 메트릭 수집기. /metrics 경로를 주기적으로 Pull 방식으로 수집 |
Grafana | 시각화 도구. 메트릭(PromQL)과 로그(LogQL)를 통합 조회 가능 |
🔧 핵심 설정 요약
Promtail (promtail-config.yaml)
- __path__: 로그 파일 경로
- regex: 로그 파싱을 위한 정규표현식
- labels: 쿼리 필터용 라벨 추가
Loki (loki-config.yaml)
- 로그 저장소 위치 및 인덱싱 전략 지정 (boltdb + filesystem)
- chunk 단위 저장으로 효율적인 조회와 압축 수행
- 자체 메트릭 제공 (Prometheus로 수집 가능)
Prometheus (prometheus.yml)
- scrape_configs로 대상 서비스(FastAPI 등) 정의
- job_name 기준으로 메트릭 필터링 가능
Grafana
- Data source로 Loki, Prometheus 모두 등록
- LogQL, PromQL로 쿼리 생성 후 대시보드 구성
위에서 로그와 메트릭에 대해 간단히 알아보았지만 개인적으로는 로그와 메트릭이 헷갈리는 개념이었다. 로그와 메트릭이 언제 어떻게 생성되는 것인지, 사용할 때 어떻게 사용하는지 등이 헷갈렸기에 아래 개념 등을 적어보았다.
📄 이론과 함께 보는 로그 수집 흐름
📌 로그란?
- 사람이 읽기 쉬운 텍스트 기반 기록 (ex. 오류 메시지, 상태 변화, 요청 정보)
- 문제 발생 시 디버깅, 추적용으로 매우 중요
📌 로그 수집 방식: Push 기반
- 로그 파일(app.log, access.log 등)을 Promtail이 감시
- 라벨을 붙이고, 정규표현식으로 가공해 Loki로 Push 전송
- Loki는 시간, 라벨 기준으로 저장
- Grafana에서는 LogQL로 검색/시각화
📈 이론과 함께 보는 메트릭 수집 흐름
📌 메트릭이란?
- 수치 기반 성능 데이터 (ex. CPU 사용률, 요청 수, 처리 시간)
- 경향성 분석, 성능 모니터링, Alert 조건 설정에 사용됨
📌 메트릭 수집 방식: Pull 기반
- FastAPI는 /metrics 경로에서 Prometheus client 데이터를 노출
- Prometheus가 주기적으로 해당 경로를 Polling 하여 수집
- 수집된 시계열 데이터는 Prometheus TSDB에 저장됨
- Grafana에서는 PromQL로 시각화/경고 설정 가능
🧠 실습을 통해 배운 점
개념 | 실전 의미 |
로그와 메트릭의 차이 | 로그는 이벤트 추적용, 메트릭은 수치 기반 경향 분석용 |
Push vs Pull | 로그는 Promtail이 Push, 메트릭은 Prometheus가 Pull |
라벨의 중요성 | 필터링, 분석, 대시보드 구성의 핵심 요소 |
Docker Compose | 여러 컨테이너를 한 번에 실행하고 연결해주는 오케스트레이터 |
📁 디렉토리 구조 및 역할
project-root/
├── docker-compose.yml # 전체 스택 정의
├── fastapi/ # FastAPI 애플리케이션
│ ├── main.py
│ ├── Dockerfile
│ └── requirements.txt
├── nginx.conf # Nginx 설정 파일
├── promtail-config.yaml # 로그 수집 설정
├── loki-config.yaml # 로그 저장 설정
├── prometheus/prometheus.yml # 메트릭 수집 설정
├── grafana-data/ # Grafana 데이터 볼륨
├── fastapi-logs/, nginx-logs/ # 로그 저장 디렉토리
📝 추가 정리: 실습하며 이해한 개념 질문 정리
🔹 Promtail이 메트릭을 제공한다고 했던 이유는?
- Promtail은 자체적으로 /metrics 엔드포인트를 제공하며, Prometheus가 이를 스크랩하여 Promtail의 내부 상태(예: 수집한 로그 수, 전송 상태 등)를 모니터링할 수 있다.
- 하지만 Promtail은 메트릭 수집기가 아니라 로그를 Loki로 전송하는 수단이다.
🔹 Loki는 로그 저장소이지만 파일인가?
- Loki는 전통적인 텍스트 파일 저장 방식이 아닌, 자체 데이터베이스(boltdb + chunk 파일 시스템)를 이용한 시계열 로그 저장소이다.
- 로그는 Promtail이 Push 하고, Loki는 이를 시계열 인덱스로 정리하여 조회 가능하게 만든다.
🔹 메트릭은 언제 생성되나?
- FastAPI 같은 서비스가 /metrics 엔드포인트를 통해 Prometheus 클라이언트 메트릭을 노출하면 자동으로 생성된다.
- Prometheus가 이 엔드포인트를 주기적으로 조회해 수집하지 않으면 생성되더라도 저장되진 않는다.
🔹 로그와 메트릭은 항상 함께 생성되나?
- 아니다.
- 로그는 코드 내 logger 사용이나 시스템 동작 중 명시적으로 출력되는 문자열이다.
- 메트릭은 별도로 Prometheus client를 통해 정의된 변수와 수치가 있어야 생성된다.
🔹 Promtail의 scrape_configs는 메트릭용인가?
- 아니다.
- Promtail의 scrape_configs는 어떤 로그 파일을 수집할지 지정하는 설정이다.
- Prometheus의 scrape_configs와 다르게 로그 수집과 가공(Pipeline stages 포함)을 설정한다.
🔹 Prometheus가 없으면 메트릭은 저장이 안 되는가?
- 맞다.
- /metrics 엔드포인트에서 메트릭은 노출되더라도 Prometheus가 없으면 이를 가져가서 저장하는 주체가 없기 때문에 단순히 출력만 되고 저장되지 않는다.
🔹 로그는 왜 Loki로 Push 하는가?
- Loki는 Pull 방식이 아니라 Promtail이 Push로 전송하는 방식을 채택했기 때문이다.
- 로그는 파일에서 수시로 기록되기 때문에 이벤트 기반으로 Push 하는 게 효율적이다.
🔹 Grafana에서 보는 화면은 실시간인가?
- Grafana의 대시보드는 지정된 시간 간격으로 자동 새로고침(Polling) 되며, 완전한 실시간은 아니지만 거의 실시간에 가깝다.
본 후기는 [카카오엔터프라이즈 x스나이퍼팩토리] 카카오클라우드로 배우는 AIaaS 마스터 클래스 (B-log) 리뷰로 작성되었습니다.