day-log

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

어쩌다 라벨에 request_id를 박았나지난주 새벽 2시 17분에 핸드폰이 울렸다. PagerDuty였다. "Loki ingester OOM, 로그 쿼리 응답 없음." 평소 같으면 "내일 보자" 하고 자야 하는데, 마침 다음날 오전에 장애 회고 미팅이 잡혀 있었다. 거기서 로그가 안 보이면 곤란해진다. 노트북을 켰다.결론부터 말하면, 우리 팀에서 무심코 라벨에 박아놓은 request_id 하나 때문에 Loki 인덱스가 통째로 부풀어 올랐고, ingester가 메모리 한계에 부딪혀 차례로 죽었다. 그 후로 1주일 동안 카디널리티를 줄이느라 정신없이 보냈다. 그 기록이다.이게 좀 부끄러운 이야기인데, 처음부터 그런 건 아니었다. 우리 팀이 Loki를 도입한 건 작년 봄이었고, 그때는 그냥 namespace..