day-log

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를 그대로 밀어..

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

지난주에 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%까지 줄었다는 리포트가 ..

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

지난주에 OpenTelemetry Collector가 새벽에 세 번이나 OOM으로 재시작됐다. 알림이 잔뜩 쌓여있었고, 아침에 슬랙 열자마자 "이거 뭐야" 소리가 절로 나왔다. 원인은 결국 tail sampling processor였는데, 문제를 잡기까지 꽤 돌아왔다. 기록 삼아 남긴다.처음엔 그냥 트래픽 스파이크인 줄 알았다우리 팀은 최근에 head sampling에서 tail sampling으로 옮겼다. 이유는 명확했다. 에러 트레이스나 P99 넘어가는 느린 트레이스는 무조건 살려두고 싶은데, head sampling으로는 그게 불가능하니까. 트레이스 전체가 다 모여야 판단할 수 있는 정책들, 예를 들어 "이 트레이스에 5xx가 하나라도 있으면 keep" 같은 것들 말이다.옮긴 지 2주 정도는 조용했..

Fluent Bit vs OpenTelemetry Collector, 로그 파이프라인 뭘 쓸까로그 파이프라인 얘기가 나올 때마다 팀 내부에서 도는 논쟁이 하나 있다. "그냥 Fluent Bit 계속 쓰면 되지 않냐" vs "이제 OpenTelemetry Collector로 통합해야 하지 않냐". 사실 둘 다 맞는 말이라 답이 애매하다. 몇 달간 두 도구를 병렬로 굴려보고 정리한 감상을 적어둔다.어디서 마주치는 문제인가우리 팀 클러스터는 노드 40대 규모다. 로그는 원래 Fluent Bit DaemonSet으로 수집해서 사내 Loki로 밀어넣고 있었다. 문제는 그 다음 단계다. 트레이스는 OTel Collector로, 메트릭은 Prometheus로, 로그만 Fluent Bit로 각각 다른 파이프라인이 돌고..

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