day-log

Loki 스트림 폭발로 새벽 3시에 알람 받은 날

지난주 금요일 새벽 3시, 폰이 미친 듯이 울렸다. LokiIngesterMemoryHigh 알람. 눈이 번쩍 떠졌다.솔직히 이 알람이 처음 뜬 건 아니었다. 근데 그날은 좀 달랐다. ingester 파드 12개 중 4개가 OOMKilled로 계속 재시작 중이었고, 그 사이에 유입되던 로그는 500 에러 뱉으면서 다 흘려 보내고 있었다. 팀 슬랙에 사고 채널 만들고 노트북 열었을 땐 이미 5분치 로그가 유실된 상태였다.원인은 결국 stream 카디널리티Loki 운영해본 사람은 알겠지만, "카디널리티"는 반쯤 저주 같은 단어다. 라벨 하나 잘못 붙이면 몇 시간 뒤에 클러스터가 죽는다. 우리 팀도 그걸 알고 있었고, 그래서 애초에 라벨 조합을 5~6개로 제한하는 룰이 있었다.문제는 그 룰이 깨진 게 아니었다..

OpenTelemetry Collector 를 몇 년째 굴리다 보면 이상하게 감이 안 오는 순간이 온다. memory_limiter 를 batch 앞에 두라는 말은 모두가 하는데, 왜 그래야 하는지 정확히 설명할 수 있는 사람은 의외로 적다. 큐 사이즈랑 배치 사이즈를 같이 튜닝하라는 말도 마찬가지다. 각자 뭘 하는지 알아야 튜닝이 되는데, 대부분은 예제 설정을 그대로 복붙해서 쓴다.이번 글은 그 안쪽을 파본다. 리시버가 데이터를 받아서 익스포터까지 흘려보내는 사이에 사실 뭐가 일어나는지, 그리고 최근 컨트리뷰터들이 왜 큐 구조를 뜯어고치는지에 대한 이야기다.파이프라인이라는 이름의 파이프Collector 문서에서 "파이프라인" 이라고 부르는 건 겉보기에 리시버 → 프로세서 → 익스포터 로 이어지는 한 줄..

세 함수, 한 줄 요약Prometheus 쓰다 보면 반드시 한 번은 헷갈리는 게 rate, increase, irate 세 함수다. 이거 모르는 분 꽤 많더라. 알림 튜닝하다가 값이 이상해서 파본 적이 있는데, 이번 기회에 정리해둔다.rate(x[5m]): 지정한 구간(5분) 동안의 초당 평균 증가율. 부드럽게 완만해진다.increase(x[5m]): 지정한 구간 동안의 총 증가량. 그냥 얼마 늘었냐.irate(x[5m]): 구간 내 마지막 두 샘플만 보고 계산한 순간 증가율. 뾰족하게 튄다.사실 내부적으로는 increase(x[5m])는 rate(x[5m]) * 300 이랑 같다. rate가 좀 더 근본이다.실무에서 언제 뭘 쓰나알림(Alerting)에는 무조건 rate. irate로 알림 걸면 순간 ..

지난주에 OTel Collector가 메모리를 계속 먹다가 OOMKilled로 재시작되는 사고를 겪었다. 클러스터 전체 트레이스가 5분 단위로 뚝뚝 끊기는데, 그 시점 대시보드는 그냥 흰 도화지였다. 새벽 2시에 페이지가 울렸고, 눈을 뜨자마자 "batch processor" 4글자가 머리에 떠올랐다. 왜 하필이면 걔였는지, 지금 돌아보면 뻔한 이유가 있었지만 당시엔 한참을 헤맸다.우리 팀은 OTel Collector를 Deployment 3replica로 돌리고 있다. Ingress-nginx, 애플리케이션 SDK, kube-state-metrics에서 오는 트레이스/메트릭/로그를 모아 Tempo, Prometheus, Loki로 흘려보낸다. 트래픽 자체는 초당 스팬 8만개 정도. 그리 크지 않다. 그..

트레이스 샘플링을 tail 기반으로 돌리면 늘 만나는 문제가 있다. Collector 메모리가 훅훅 튀어 오른다. num_traces를 조금만 크게 잡아도 OOMKilled를 반복하고, 반대로 줄이면 span drop이 쌓인다. 우리 팀도 얼마 전까지 gateway 뒤에 붙은 tail-sampling collector 4대가 매일 새벽마다 OOM으로 재시작되는 걸 보고 있었다.이 글은 그 상황을 정리한 실무 가이드다. 최근에 OpenTelemetry Collector 쪽에서 나온 변화도 짚는다. 사실 이번 달(2026년 7월) Elastic이 upstream에 기여한 span-ingest 샘플링과 Pebble 기반 tail storage extension이 머지되면서 메모리 65%까지 줄었다는 리포트가 ..

문제 상황오늘 알게 된 건 아니고, 최근에 신규 팀원한테 알림 튜닝 인수인계하다가 "이 함수 처음 봐요"라는 말을 들었다. 생각해 보니 나도 예전에 absent()랑 헷갈려서 쓰다가 알람을 놓친 적이 있었다. 짧게 정리해 둔다.Prometheus 알림 대부분은 "값이 얼마 이상이면 발동"이다. 근데 실제 사고는 오히려 "메트릭 자체가 안 오는" 순간에 터진다. exporter 프로세스가 죽었거나, 파드가 재시작되면서 라벨이 살짝 바뀌었거나, scrape job이 config reload 때 조용히 빠졌거나.이럴 때 up == 0만 걸어두면 반쯤은 놓친다. up은 scrape target이 등록돼 있어야 값이 있는 거고, target이 아예 discovery에서 사라지면 up{job="X"} 시리즈 자체가..

왜 지금 넘어가야 하나Grafana Agent(Static/Flow/Operator)가 2025년 11월 1일에 공식적으로 EOL을 맞았다. 우리 팀도 그 전에 다 넘겨야 했는데, 막상 문서를 보면 "convert 명령어 쓰세요" 정도로 뭉뚱그려져 있어서 실무에서 걸리는 지점이 꽤 있었다. 이 글은 프로덕션 클러스터 3개(스테이징 1, 프로덕션 2 — 노드 합쳐서 80대 정도)에서 넘긴 기록을 정리한 것이다.Alloy는 이제 단순히 Agent 후속작이 아니라 Grafana Labs가 OpenTelemetry Collector를 자기네 방식으로 배포하는 형태에 가깝다. 이게 왜 중요하냐면, 기존에 metrics {}, logs {} 블록으로 쪼개 놓던 것이 otelcol.* 파이프라인과 나란히 놓이면서 c..

Loki 라벨 하나로 인제스터가 죽었다지난주 금요일 오후, Slack 알람이 미친 듯이 울렸다. loki-ingester가 OOMKilled로 재시작 루프에 빠진 것이다. 그날 배포한 건 아무것도 없었다. 근데 왜 갑자기?결론부터 말하면 개발팀 한 곳이 애플리케이션 로그에 trace_id를 라벨로 추가했다. 그거 하나 때문에 클러스터가 죽을 뻔했다. 이 삽질을 공유한다.처음엔 그냥 트래픽 스파이크인 줄 알았다인제스터 3대 중 2대가 메모리 12Gi 리밋을 찍고 OOMKilled. 남은 1대에 부하가 몰리면서 그것도 죽고. 클래식한 캐스케이딩 실패였다.처음엔 그냥 로그가 늘어난 줄 알았다. 배포 이력을 봐도 로키 관련 변경은 2주 전이 마지막이었고, 그라파나 대시보드에서 로그 인입량(loki_distrib..

며칠 전에 팀 신입한테 SLO 세팅을 맡겼는데, 결과물이 좀 아쉬웠다. Availability SLO 99.9% 걸어놓고 burn rate 알람을 하나만 만들어놨더라. 1시간 윈도우에 14.4x 넘으면 알람. 이거 흔한 실수라서 짧게 정리해둔다.왜 하나면 부족한가burn rate 알람 하나만 두면 두 가지 중 하나 문제가 무조건 생긴다.윈도우를 짧게 잡으면 (예: 5분/1시간) — 트래픽 스파이크 한 번에 알람을 뜬다. 새벽에 CDN이 잠깐 흔들려서 5분간 에러율 튀었다? 알람 온다. 근데 실제로는 15분 후에 자동 복구됐다. 오탐이다. 이런 게 반복되면 팀이 알람을 무시하기 시작한다.윈도우를 길게 잡으면 (예: 6시간/3일) — 진짜 큰 장애가 났는데 알람이 늦게 온다. 30분간 API가 완전히 죽어 ..

PromQL의 rate()랑 irate(), 언제 뭘 쓰는지 헷갈릴 때오늘 알림 룰 리뷰하다가 팀 주니어가 물어봤다. "이거 왜 rate() 썼어요? irate()가 더 최신 값 반영하는 거 아닌가요?" 아, 이거 은근히 헷갈려하는 사람 많더라. 짧게 정리한다.한 줄 요약대시보드와 알림에는 대부분 rate(). irate()는 진짜 필요할 때만.왜 그런지rate([5m])은 5분 범위 안의 첫 샘플과 마지막 샘플을 보고 초당 증가율의 평균을 낸다. 값이 부드럽다. 짧은 스파이크 하나가 튀어도 완만해진다.반면 irate([5m])은 범위 안의 가장 최근 두 샘플만 본다. 5분 범위를 줘도 실제로는 마지막 두 점만 쓴다는 얘기다. 그래서 반응은 빠른데 그래프가 지글지글하다.문제는 알림 룰에서 이걸 잘못 쓰면..