본문 바로가기

반응형

Observability

(4)
알림 설계: 노이즈를 줄이고 의미 있는 알림만 받는 방법 모니터링 도구를 도입하면 대부분 알림부터 설정합니다. CPU 80% 초과, 디스크 90% 초과, 5xx 에러 발생 — 하나씩 추가하다 보면 하루에 수십 건의 알림이 울립니다. 팀원들은 알림을 무시하기 시작하고, 정작 실제 장애 알림도 놓치게 됩니다. 이 글에서는 알림 피로(Alert Fatigue)를 줄이고, 사람이 대응해야 하는 상황에만 알림이 울리도록 설계하는 원칙을 정리합니다.핵심 요약알림은 "사람이 즉시 대응해야 하는 상황"에만 설정합니다. 정보성 알림은 대시보드로 대체합니다.원인(Cause)이 아닌 증상(Symptom)에 알림을 걸어야 커버리지가 높아집니다.심각도(Severity)를 명확히 분류하고, 각 심각도에 맞는 알림 채널과 대응 시간을 정의합니다.for 절(지속 시간)을 설정하여 일시적 ..
Prometheus + Grafana로 Kubernetes 모니터링 구성하기 Kubernetes 클러스터를 운영하는데 모니터링이 없다면, 장애가 발생했을 때 "어디서, 왜, 얼마나" 문제인지 알 수 없습니다. kubectl top으로는 현재 순간만 볼 수 있고, 과거 데이터도 없고, 알림도 없습니다. Prometheus + Grafana 스택은 이 문제를 해결하는 오픈소스 표준 조합입니다.핵심 요약Prometheus는 Pull 기반 메트릭 수집기이며, Grafana는 시각화 도구입니다. 이 조합은 Kubernetes 모니터링의 사실상 표준(de facto standard)입니다.kube-prometheus-stack Helm 차트를 사용하면 Prometheus, Grafana, Alertmanager, node-exporter, kube-state-metrics를 한 번에 배포할..
CloudWatch vs Datadog vs Grafana: 모니터링 도구 선택 기준 모니터링 도구를 선택할 때 "기능이 많은 것"이 정답은 아닙니다. AWS 단일 환경에서 EC2 10대를 운영하는 팀과, 멀티 클라우드에서 마이크로서비스 50개를 운영하는 팀이 같은 도구를 쓸 이유가 없습니다. 비용, 운영 부담, 확장성, 팀 역량을 기준으로 판단해야 합니다.요약기준CloudWatchDatadogGrafana + Prometheus유형AWS 매니지드SaaS 플랫폼오픈소스 자체 운영초기 설정거의 없음 (AWS 자동 연동)에이전트 설치 후 빠름직접 구축 필요운영 부담낮음낮음높음비용 (소규모)낮음중간낮음 (인프라 비용만)비용 (대규모)중간~높음높음낮음~중간멀티 클라우드어려움강점가능커스터마이징제한적중간높음추천 환경AWS 단일 환경, 소규모 팀멀티 클라우드, 빠른 도입 필요Kubernetes 중심,..
Observability란 무엇인가: Monitoring, Logging, Tracing의 차이 Observability는 시스템 외부에서 내부 상태를 추론할 수 있는 능력입니다. Monitoring은 "무엇이 문제인가", Logging은 "왜 문제인가", Tracing은 "어디서 느려지는가"에 답합니다. 이 세 가지를 조합해야 장애를 감지하고 원인을 추적할 수 있습니다.핵심 요약Observability는 Monitoring, Logging, Tracing 세 가지 축(Three Pillars)으로 구성됩니다.Monitoring은 메트릭 기반으로 시스템 상태를 수치화하고, 임계값 초과 시 알림을 발생시킵니다.Logging은 이벤트 단위로 상세 맥락을 기록하며, 장애 원인 분석(Root Cause Analysis)에 사용됩니다.Tracing은 분산 시스템에서 하나의 요청이 여러 서비스를 거치는 경로를..

반응형