day-log

지난주에 우리 팀 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대 정도,..

왜 굳이 eBPF인가Pyroscope 2.0이 정식 릴리즈되면서 우리 팀도 한 번 손을 대봤다. 결론부터 말하면 — eBPF 기반으로 깔면 코드 한 줄 안 건드리고 P99 튀는 핫스팟을 잡을 수 있다. 다만 처음 깔 때 알아둬야 할 함정이 몇 개 있어서 정리한다.이 글은 EKS 1.31 클러스터(노드 약 60대) 기준이고, Grafana Alloy로 eBPF 프로파일러를 띄우는 방식을 기준으로 쓴다. Java/Go/Python 워크로드가 섞여 있는 환경이다.기존 SDK 방식으로 깔아도 되긴 한다. Java면 async-profiler, Go면 pprof endpoint, Python이면 pyspy를 사이드카로... 근데 워크로드 수가 100개 넘어가면 이걸 다 일일이 깔고 유지하는 게 일이다. 우리 팀에..

P99 레이턴시가 살짝 튀었다고 한밤중에 페이저가 울리는 경험, 다들 한 번쯤 해봤을 것 같다. 우리 팀도 작년에 SLO를 도입하고 단일 burn rate 알람으로 굴리다가 알람 피로도 때문에 결국 6개월 만에 갈아엎었다. 이번 글에서는 그때 갈아탔던 멀티 윈도우, 멀티 burn rate 방식의 셋업 가이드를 정리해본다. Google SRE workbook에 나온 것을 우리 팀 환경에 맞춰 변형한 버전이고, Prometheus 기반이라면 거의 그대로 쓸 수 있다.단일 burn rate가 왜 안 되냐먼저 단일 윈도우 알람이 왜 망가지는지부터 짚고 가자. SLO 99.9% 가용성을 가정해보자. 30일 기준 에러 버짓은 약 43분이다. burn rate가 1이면 에러 버짓을 정확히 30일에 걸쳐 다 쓰는 속도..

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