Summary

• Observability 3요소 (메트릭/로그/트레이스) 중 메트릭/로그와 알림을 GKE 클러스터에 구성
• 메트릭: Prometheus+Grafana/ 로그: Loki+Fluent Bit / 알림: PrometheusRule
• 트레이스는 이후 8장에서 구성

Thoughts

• 기존 책들과 다른 설명 순서 > 추상화된 고수준 도구의 장점?
  • 기존 방식: 도구마다 제공 기능·아키텍처·동작 원리 숙지 > 설치 > 테스트
  • 이번 방식: 앞부분(비교, 원리 파악)을 LLM에게 요청해 간단히 훑고, 필요할 때만 파고들어 질문. 순서역전
  • 아 이건 아닌데 싶으면서도 아닐거는 뭐가있나 싶기도하고..
    • 직접 리서칭하고 헤매는 과정에서 몰랐던/추가로 알게된 정보들을 알지 못하게됨
    • 질문을 잘한다면 이전과 동일한 or 그 이상의 효과를 얻을 수 있다
    • 저자분이 말씀하신 이 책은 질문하기에 관한 책이다 라는게 그런의미인가 싶음
  • 어쨌든 프로메테우스 관한 강의/교재에서 아키텍처 그림이 없어서 신기함

---

4장. 관측 가능성 한 번에 구축하기

• 3장을 통해 코드 푸시부터 빌드 / 배포 자동화 까지 구성
• 서비스 상태 확인을 위한 시스템 부재, CPU/Mem 등 에러 원인과 상황 확인 어려움 (재시작 시 로그 사라짐)

4.1 관측 가능성이란

• 관측 가능성(Observability)는 메트릭, 로그, 트레이스 3요소로 이루어짐
  • 메트릭(metrics): 숫자. CPU 사용률 90%, 초당 요청 500개, 에러율 2% 와 같이 서비스 상태 파악
  • 로그(logs): 텍스트, connection refused at line 42, timeout after 30s 와 같이 에러 원인 파악
  • 트레이스(traces): 흐름, 일련의 요청과정이 어떤 서비스를 거치는지, 병목지점이 어디인지 추적
• 4장에서는 메트릭+로그만 구성하고 알림을 설정함. 트레이스는 서비스간 호출이 생기는 8장에서 추가

4.2 메트릭 모니터링: 프로메테우스 + 그라파나

• 클러스터 현황 파악을 위한 메트릭 데이터 수집 및 시각화

4.2.1 클로드 코드에게 메트릭 수집과 시각화 도구 물어보기

• cc에게 자연어로 클러스터에서 뭐가돌아가는지 어떻게 파악할 수 있어? 질문
  • Prometheus+Grafana 조합 추천

4.2.2 다른 도구는 없는지 비교해보기

• cc에게 자연어로 다른 모니터링 도구들과 비교해줘 질문
• 다른 Datadog, Google Cloud Monitoring, AWS Cloudwatch(?) 대비 비용, 커스텀 등에서 장점

4.2.3 프로메테우스 + 그라파나 설치하기

• cc에게 자연어로 프로메테우스+그라파나 구성해줘 요청
  • Helm kube-prometheus-stack 차트 기반 구성

4.2.4 그라파나에 접속하기

• 구성 이후, cc에게 자연어로 그라파나 화면 접근 방법 질문
  • 로컬머신의 3000포트로 포트포워딩하여 접근 가능, metric 수집 및 조회 가능

4.2.5 프로메테우스 메트릭 확인하기

• cc에게 자연어로 프로메테우스 데이터 수집 동작 확인 방법 질문
  • 16/18개 타겟 동작중 (GKE 특성상 coreDNS down)

4.3 로그 수집: Loki + Fluent Bit

• 메트릭은 ‘무엇이 잘못되었는지’ 파악 가능, 로그는 ‘왜 잘못되었는지’ 파악 가능, 로그 수집 체계 구축

4.3.1 클로드 코드에게 로그 수집 도구 물어보기

• cc에게 자연어로 Pod의 로그를 어떻게 모아서 조회할 수 있어? 질문
  • Loki + Fluent Bit 조합 추천

4.3.2 다른 도구는 없는지 비교해보기

• cc에게 자연어로 다른 로깅 도구들과 비교해줘 질문
  • Loki+Fluent Bit / ELK / Google Cloud Logging / Datadog / Opensearch 등

4.3.3 Loki + Fluent Bit 설치하기

• cc에게 자연어로 loki+Fluent Bit 구성해줘 요청
  • helm chart 기반 loki(single binary)+fluentbit(ds) 구성

4.3.4 그라파나에서 로그 확인하기

• cc에게 자연어로 로그 수집 동작 확인 방법 질문

4.4 알림 설정: PrometheusRule

• 메트릭/로그를 상시 확인 할 수 없기에 장애시 자동 알림 설정 필요

4.4.1 클로드 코드에게 알림 도구 물어보기

• cc에게 자연어로 장애시 알림 구성을 위한 도구 추천 질문
  • PrometheusRule + Alertmanager 권장

4.4.2 다른 방식은 없는지 비교해보기

• cc에게 자연어로 다른 알림 도구와의 비교 질문
  • Grafana 기반 알림, Pager duty류(인시던트 관리), Google Cloud Monitoring Alert, 등 추천

4.4.3 알림 규칙 만들기

• cc에게 자연어로 알림 구성해줘 요청
  • pod ready/restart/CPU usage 알람 및 kube-prometheus-stack 기본 규칙들

4.4.4 알림 규칙 확인하기

• cc에게 자연어로 구성된 알림의 동작 확인 방법 요청
  • CrashLoopBackOff 일으키는 Deployment 생성하여 PodRestartTooMany trigger

4.5 마무리: 메모리에 작업 컨텍스트 기록

• Claude Code의 두가지 기억 메커니즘
  • CLAUDE.md: 프로젝트 루트에서, 세션 시작시 로드되어 항상 참조
  • memory: 사용자의 홈디렉토리에, 사용자 선호/작업패턴/결정 기록을 남겨 필요시 참조
    • 다양한 항목을 메모리에 구성 하여 활용 가능
      • TODO: 분산트레이싱(Tempo)는 서비스간 호출이 발생하는 8장에서 사용
      • 사용자 선호: kubectl apply 직접 적용 보다 헬름 차트 선호
      • 작업 패턴: Pod requests 결정 시 resource-budget.md를 참조 우선순위 할당
      • 금지 사항: 이미지 태그 :latest 금지, 명시적 sha 또는 semantic version 사용
  • CLAUDE.md에 모든 내용을 지시하면 컨텍스트가 길어져 부담, Memory 활용시 인덱스(MEMORY.md)에 따라 필요한 개별 토픽을 읽어 세션 부담 완화

• cc 내부에서 다음 TODO내용을 메모리에 등록
  • PrometheusRule 임계값은 일단 5분/3회로 뒀는데, 운영 데이터를 보고 조정해야 해. 메모리에 TODO로 적어 둬.

• 두 매커니즘 모두 작업자의 로컬에만 남아있어 협업시 전파 안됨, 결정의 영구 기록은 git 활용이 바람직
  • 작업레포인 notiflex-platform 레포지토리에서 /update-docs 실행

4.6 4장 가드레일 살펴보기

• 4장 진행에 있어, 모니터링/로깅/알람 도구에 대해 탐색>비교>실행의 절차가 실행, 연관 가드레일 사용

서브챕터	유형	참조 파일	역할
4.2 탐색/비교	탐색과 비교	decision-guides/ch4/4.2-metrics-monitoring.md	Prometheus 추천 + 대안 비교
4.2 실행	실행	prompt-guardrails/ch4/4.2-prometheus-grafana.md	kube-prometheus-stack 설치
4.3 탐색/비교	탐색과 비교	decision-guides/ch4/4.3-logging.md	Loki 추천 + ELK 비교
4.3 실행	실행	prompt-guardrails/ch4/4.3-loki-fluentbit.md	Loki + Fluent Bit 설치
4.4 탐색/비교	탐색과 비교	decision-guides/ch4/4.4-alerting.md	PrometheusRule 추천 + 비교
4.4 실행	실행	prompt-guardrails/ch4/4.4-alerting.md	PrometheusRule 작성