day-log

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

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

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

Prometheus를 운영하다 보면 어느 순간부터 “카디널리티(cardinality) 조심하세요”라는 말이 유령처럼 따라붙는다. 개발자가 라벨 하나 추가했을 뿐인데 다음 날 Prometheus 인스턴스가 OOMKilled로 재기동되고, prometheus_tsdb_head_series가 400만을 찍고 있는 걸 보게 된다. 사실 나도 예전에는 “라벨 값 종류 많아지면 메모리 좀 쓰겠지” 정도로만 생각했다. 근데 TSDB 내부를 좀 파고 들어가 보니 이건 “좀 쓰는” 수준이 아니라, 아예 저장 엔진의 구조 자체가 라벨 조합 하나하나에 비용을 부과하도록 설계돼 있다.이 글에서는 Prometheus의 로컬 TSDB가 시계열(series)을 어떻게 저장하고 인덱싱하는지, 그래서 왜 user_id, request..

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

로그 파이프라인 재설계 얘기가 팀 내부에서 다시 나왔다. 3년 전에 Fluentd로 깔아둔 걸 언제까지 끌고 갈지, 지금 시점에서 갈아탄다면 Fluent Bit이냐 Vector냐. 두 도구 모두 몇 달씩 붙잡고 굴려봤기 때문에 이 참에 정리해두려고 한다.결론부터 말하면 "무조건 이거"는 없다. 다만 우리 팀이 어떤 상황에서 뭘 골랐는지, 왜 그랬는지는 명확하게 얘기할 수 있다.두 도구를 다시 보자Fluent Bit은 C로 짜였고 CNCF 공식 프로젝트다. Kubernetes 생태계 안에서는 사실상 표준처럼 자리잡은 지 오래다. 바이너리 크기 작고, 메모리 몇십 MB로 노드마다 DaemonSet으로 깔아둬도 티가 안 난다. Kubernetes metadata filter가 안정적이고, tail input의..

한 달 반쯤 팀 내부에서 계속 논쟁이 있었다. 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..

요즘 새 클러스터 세팅할 때마다 CNI를 Cilium으로 깔고, 그 다음날부터 "Hubble UI 켜주세요" 요청이 들어온다. Pixie도 붙여봤고, 최근에는 Grafana Beyla까지 검토 목록에 올렸다. 세 도구 다 "사이드카 없이 관측성 확보"라는 같은 문구를 쓰는데, 사실 내부적으로는 노드에서 하는 일이 꽤 다르다. 이번 주에 팀 세미나 준비하면서 각 도구가 어디에 eBPF 프로그램을 붙이는지, 데이터는 어떻게 흘러 나가는지 다시 정리했다.이 글은 그 정리 노트다. 사용법 튜토리얼은 아니고, "왜 이 도구는 HTTP 헤더까지 보이는데 저 도구는 IP:포트만 보이지?" 같은 궁금증에 답이 되도록 쓴다.eBPF 훅 포인트가 결정하는 관측 범위관측성 도구가 뭘 볼 수 있는지는 결국 커널의 어느 지점에..

지난주에 관측성 파이프라인이 새벽에 두 번 죽었다. 슬랙 알람이 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로 알림 걸면 순간 ..