day-log

Grafana Agent가 작년 11월에 공식 EOL 된 지 벌써 9개월이 넘었는데, 우리 팀은 부끄럽지만 지난주에야 Alloy로 완전히 넘어왔다. 마감 압박 없으면 이런 마이그레이션은 자꾸 미뤄지는 게 사람 심리인 것 같다. 로그/메트릭 수집기가 노드에서 22대, 사이드카로 40개 넘게 떠 있는 환경이라 무섭기도 했고.결론부터 말하면 큰 사고는 없었지만, 문서만 보고 넘어갔다가는 새벽에 한 번쯤 페이지 받을 수 있는 함정이 몇 개 있었다. 정리해 둔다.storage.path 하나 때문에 메트릭이 20분간 안 왔다Alloy는 --storage.path 기본값이 data-alloy/로 바뀌었다. Agent Flow는 data-agent/였고. 이게 컨버터가 자동으로 안 바꿔주는 항목이라 문제였다.WAL이 ..

Loki를 운영해봤다면 한 번쯤은 겪는다. 어느 날 갑자기 인덱스가 폭발하고 쿼리가 느려지고, 로그 라이터에서 stream limit exceeded 에러가 뜬다. 원인은 대개 하나다. 누군가 라벨에 넣지 말아야 할 값을 넣었다.이 글은 그런 상황을 만난 팀을 위한 짧은 실무 가이드다. Loki 3.x 이후 정착된 structured metadata를 어떻게 쓰는지, 라벨과 structured metadata를 어떻게 나눠야 하는지 정리한다.무엇을 라벨에 넣으면 안 되는가원칙은 단순하다. 라벨은 수십 개 이내의 고유 값만, 그리고 오래 살아있는 값만 넣는다. 아래는 라벨에 넣으면 안 되는 대표적인 값들이다.trace_id, request_id, order_id 같은 요청 단위 IDuser_id, tena..

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

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

왜 굳이 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개 넘어가면 이걸 다 일일이 깔고 유지하는 게 일이다. 우리 팀에..

지난주 화요일 새벽 2시였다. 핸드폰이 울렸다. 처음엔 무시했다. 두 번째 울렸을 때 눈이 번쩍 떠졌다. 화면에는 loki-write Pod 절반이 OOMKill로 죽고 있다는 알림이 떠 있었다. 멘탈이 나갔다.우리 팀이 Loki를 도입한 건 2년 전이고, 그동안 큰 사고는 없었다. 노드 40대 정도 클러스터에서 하루에 약 1.2TB 로그가 들어오는 규모다. 그런데 그날 밤 갑자기 인덱스가 비정상적으로 커지면서 ingester가 메모리를 다 잡아먹었다. 새벽 4시까지 PC 앞에 있었다. 이 글은 그때 무슨 일이 있었고, 결국 어떻게 푼 건지에 대한 회고다.사고 시작 — 시리즈 수가 갑자기 30배처음 본 건 Grafana에 띄워둔 Loki 자체 모니터링 대시보드였다. loki_ingester_memory_..