반응형

opentelemetry 2

OpenTelemetry Collector 메모리 누수, 며칠 싸운 기록

지난주에 우리 팀 OpenTelemetry Collector 파드들이 갑자기 OOMKill 잔치를 벌였다. 평소 워킹셋이 1.2GB 정도였는데, 어느 날 새벽부터 4GB까지 치솟더니 limit(6GB)을 넘기고 죽기 시작했다. 트래픽이 갑자기 늘어난 것도 아니고 설정을 건드린 것도 아니었다. 그라파나 패널 보면서 "아 이거 또 시작이네" 싶었다.결론부터 말하자면 batch processor의 send_batch_size를 잘못 키운 게 시작이었고, 거기에 exporter queue가 백프레셔를 못 받아주면서 메모리가 무한정 쌓였다. 글 안에 다 풀어쓰겠지만, 비슷한 증상 보시는 분들은 일단 memory_limiter부터 위에 끼워두시는 걸 권한다.증상 — 처음 3시간 동안 본 것오전 5시 23분에 첫 페..

IT/모니터링 2026.05.08

OpenTelemetry Collector tail sampling, 사실 내부에선 이렇게 돌아간다

지난 분기에 우리 팀은 트레이싱 백엔드를 Tempo로 옮기면서 OpenTelemetry Collector 게이트웨이 레이어를 다시 설계했다. 처음엔 head sampling으로 1%만 떼서 보내고 있었는데, 막상 장애가 터지면 정작 보고 싶은 에러 트레이스가 빠져 있는 일이 잦았다. 그래서 tail sampling으로 바꿨다. 그런데 도입한 지 며칠 지나니 collector 파드가 OOMKilled 당하면서 자꾸 죽는다. memory_limiter는 켜져 있었고, num_traces도 늘렸다 줄였다 하면서 한 주를 보냈다.문제는 tail sampling processor의 동작 원리를 정확하게 모르고 노브만 돌리고 있었다는 점이다. 사실 내부적으로는 어떻게 돌아가는지를 한 번 정리하지 않으면, 메모리 튜..

IT/모니터링 2026.04.28
반응형