day-log

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

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

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

Grafana Agent가 작년 11월에 공식 EOL 된 지 벌써 9개월이 넘었는데, 우리 팀은 부끄럽지만 지난주에야 Alloy로 완전히 넘어왔다. 마감 압박 없으면 이런 마이그레이션은 자꾸 미뤄지는 게 사람 심리인 것 같다. 로그/메트릭 수집기가 노드에서 22대, 사이드카로 40개 넘게 떠 있는 환경이라 무섭기도 했고.결론부터 말하면 큰 사고는 없었지만, 문서만 보고 넘어갔다가는 새벽에 한 번쯤 페이지 받을 수 있는 함정이 몇 개 있었다. 정리해 둔다.storage.path 하나 때문에 메트릭이 20분간 안 왔다Alloy는 --storage.path 기본값이 data-alloy/로 바뀌었다. Agent Flow는 data-agent/였고. 이게 컨버터가 자동으로 안 바꿔주는 항목이라 문제였다.WAL이 ..

한 달 반쯤 팀 내부에서 계속 논쟁이 있었다. Grafana Agent가 EOL 방향으로 가면서 Alloy로 갈아탈지, 아니면 이참에 그냥 순정 OpenTelemetry Collector(otelcol)로 통일할지. 결론부터 말하면 우리는 양쪽 다 쓴다. 딱 정하는 게 실무에서는 오히려 이상한 답이었다. 왜 그런 결론이 났는지 정리해둔다.왜 이 논쟁이 지금 튀어나왔나Grafana Agent가 2025년 말에 사실상 유지보수 모드로 들어갔고, 팀이 쓰던 Agent Flow 설정을 어디로 옮기느냐가 실질적인 문제였다. 자연스러운 후보는 두 개.하나는 Grafana Alloy. Agent Flow의 후속이니 마이그레이션 문서도 잘 정리돼 있고, alloy convert 명령으로 기존 config를 그대로 밀어..

Loki를 운영해봤다면 한 번쯤은 겪는다. 어느 날 갑자기 인덱스가 폭발하고 쿼리가 느려지고, 로그 라이터에서 stream limit exceeded 에러가 뜬다. 원인은 대개 하나다. 누군가 라벨에 넣지 말아야 할 값을 넣었다.이 글은 그런 상황을 만난 팀을 위한 짧은 실무 가이드다. Loki 3.x 이후 정착된 structured metadata를 어떻게 쓰는지, 라벨과 structured metadata를 어떻게 나눠야 하는지 정리한다.무엇을 라벨에 넣으면 안 되는가원칙은 단순하다. 라벨은 수십 개 이내의 고유 값만, 그리고 오래 살아있는 값만 넣는다. 아래는 라벨에 넣으면 안 되는 대표적인 값들이다.trace_id, request_id, order_id 같은 요청 단위 IDuser_id, tena..

지난주에 관측성 파이프라인이 새벽에 두 번 죽었다. 슬랙 알람이 4시 47분에 왔고, 눈 뜨자마자 노트북 열어서 로그부터 봤다. OTel Collector가 OOM으로 재시작을 반복하고 있었다. 이번 글은 그 삽질을 정리한 회고다. 결론부터 말하면 tail sampling 튜닝을 잘못했고, 트래픽 스파이크와 겹치면서 폭탄이 터졌다.상황우리 팀은 대략 40개 서비스에서 스팬을 뽑아 OpenTelemetry Collector 게이트웨이 → tail sampling 전용 Collector → 백엔드(Tempo)로 흘려보내고 있다. 게이트웨이는 15대, 샘플링 Collector는 6대. 각각 c6i.xlarge. 사고 당일 트래픽은 평소 대비 2.3배쯤 튀었다. 프로모션 이벤트가 있었는데 관측성 팀은 그 스케줄..

세 함수, 한 줄 요약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로 알림 걸면 순간 ..

트레이스 샘플링을 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%까지 줄었다는 리포트가 ..

SLO를 도입하고 나면 대부분 다음 관문에서 걸린다. "그래서 알림을 어떻게 쏘지?"에러 예산이 30일 기준으로 계산되니까 30일치를 보고 알림을 쏘면 너무 느리고, 5분만 보고 쏘면 배포 중 살짝 튀는 것에도 오작동한다. Google SRE 워크북에 있는 "multi-window multi-burn-rate" 패턴을 그대로 갖다 쓰긴 하는데, 이게 왜 이 조합인지, 내부에서 무슨 일이 벌어지는지는 대충 넘어가는 경우가 많다. 우리 팀도 그러다. 최근에 알림 튜닝을 다시 하면서 정리한 내용을 풀어본다.번-레이트라는 지표가 사실은 뭘 계산하는가번-레이트(burn rate)는 이름이 살짝 오해를 부른다. "얼마나 빨리 타고 있냐"인데, 기준선이 뭔지가 모호하다. 정확히는 이거다.번-레이트 = (관측 윈도우의..

트레이스 저장 비용이 슬금슬금 오르기 시작한 게 지난 분기부터였다. 우리 팀은 마이크로서비스 40여 개에서 초당 8만 스팬 정도를 뽑아내고 있었는데, 벤더 청구서가 예산의 두 배를 찍은 걸 보고 "샘플링을 진지하게 다시 봐야겠다"는 결론에 도달했다.Head sampling은 이미 걷어냈다. 어차피 랜덤으로 10% 남기는 방식은 정작 봐야 할 P99 지연이나 에러 트레이스를 놓치기 일쑤였다. 그래서 tail sampling으로 갈아탔는데, 처음 도입할 때는 "결정을 뒤로 미룬다" 정도의 개념만 알고 시작했다가, 운영하면서 그 안에서 벌어지는 일들이 훨씬 복잡하다는 걸 알게 됐다. 이 글은 그때 내가 코드를 뜯어보며 정리한 노트에 가깝다.Decision Wait의 의미와 함정Tail sampling proc..