모니터링 파이프라인 분석

📑 목차

파이프라인 개념
3단계 구조
구성요소 분석
로그와의 비교

1. 파이프라인 개념 완전 정복

파이프라인의 핵심

순차적으로 일어나는 일들의 연결. 작업 n의 결과가 → 작업 n+1의 입력이 되는 구조

💡 가장 쉬운 예시: 리눅스 파이프

📋 리눅스 명령어 분해

ps aux | grep systemd

흐름 분해:

1단계: ps aux 실행
  → 입력: 없음
  → 처리: 현재 실행 중인 모든 프로세스 조회
  → 출력: "프로세스 목록 (수백 줄의 텍스트)"
 
2단계: | (파이프)
  → 역할: 1단계 출력을 다음 명령어로 전달
  → 핵심: 데이터 연결고리
 
3단계: grep systemd
  → 입력: 1단계에서 받은 프로세스 목록
  → 처리: "systemd" 포함된 줄만 필터링
  → 출력: "systemd 관련 프로세스만 표시"

파이프라인 원리:

ps aux → [모든 프로세스] → grep systemd → [systemd만]

🏭 실생활 비유: 자동차 생산라인

📊 자동차 공장 vs 파이프라인

자동차 생산 파이프라인:
  1단계: 차체 제작
    → 입력: 철판, 설계도
    → 출력: 기본 차체
 
  2단계: 엔진 조립 (1단계 결과 받아서)
    → 입력: 기본 차체 + 엔진 부품
    → 출력: 엔진 장착된 차체
 
  3단계: 내외장 작업 (2단계 결과 받아서)
    → 입력: 엔진 장착된 차체 + 내장재
    → 출력: 완성된 자동차
 
  4단계: 품질 검사 (3단계 결과 받아서)
    → 입력: 완성된 자동차
    → 출력: 검증된 출고 차량

핵심 특징:

각 단계는 순서대로 진행
앞 단계 완료되어야 다음 단계 시작
각 단계의 출력 = 다음 단계의 입력

💻 개발 환경 예시: CI/CD 파이프라인

📋 GitHub Actions 파이프라인

개발자 코드 작성
  ↓ (Push)
GitHub Repository (작업 1)
  ↓ (코드 변경 감지)
자동 빌드 (작업 2)
  → 입력: 소스코드
  → 처리: npm install, npm build
  → 출력: 빌드된 애플리케이션
  ↓
자동 테스트 (작업 3)
  → 입력: 빌드된 애플리케이션
  → 처리: jest 테스트 실행
  → 출력: 테스트 통과/실패 결과
  ↓
자동 배포 (작업 4)
  → 입력: 테스트 통과한 애플리케이션
  → 처리: Docker 이미지 생성, K8s 배포
  → 출력: 운영 서버에 배포된 서비스

실패 시 중단:

테스트 실패 → 파이프라인 중단 → 배포 안됨 (의도된 동작)

2. 모니터링 파이프라인 3단계

모니터링 파이프라인의 목적

시스템 상태 데이터를 수집 → 저장 → 시각화하여 관리자가 볼 수 있게 만드는 것

🎯 전체 구조 한눈에 보기

[1단계: 메트릭 수집] → [2단계: 통합 및 저장] → [3단계: 시각화]
        ↓                    ↓                   ↓
    각 서버에서            Prometheus가          Grafana에서
   데이터 노출            데이터 수집/저장        예쁜 그래프로 변환

📊 단계별 상세 분석

1단계: 메트릭 수집 (Data Exposure)

역할: 각 서버/애플리케이션이 자신의 상태 정보를 외부에서 읽을 수 있도록 노출
 
쿠버네티스 클러스터 내부:
  마스터 노드:
    - /metrics 엔드포인트 제공
    - API 서버 상태, etcd 상태 등
    
  워커 노드 1, 2, 3:
    - node-exporter: OS 메트릭 수집기 실행
    - /metrics 엔드포인트 제공 (포트 9100)
    - CPU, 메모리, 디스크, 네트워크 상태
    
  kube-state-metrics:
    - 쿠버네티스 자체 상태 메트릭
    - Pod 상태, Deployment 상태 등
 
출력 형태: HTTP 엔드포인트로 메트릭 데이터 노출
예시: http://worker1:9100/metrics

2단계: 통합 및 저장 (Data Collection & Storage)

역할: 흩어진 메트릭들을 한곳으로 모아서 시간별로 저장
 
Prometheus Server:
  1. 스케줄링: 설정된 간격(기본 15초)마다 실행
  2. 스크레이핑: 각 /metrics 엔드포인트 방문
     - GET http://master:8080/metrics
     - GET http://worker1:9100/metrics  
     - GET http://worker2:9100/metrics
     - GET http://worker3:9100/metrics
  3. 파싱: 받은 데이터를 구조화
  4. 저장: 시계열 DB에 타임스탬프와 함께 저장
 
Alertmanager (선택사항):
  - Prometheus에서 설정한 임계치 넘으면
  - Slack, 이메일, SMS 등으로 알람 발송
 
출력 형태: 시계열 데이터베이스에 저장된 메트릭

3단계: 시각화 (Data Visualization)

역할: 저장된 데이터를 사람이 이해하기 쉬운 그래프/대시보드로 변환
 
Prometheus Web UI:
  - 간단한 쿼리 테스트
  - 개발자용 디버깅 도구
  - PromQL 쿼리 실행 및 결과 확인
 
Grafana Dashboard:
  - 예쁜 대시보드 생성
  - 경영진/운영팀용 보고서
  - 실시간 모니터링 화면
  - 드릴다운, 필터링 등 고급 기능
 
출력 형태: 웹 브라우저에서 볼 수 있는 대시보드

3. 각 구성요소 상세 분석

💡 Node-exporter 심화 이해

Node-exporter 역할

리눅스 OS 메트릭을 Prometheus 형식으로 변환하는 통역사

📋 동작 원리

1. OS 시스템 정보 수집:
   - /proc/stat (CPU 정보)
   - /proc/meminfo (메모리 정보)  
   - /proc/diskstats (디스크 정보)
   - /proc/net/dev (네트워크 정보)
 
2. Prometheus 형식으로 변환:
   입력 (리눅스): "Mem: 4194304 kB total, 2097152 kB used"
   출력 (Prometheus): node_memory_MemTotal_bytes 4294967296
 
3. HTTP 서버로 제공:
   - 포트 9100에서 HTTP 서버 실행
   - GET /metrics 요청 시 변환된 데이터 반환

💻 /metrics 엔드포인트 예시

# curl http://worker1:9100/metrics
node_cpu_seconds_total{cpu="0",mode="idle"} 1234567.89
node_cpu_seconds_total{cpu="0",mode="system"} 12345.67
node_memory_MemTotal_bytes 8589934592
node_filesystem_size_bytes{device="/dev/sda1",fstype="ext4"} 21474836480

🏗️ kube-state-metrics 심화 이해

kube-state-metrics 역할

쿠버네티스 API에서 클러스터 상태 정보를 메트릭으로 변환

📊 수집 대상

Pod 메트릭:
  - kube_pod_status_phase: Pod가 Running/Pending/Failed 상태인지
  - kube_pod_container_restarts_total: 컨테이너 재시작 횟수
 
Deployment 메트릭:
  - kube_deployment_status_replicas: 설정된 레플리카 수
  - kube_deployment_status_replicas_ready: 준비된 레플리카 수
 
Node 메트릭:
  - kube_node_status_condition: Node가 Ready 상태인지
  - kube_node_info: Node 정보 (OS, 버전 등)
 
Service 메트릭:
  - kube_service_info: Service 정보
  - kube_service_spec_ports: Service 포트 정보

🎯 Prometheus Server 심화 이해

📋 스크레이핑 프로세스

1. 설정 로드:
   prometheus.yml 파일에서 타겟 목록 읽기
   
2. Service Discovery:
   쿠버네티스 API 통해 새로운 Pod 자동 발견
   
3. 스크레이핑 스케줄링:
   scrape_interval: 15s (기본값)
   각 타겟별로 독립적 스케줄 관리
   
4. HTTP 요청:
   GET /metrics HTTP/1.1
   Host: target-server:port
   
5. 응답 파싱:
   메트릭 이름, 라벨, 값 추출
   
6. 시계열 저장:
   {metric_name{labels} value timestamp}

💻 시계열 저장 구조

시계열 데이터 구조:
  메트릭명: cpu_usage
  라벨: {server="web1", cpu="0"}
  시계열:
    1701504000 → 75.5
    1701504015 → 78.2
    1701504030 → 82.1
    1701504045 → 79.8
 
실제 저장 형태:
cpu_usage{server="web1",cpu="0"} 75.5 @1701504000
cpu_usage{server="web1",cpu="0"} 78.2 @1701504015
cpu_usage{server="web1",cpu="0"} 82.1 @1701504030

📊 Alertmanager 심화 이해

Alertmanager 역할

Prometheus에서 발생한 알람을 적절한 채널로 전송하는 라우터

📋 알람 처리 과정

1. 알람 규칙 평가:
   Prometheus가 주기적으로 알람 규칙 확인
   예: cpu_usage > 80%
 
2. 알람 발생:
   조건 만족 시 Alertmanager로 알람 전송
   
3. 그룹핑:
   유사한 알람들을 묶어서 처리
   예: 같은 서버에서 발생한 여러 알람
 
4. 라우팅:
   알람 종류에 따라 적절한 채널 선택
   CPU 알람 → Slack #dev
   디스크 알람 → Email + SMS
 
5. 전송:
   설정된 채널로 알람 메시지 발송

4. 로그 파이프라인과의 비교

💡 메트릭 vs 로그 파이프라인

근본적 차이

메트릭: “지금 상태가 어때?” (숫자)
로그: “무슨 일이 있었어?” (텍스트)

📊 상세 비교표

구분	메트릭 파이프라인	로그 파이프라인
데이터 형식	숫자 (CPU 80%)	텍스트 (ERROR: DB 연결 실패)
저장소	Prometheus (시계열 DB)	Elasticsearch (검색 엔진)
수집기	node-exporter	Fluentd/Logstash
전송 방식	Pull (Prometheus가 가져감)	Push (로그를 보냄)
쿼리 언어	PromQL	Lucene Query
시각화	Grafana	Kibana
용도	실시간 모니터링, 알람	디버깅, 감사, 분석
데이터 크기	작음 (KB)	큰 편 (MB)

🔧 로그 파이프라인 구조

📋 ELK Stack 파이프라인

[1단계: 로그 생성]
각 워커 노드의 애플리케이션:
  → 로그 파일 생성
  → 예시: 2024-12-02 10:00:01 ERROR Connection timeout
 
[2단계: 로그 수집 및 가공]  
Fluentd (각 노드에 DaemonSet으로 설치):
  → 로그 파일 읽기
  → 파싱 및 구조화
  → Elasticsearch로 전송
 
[3단계: 저장 및 인덱싱]
Elasticsearch:
  → 로그를 검색 가능한 형태로 저장
  → 전문 검색 인덱스 생성
 
[4단계: 검색 및 시각화]
Kibana:
  → 로그 검색 및 필터링
  → 로그 기반 대시보드
  → 패턴 분석 및 알람

🎯 언제 무엇을 사용할까?

📋 상황별 도구 선택

실시간 시스템 상태 확인:
  → 메트릭 파이프라인 (Prometheus + Grafana)
  예시: "지금 서버 CPU 사용률이 얼마야?"
 
장애 원인 분석:
  → 로그 파이프라인 (ELK Stack)
  예시: "15분 전에 왜 에러가 발생했지?"
 
성능 튜닝:
  → 메트릭 파이프라인
  예시: "최근 1주간 응답시간 추이는?"
 
보안 감사:
  → 로그 파이프라인
  예시: "누가 언제 관리자 권한으로 로그인했지?"
 
비즈니스 분석:
  → 둘 다 사용
  메트릭: 실시간 매출, 사용자 수
  로그: 사용자 행동 패턴, 에러 추적

🔗 통합 모니터링 스택

💻 실무에서의 조합

완전한 모니터링 환경:
  
메트릭 (숫자 데이터):
  - Prometheus: 수집 및 저장
  - Grafana: 시각화
  - Alertmanager: 알람
 
로그 (텍스트 데이터):  
  - Fluentd: 수집
  - Elasticsearch: 저장
  - Kibana: 시각화
 
분산 추적 (트레이싱):
  - Jaeger: 마이크로서비스 호출 추적
  - OpenTelemetry: 표준 계측
 
통합 계층:
  - OpenTelemetry Collector: 모든 종류 데이터 통합 수집
  - Grafana: 메트릭 + 로그 + 트레이스 통합 대시보드

🎯 핵심 포인트 정리

✅ 파이프라인 이해 체크리스트

1. 파이프라인 개념

[ ] 파이프라인은 순차적 작업의 연결이다
[ ] 각 단계의 출력이 다음 단계의 입력이 된다
[ ] 리눅스 파이프(|)가 가장 기본적인 예시다
[ ] CI/CD도 파이프라인의 일종이다

2. 모니터링 파이프라인 3단계

[ ] 1단계: 수집 - 각 서버가 /metrics로 데이터 노출
[ ] 2단계: 통합 - Prometheus가 스크레이핑하여 저장
[ ] 3단계: 시각화 - Grafana가 대시보드로 변환

3. 주요 구성요소 역할

[ ] node-exporter: OS 메트릭 → Prometheus 형식 변환
[ ] kube-state-metrics: K8s 상태 → 메트릭 변환
[ ] Prometheus: 중앙 수집 서버 + 시계열 DB
[ ] Alertmanager: 임계치 초과 시 알람 발송
[ ] Grafana: 예쁜 대시보드 생성

4. 메트릭 vs 로그

[ ] 메트릭: 현재 상태 (숫자) → 실시간 모니터링
[ ] 로그: 발생 사건 (텍스트) → 사후 분석
[ ] Prometheus vs Elasticsearch
[ ] Grafana vs Kibana

🔗 다음 학습 연결고리

다음 단계 예상

도구 비교: 왜 DataDog, Zabbix가 아닌 Prometheus인가?

실습 준비: Vagrant 환경에서 직접 구축해보기

고급 설정: PromQL 쿼리 작성, 알람 규칙 설정

📚 관련 문서

01_프로메테우스_기초_개념_완벽_정리 - 기초 개념 복습
03_프로메테우스_vs_다른_도구_비교 - 도구 선택 근거
04_실습_준비_가이드 - 실제 환경 구축 준비

파이프라인을 이해하면 복잡한 모니터링 시스템도 단순하게 보입니다! 🔧

Quartz 4

탐색기

02_모니터링 파이프라인 분석

모니터링 파이프라인 분석

📑 목차

1. 파이프라인 개념 완전 정복

💡 가장 쉬운 예시: 리눅스 파이프

📋 리눅스 명령어 분해

🏭 실생활 비유: 자동차 생산라인

📊 자동차 공장 vs 파이프라인

💻 개발 환경 예시: CI/CD 파이프라인

📋 GitHub Actions 파이프라인

2. 모니터링 파이프라인 3단계

🎯 전체 구조 한눈에 보기

📊 단계별 상세 분석

1단계: 메트릭 수집 (Data Exposure)

2단계: 통합 및 저장 (Data Collection & Storage)

3단계: 시각화 (Data Visualization)

3. 각 구성요소 상세 분석

💡 Node-exporter 심화 이해

📋 동작 원리

💻 /metrics 엔드포인트 예시

🏗️ kube-state-metrics 심화 이해

📊 수집 대상

🎯 Prometheus Server 심화 이해

📋 스크레이핑 프로세스

💻 시계열 저장 구조

📊 Alertmanager 심화 이해

📋 알람 처리 과정

4. 로그 파이프라인과의 비교

💡 메트릭 vs 로그 파이프라인

📊 상세 비교표

🔧 로그 파이프라인 구조

📋 ELK Stack 파이프라인

🎯 언제 무엇을 사용할까?

📋 상황별 도구 선택

🔗 통합 모니터링 스택

💻 실무에서의 조합

🎯 핵심 포인트 정리

✅ 파이프라인 이해 체크리스트

🔗 다음 학습 연결고리

📚 관련 문서

그래프 뷰

목차

백링크