day-log

왜 지금 넘어가야 하나Grafana Agent(Static/Flow/Operator)가 2025년 11월 1일에 공식적으로 EOL을 맞았다. 우리 팀도 그 전에 다 넘겨야 했는데, 막상 문서를 보면 "convert 명령어 쓰세요" 정도로 뭉뚱그려져 있어서 실무에서 걸리는 지점이 꽤 있었다. 이 글은 프로덕션 클러스터 3개(스테이징 1, 프로덕션 2 — 노드 합쳐서 80대 정도)에서 넘긴 기록을 정리한 것이다.Alloy는 이제 단순히 Agent 후속작이 아니라 Grafana Labs가 OpenTelemetry Collector를 자기네 방식으로 배포하는 형태에 가깝다. 이게 왜 중요하냐면, 기존에 metrics {}, logs {} 블록으로 쪼개 놓던 것이 otelcol.* 파이프라인과 나란히 놓이면서 c..

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

Loki 라벨 하나로 인제스터가 죽었다지난주 금요일 오후, Slack 알람이 미친 듯이 울렸다. loki-ingester가 OOMKilled로 재시작 루프에 빠진 것이다. 그날 배포한 건 아무것도 없었다. 근데 왜 갑자기?결론부터 말하면 개발팀 한 곳이 애플리케이션 로그에 trace_id를 라벨로 추가했다. 그거 하나 때문에 클러스터가 죽을 뻔했다. 이 삽질을 공유한다.처음엔 그냥 트래픽 스파이크인 줄 알았다인제스터 3대 중 2대가 메모리 12Gi 리밋을 찍고 OOMKilled. 남은 1대에 부하가 몰리면서 그것도 죽고. 클래식한 캐스케이딩 실패였다.처음엔 그냥 로그가 늘어난 줄 알았다. 배포 이력을 봐도 로키 관련 변경은 2주 전이 마지막이었고, 그라파나 대시보드에서 로그 인입량(loki_distrib..

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

오늘 알게 된 건데, 이거 모르고 쓰는 분이 꽤 많더라. absent() 함수. Prometheus에서 "메트릭이 사라졌을 때" 알람 거는 그 함수 말이다.뭐가 문제냐면우리 팀이 최근에 배치 job 상태를 감시하려고 이런 룰을 넣었다.- alert: JobMetricMissing expr: absent(batch_job_last_success_timestamp) for: 5m문제는 이거다. 배치가 서버 2대에 떠 있고, 한쪽 서버만 죽었을 때 이 알람이 안 울린다. absent()는 "메트릭 전체가 사라졌을 때"만 1을 반환한다. 나머지 한 서버가 살아있으면 시리즈는 여전히 존재하니까 조용하다. 근데 우리는 인스턴스 단위로 놓치고 싶지 않았다.unless가 답인 경우이럴 땐 unless를 쓴다.- a..

지난주 화요일 새벽 2시 반쯤이었다. 온콜 알림이 왔고, Prometheus 인스턴스 두 대가 연달아 OOM으로 죽었다는 내용이었다. 눈을 비비고 노트북을 열었는데, Grafana는 이미 죽어 있었다. 데이터 소스가 죽었으니 당연한 일이었다. 그 다음 두 시간 반 동안 내가 겪은 얘기다.처음엔 그냥 재시작하면 될 줄 알았다당시 우리 스택은 이랬다. 노드 24대 EKS 클러스터, kube-prometheus-stack으로 배포한 Prometheus 두 대 HA 구성, 메모리 리소스 리밋은 각각 16GB. 평상시 series 개수는 대략 480만 정도. 리텐션 15일. remote_write로 장기 저장소에 밀어넣고 있었다.일단 재시작. WAL replay가 시작됐는데, 이게 도무지 끝나지가 않았다. 평소엔..

지난주 수요일 새벽이었다. 새벽 2시쯤 자다가 슬랙 멘션 알림에 깼다. "어제 오후 4시부터 지금까지 로그가 안 보여요." 운영팀 야간 담당자였다. 휴대폰 화면 밝기에 눈이 시리면서도 멘탈은 이미 깨어버린 상태. 우리 클러스터는 노드 80대 규모에 Loki 3.7.x를 미러 모드로 돌리고 있었고, 하루에 1.5TB 정도의 로그를 받는다. 그게 7시간 동안 사라졌다는 얘기다.솔직히 처음엔 좀 의심했다. "진짜 7시간 동안 아무도 모를 수가 있나?" 근데 확인해보니 진짜였다. Grafana에서 last 24h로 보면 오후 4시 지점에서 갑자기 라인이 뚝 끊겨 있었다. 그래프가 그렇게 정직하게 끊긴 건 처음 봤다.ingester pod 상태부터 봤다가장 먼저 한 일은 ingester pod의 상태 확인이었다...

관측성 파이프라인 한 번이라도 운영해본 사람이면 다 비슷한 고민을 한다. "에이전트는 뭘로 깔지?" 예전에는 Prometheus + Promtail + Tempo agent 같은 식으로 컴포넌트별로 따로 깔거나, 통합하려면 OpenTelemetry Collector 한 장 깔거나, 그것도 아니면 Grafana Agent 깔거나. 그런데 Grafana Agent가 Alloy로 리브랜딩된 이후, 그리고 그 사이에 OTel Collector contrib도 계속 두꺼워지면서 선택지가 다시 흐릿해졌다.우리 팀에서도 작년 말에 한 번 정리하고 갔는데, 최근 Alloy v1.16 시리즈가 나오고 OTel Collector 쪽도 컴포넌트가 또 바뀌면서 다시 비교할 필요가 생겼다. 이번 글은 그 정리 노트다. 어느 쪽..

들어가며작년 말부터 트레이싱 백엔드를 갈아엎자는 얘기가 팀 내부에서 계속 나왔다. 직접적인 계기는 Jaeger v1이 2025년 12월 31일부로 EOL을 맞은 것이었다. 어차피 손을 대야 한다면 Jaeger v2로 갈지, Tempo로 옮길지 둘 중 하나를 골라야 했다. 결론부터 말하면 우리는 Tempo로 갔다. 그런데 솔직히 말해서 이 결정이 모든 팀에 정답은 아니다.두 솔루션이 지금 어디쯤 와 있는지Jaeger v2는 2024년 11월에 정식 릴리즈됐는데, 기존 코드베이스를 거의 다 버리고 OpenTelemetry Collector 위에 다시 쌓아 올린 구조다. 그러니까 Jaeger v2는 사실 "Jaeger 구성요소가 추가된 OTel Collector distribution"에 가깝다. 최근 2.1..