day-log

지난 화요일 새벽에 사고가 하나 있었다. 결제 API의 error rate가 슬금슬금 올라가고 있었는데, 우리가 그렇게 자랑하던 multi-window multi-burn-rate alert는 새벽 5시가 다 되어서야 울렸다. CS팀이 먼저 알아챈 걸 사후에 확인했다. 그 시간까지 error budget의 30% 가까이가 이미 타버린 상태였다.사실 이 alert 룰은 팀 내부에서 두 달 전에 큰 리팩터링을 마쳤던 것이라 더 뼈아팠다. Google SRE 워크북에 나온 그 표를 그대로 옮겨놓고, PromQL도 두 번 세 번 리뷰했었다. 근데 왜 안 울렸을까.룰은 정석대로였다우리가 쓰던 fast burn 알람은 이런 모양이었다.- alert: PaymentApiErrorBudgetBurnFast expr:..

오늘 알게 된 건데, 이거 모르고 쓰는 분이 꽤 많더라. absent() 함수. Prometheus에서 "메트릭이 사라졌을 때" 알람 거는 그 함수 말이다.뭐가 문제냐면우리 팀이 최근에 배치 job 상태를 감시하려고 이런 룰을 넣었다.- alert: JobMetricMissing expr: absent(batch_job_last_success_timestamp) for: 5m문제는 이거다. 배치가 서버 2대에 떠 있고, 한쪽 서버만 죽었을 때 이 알람이 안 울린다. absent()는 "메트릭 전체가 사라졌을 때"만 1을 반환한다. 나머지 한 서버가 살아있으면 시리즈는 여전히 존재하니까 조용하다. 근데 우리는 인스턴스 단위로 놓치고 싶지 않았다.unless가 답인 경우이럴 땐 unless를 쓴다.- a..

OTel Collector 배포할 때 처음에는 다들 하나만 띄우고 시작한다. 우리 팀도 그러다. Deployment 하나 만들어서 어플리케이션들이 다 거기로 OTLP 쏘게. 초기엔 잘 돌아간다. 그러다 트래픽 늘고, tail sampling 붙이고, k8s 노드 라벨을 span에 붙이기 시작하면 슬슬 얘가 무너진다.이번 글은 그 다음 단계 — Agent(DaemonSet) + Gateway(Deployment) 두 층 구조로 가는 실전 셋업이다. 최근 릴리스 몇 개(현재 v0.154 기준)에서 바뀐 것들도 같이 정리한다.왜 두 층인가한 층으로 유지하다 보면 결국 이런 문제가 나온다.첫째, 노드 로컬 정보를 붙이기 어렵다. Pod의 IP는 알지만 노드 이름, 커널 버전, 인스턴스 타입 같은 건 어디선가 리..

지난주 화요일 새벽 2시 반쯤이었다. 온콜 알림이 왔고, Prometheus 인스턴스 두 대가 연달아 OOM으로 죽었다는 내용이었다. 눈을 비비고 노트북을 열었는데, Grafana는 이미 죽어 있었다. 데이터 소스가 죽었으니 당연한 일이었다. 그 다음 두 시간 반 동안 내가 겪은 얘기다.처음엔 그냥 재시작하면 될 줄 알았다당시 우리 스택은 이랬다. 노드 24대 EKS 클러스터, kube-prometheus-stack으로 배포한 Prometheus 두 대 HA 구성, 메모리 리소스 리밋은 각각 16GB. 평상시 series 개수는 대략 480만 정도. 리텐션 15일. remote_write로 장기 저장소에 밀어넣고 있었다.일단 재시작. WAL replay가 시작됐는데, 이게 도무지 끝나지가 않았다. 평소엔..

OpenTelemetry Collector를 운영하다 보면 refused_spans, enqueue_failed, OOMKilled 같은 시그널을 한 번쯤은 본다. 다들 "memory_limiter 처음에 두면 된다"고 말하지만, 정작 메모리가 한계에 닿았을 때 collector 내부에서 무슨 일이 일어나는지는 의외로 흐릿하게 알고 있는 경우가 많다. 나도 처음엔 그랬다. 어느 날 traces 파이프라인이 갑자기 데이터를 흘리기 시작해서 메트릭을 파보다가, 그때서야 batch와 queue, retry가 메모리 한계 앞에서 어떻게 상호작용하는지 본격적으로 파악하게 됐다.이 글은 그 흐름을 정리한 노트다. 2026년 2월 즈음 oneuptime이나 dash0 쪽에서 모범 사례 가이드가 다시 한번 정리됐는데,..

autovacuum이 돌고 있는 줄 알았다지난주에 PostgreSQL 디스크가 갑자기 부풀어오르는 사건이 있었다. 정확히는 이미 며칠 전부터 부풀고 있었는데, 우리가 늦게 알아챈 거다.처음에는 단순히 "데이터가 많아져서 그렇겠지" 생각했다. 그런데 dead tuple 비율을 찍어보니 40%를 넘기고 있었다. 어떤 테이블은 60%. 라이브 row보다 죽은 row가 더 많은 상태였다. autovacuum 로그를 뒤져보니 마지막 vacuum이 4일 전에 멈춰 있었다. 그리고 그 사이에 누가 무엇을 했는지 추적이 시작됐다.pg_stat_activity가 말해준 것pg_stat_activity 뷰를 열어보니 한 세션이 4일째 살아 있었다. state는 idle in transaction. xact_start는 월..

지난주 수요일 새벽이었다. 새벽 2시쯤 자다가 슬랙 멘션 알림에 깼다. "어제 오후 4시부터 지금까지 로그가 안 보여요." 운영팀 야간 담당자였다. 휴대폰 화면 밝기에 눈이 시리면서도 멘탈은 이미 깨어버린 상태. 우리 클러스터는 노드 80대 규모에 Loki 3.7.x를 미러 모드로 돌리고 있었고, 하루에 1.5TB 정도의 로그를 받는다. 그게 7시간 동안 사라졌다는 얘기다.솔직히 처음엔 좀 의심했다. "진짜 7시간 동안 아무도 모를 수가 있나?" 근데 확인해보니 진짜였다. Grafana에서 last 24h로 보면 오후 4시 지점에서 갑자기 라인이 뚝 끊겨 있었다. 그래프가 그렇게 정직하게 끊긴 건 처음 봤다.ingester pod 상태부터 봤다가장 먼저 한 일은 ingester pod의 상태 확인이었다...

무슨 일이 벌어지는가absent_over_time(up{job="api"}[5m]) 같은 알람 표현식은 "지정한 메트릭이 5분 동안 한 번도 안 보이면 1을 반환"한다. 그래서 잡 다운 감지용으로 흔히 쓴다. 근데 함정이 있다.Prometheus 프로세스가 막 기동했을 때, 아직 첫 스크레이프가 끝나지 않은 시점에서 이 표현식이 평가되면 어떻게 될까? 메트릭이 없으니까 그냥 1 이 나온다. 그리고 알람룰에 for 절이 없으면 그 즉시 firing.# 이렇게 쓰면 Prometheus 재시작할 때마다 알람 옴- alert: ApiDown expr: absent_over_time(up{job="api"}[5m]) labels: severity: critical룰 평가 주기가 보통 30초~1분이라, P..

관측성 파이프라인 한 번이라도 운영해본 사람이면 다 비슷한 고민을 한다. "에이전트는 뭘로 깔지?" 예전에는 Prometheus + Promtail + Tempo agent 같은 식으로 컴포넌트별로 따로 깔거나, 통합하려면 OpenTelemetry Collector 한 장 깔거나, 그것도 아니면 Grafana Agent 깔거나. 그런데 Grafana Agent가 Alloy로 리브랜딩된 이후, 그리고 그 사이에 OTel Collector contrib도 계속 두꺼워지면서 선택지가 다시 흐릿해졌다.우리 팀에서도 작년 말에 한 번 정리하고 갔는데, 최근 Alloy v1.16 시리즈가 나오고 OTel Collector 쪽도 컴포넌트가 또 바뀌면서 다시 비교할 필요가 생겼다. 이번 글은 그 정리 노트다. 어느 쪽..

지난주 화요일 새벽 3시쯤이었다. 슬랙 oncall 채널에 "그라파나 대시보드 일부 패널이 No data로 뜬다"는 핑이 올라왔다. 자다가 받은 알림이라 멘탈이 좀 나간 상태에서 노트북을 열었는데, 진짜로 우리 결제 서비스 P99 레이턴시 그래프가 새벽 1시 47분부터 약 한 시간 동안 비어 있었다.문제는 Prometheus 자체는 멀쩡했다는 거다. up{} 메트릭도 정상이고 로컬 쿼리도 잘 됐다. 그런데 Thanos를 통해 보던 장기 보관 대시보드에서만 그 구간이 통째로 비어 있었다. 결론부터 말하면 remote_write 큐가 막혀서 WAL에서 읽기가 블록됐고, 그 사이에 들어온 샘플들이 일부 누락됐다. 이게 내가 새벽 4시까지 깨어 있었던 이유다.처음 의심한 것들 (다 틀렸음)가장 먼저 의심한 건 ..