8. 관측 — 온프렘에서 무엇이 걸리나

관측 스택의 목적은 대시보드가 아니다 — “지금 뭐가 문제냐”에서 원인까지 가는 시간을 줄이는 것이다

이 장에서 처음 나오는 말6개

관측 가능성Observability

시스템 밖에서 나오는 신호만 보고 안에서 무슨 일이 벌어지는지 알아낼 수 있는 성질. "모니터링"이 정해 둔 것을 지켜보는 일이라면, 이쪽은 묻지 않았던 질문에도 답할 수 있는가를 본다.

메트릭 · 로그 · 트레이스Metrics · Logs · Traces

관측의 세 신호. 각각 얼마나 · 무슨 일이 · 어디서 느렸나에 답한다.

카디널리티Cardinality

라벨 조합의 가짓수. 관측 스택을 죽이는 1번 원인이다 — 사용자 ID처럼 값이 무한한 것을 라벨에 넣으면 시계열이 폭발한다.

Grafana Alloy

Grafana Labs의 OpenTelemetry 컬렉터 배포판. 로그·메트릭·트레이스를 한 에이전트로 모은다. Promtail은 EOL이라 이쪽이 답이다.

dead man 스위치Dead Man's Switch

정상일 때 주기적으로 울리는 신호. 그게 멈추면 "알림 경로가 죽었다"를 밖에서 알아챈다. 관측 스택 자신을 감시하는 거의 유일한 방법이다.

실패 도메인Failure Domain

함께 죽는 범위. 감시자와 감시 대상이 같은 실패 도메인에 있으면 정작 필요한 순간에 둘 다 없다.

이 장의 범위

도구 넷의 설치·설정·질의·운영은 관측 덱이 맡는다. 이 장은 그 스택을 온프렘에 놓을 때 걸리는 것 — 어느 자리를 채우고, 상태가 어느 바닥에 떨어지고, 어디에 배치하고, 용량을 어떻게 정하나 — 까지만 쓴다.

문제 — kubectl logs로는 안 된다

클러스터에 서비스가 몇 개만 넘어가도 이런 일이 벌어진다.

상황	kubectl 만으로	클라우드에서는
“어제 새벽에 느렸다는데요”	파드가 재시작됐으면 로그가 없다	CloudWatch Logs에 남아 있다
“어느 서비스가 문제죠?”	파드를 하나씩 열어 본다	콘솔에서 한 번에 검색
“언제부터 이랬죠?”	알 수 없다 — 지난 값이 없다	CloudWatch Metrics의 그래프
“이 API가 왜 3초씩 걸리죠?”	어느 구간에서 걸리는지 안 보인다	X-Ray
“디스크 언제 찹니까”	지금 값만 보인다. 추세가 없다	콘솔이 알려 준다

오른쪽 열이 전부 관리형 서비스다 — 1장 빈칸 대응표의 네 줄이 이 장이 채우는 자리다.

클라우드에서	온프렘의 대체	도구 상세
CloudWatch Metrics	Prometheus + Alertmanager	관측 덱 2장
CloudWatch Logs	Loki (+ Grafana Alloy)	관측 덱 3장
X-Ray	Tempo (+ OpenTelemetry)	관측 덱 4장
CloudWatch 대시보드	Grafana	관측 덱 5장

세 신호와 스택 전체 그림

세 신호는 계층이 아니라 역할 분담이다 — 각각 얼마나 · 무슨 일이 · 어디서 느렸나에 답한다. 이 스택으로 통일하는 이유는 하나다. 저장소가 한 종류로 모인다 — Loki도 Tempo도 오브젝트 스토리지에 쓴다.

이 덱의 두 번째 축이 여기서 그대로 보인다 — 초록 두 개가 6장과 7장의 바닥이다.

무엇	상태가 떨어지는 곳	그 바닥이 없으면
Loki	오브젝트 스토리지 (chunk)	아예 못 뜬다
Tempo	오브젝트 스토리지 (블록)	아예 못 뜬다
Prometheus	로컬 디스크 (TSDB)	PVC 크기가 곧 보존 기간이다
Grafana	PostgreSQL (대시보드·사용자·알림)	SQLite로 떨어지고 HA가 안 된다

함정 — 순환 의존

Grafana가 CNPG를 쓰고, CNPG 장애를 Grafana로 보고, Grafana 로그인은 Keycloak을 거치고, Keycloak도 같은 CNPG를 쓴다면 — DB 하나가 죽을 때 원인을 볼 창까지 같이 죽는다. 도구마다 깨진 유리 계정(5장)과, DB 없이도 볼 수 있는 경로(Prometheus UI 포트포워딩)를 남긴다.

배치 원칙 — 감시자는 대상과 운명을 공유하면 안 된다

클라우드에서는 관측이 클러스터 밖의 관리형 서비스였다. 그래서 클러스터가 통째로 죽어도 콘솔은 살아 있었다. 온프렘에서 관측 스택을 같은 클러스터에 올리는 순간 그 성질이 사라진다 — 되찾으려면 배치로 만들어야 한다.

① 관측 스택은 인프라 노드에

앱이 노드를 잡아먹을 때 Loki가 같이 죽으면 원인을 못 본다. 2장에서 나눈 infra 노드에 두고 리소스 요청을 명시한다.

② 저장소는 클러스터 밖에

클러스터가 죽어도 로그는 남아 있어야 한다. 오브젝트 스토리지를 밖에 두는 6장의 이유가 여기서 다시 나온다.

③ 알림 경로는 스택 밖으로

Alertmanager가 죽으면 “알림이 안 온다”는 사실 자체를 모른다. 정상일 때 주기적으로 울리는 신호를 만들고, 그게 멈추면 외부 채널이 알아채게 한다 (관측 덱 2장의 Watchdog).

④ 관측 스택도 감시 대상이다

Prometheus 자신의 TSDB 용량, Loki의 인입 실패, Tempo의 S3 오류 — 이것들에 알림이 없으면 조용히 데이터가 비어 간다.

핵심 — 이 넷은 같은 문장이다

감시자와 감시 대상을 같은 실패 도메인에 두지 않는다. 같은 노드(①), 같은 저장소(②), 같은 알림 경로(③), 그리고 사각지대 없음(④). 넷 중 하나만 빠져도 정작 필요한 순간에 아무것도 안 보이는 그 사고가 난다.

온프렘의 제약 — 저장소가 유한하다

클라우드 관측 서비스는 “쓴 만큼 낸다”였다. 온프렘은 디스크가 물리적으로 유한하고, 오토스케일이 없고, 노드 증설에 몇 주가 걸린다. 그래서 시작할 때 네 값을 정해야 한다.

값	어림 기준	정하지 않으면
메트릭 리텐션	로컬 15~30일. 더 필요하면 장기 저장 검토	Prometheus PVC가 찬다
로그 보존	30~90일 (규정이 있으면 그쪽)	버킷이 차서 쓰기가 멈춘다
트레이스 보존 + 샘플링	7~30일, 샘플링은 1%에서 10% 사이	가장 빨리 용량을 먹는다
스크랩 간격	15~30초	짧을수록 시계열 수와 디스크가 비례해 는다

함정 — 차면 관측 스택이 먼저 죽는다

디스크가 차는 순서가 고약하다. 버킷이 차면 로그와 트레이스가 동시에 멈추고, 그 사실을 알려 줄 알림도 같은 스택에 있다. 그래서 용량 알림만은 관측 덱 2장의 필수 목록에서 절대 빼지 않고, 라이프사이클 규칙(6장)으로 자동으로 지워지게 만들어 둔다.

카디널리티도 같은 이유로 온프렘에서 더 아프다 — 클라우드면 인스턴스를 키우면 되지만 여기서는 Prometheus가 OOM으로 죽는 것으로 끝난다.

무엇부터 만드나

한 번에 다 세우려 하면 대개 대시보드만 예쁘게 만들다 끝난다. 도입 순서 다섯 단계(메트릭 → 알림 → 로그 → 연결 → 추적)와 각 단계에서 답할 수 있게 되는 질문은 관측 덱 1장의 “무엇부터 만드나”가 맡는다.

온프렘의 판단은 하나다 — 2단계(알림)를 건너뛰지 않는다. 1장의 제약 넷 중 “아무도 대신 안 깨워 준다”가 여기서 값을 치르고, 3단계(로그)까지만 해도 운영의 8할이 된다.

8장 요약

• 관측의 목적은 대시보드가 아니라 “뭐가 문제냐”에서 원인까지의 시간 단축이다
• 빈칸 넷(메트릭 · 로그 · 트레이스 · 조회)을 Prometheus · Loki · Tempo · Grafana가 채운다 — 도구 상세는 관측 덱
• 이 스택의 상태는 오브젝트 스토리지(6장)와 PostgreSQL(7장) 로 떨어진다. Loki·Tempo는 오브젝트 스토리지가 없으면 아예 못 뜬다
• 감시자와 감시 대상을 같은 실패 도메인에 두지 않는다 — 노드 · 저장소 · 알림 경로 · 사각지대
• 온프렘은 저장소가 유한하다 — 리텐션 · 보존 · 샘플링 · 스크랩 간격을 처음에 정한다
• 도입은 메트릭 → 알림 → 로그 → 연결 → 추적 순. 3번까지가 운영의 8할이다

관측 덱 — 도구 넷을 하나씩Prometheus·Loki·Tempo·Grafana의 설치·설정·질의·운영, 그리고 셋을 잇는 법.

9. 배포 — Argo CD와 GitOps지금까지 얹은 열몇 개를 손으로 다시 세울 수 있나. App of Apps, 설치 순서, 그리고 부트스트랩의 닭과 달걀.