day-log

지난 주말, 새벽 2시쯤 PagerDuty가 울렸다. central monitoring 클러스터의 Prometheus가 OOMKill로 재시작 루프를 돌고 있다는 알람이었다. 메모리 limit을 32Gi로 잡아둔 인스턴스인데, 이게 몇 분 만에 한계를 찍고 죽고 있었다. 멘탈이 좀 흔들렸다. 평소엔 14~16Gi 정도에서 안정적으로 돌던 녀석이었다.원인을 추적하다 보니 결국 remote_write 큐 동작에 대해 내가 잘못 알고 있었던 부분이 꽤 있었다. 이번 글은 그날 새벽 삽질의 기록이다.배경: 우리 팀의 metric pipeline우리는 Thanos 대신 Mimir로 1년 전쯤 옮겼고, 각 워크로드 클러스터의 Prometheus가 remote_write로 Mimir 게이트웨이에 메트릭을 밀어넣는 구..

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

우리 환경에서의 처리량과 자원우리 팀은 2024년 말부터 Fluent Bit을 메인 로그 수집기로 쓰고 있다. 그전에는 Fluentd였고, 메모리 때문에 갈아탄 거였다. 그리고 작년쯤부터 일부 노드 그룹에 Vector를 같이 굴리고 있다. 이유는 좀 단순한데, 특정 워크로드의 로그가 너무 거칠어서 변환 규칙이 복잡해졌고, Fluent Bit의 Lua filter로 이걸 다 처리하기엔 가독성이 너무 떨어졌기 때문이다.그 상태로 1년 넘게 양쪽을 같이 운영했다. 최근 팀 내부에서 "그냥 한쪽으로 통일하자"는 얘기가 다시 올라와서, 진지하게 다시 비교해봤다. 이 글은 결론이 정해진 비교가 아니다. 솔직히 우리도 아직 한쪽으로 못 정했다.숫자부터 봤다우리 EKS 클러스터는 worker 노드가 약 110대 정도,..

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

오늘 알게 된 건데, Prometheus 3.8에서 native histogram이 드디어 stable로 올라왔다. 나처럼 몇 년째 "언젠간 써봐야지" 하고 미뤄두신 분들 꽤 있을 것 같아서 짧게 정리해둔다.왜 지금이냐기존 classic histogram 써본 분들은 아마 버킷 설계에서 한 번쯤 멘붕 겪어봤을 거다. 레이턴시 분포가 어떻게 생겼는지도 모르고 le 버킷을 깎아야 하고, 세밀하게 하자니 카디널리티 폭발, 대충 하자니 P99가 거짓말을 한다. 이걸 수년째 "일단 이 정도면 됐지" 하면서 쓰고 있었다.Native histogram은 버킷 경계를 exponential하게 자동 생성한다. 즉 설정 한 줄로 버킷 설계가 끝난다. 거기에 Remote Write 2.0에서 native form 그대로 전..