push 는 204 인데 질의는 비어 있다

한 줄 요약

Loki 에 넣은 줄은 먼저 인제스터의 메모리에 쌓이고 나중에 청크로 저장소에 내려간다. 질의는 "최근 몇 시간" 만 인제스터에 물어보므로, 그보다 오래된 타임스탬프로 넣은 줄은 접수는 되지만 보이지 않는다.

왜 이게 필요했나

장애 복구 중이던 팀이 있었다. 수집기가 두 시간 동안 멈춰 있었고, 그동안 쌓인 파일을 복구해 Loki 로 밀어 넣었다. push 는 전부 204 를 돌려줬다. 그런데 Grafana 에서 그 시간대를 열어 보면 아무것도 없었다.

사람들은 "push 가 거짓말을 한다" 고 생각했다. 실제로는 줄이 인제스터 안에 잘 들어가 있었고, 질의가 그 구간을 인제스터에 묻지 않았을 뿐이다. 강제로 플러시를 돌려 청크를 저장소에 내리자 같은 질의에서 전부 나왔다.

어떻게 동작하나

쓰기 경로는 이렇다.

1. push 가 도착하면 인제스터가 스트림별로 열려 있는 청크에 줄을 덧붙인다. 같은 내용은 WAL 에도 적어 인제스터가 죽어도 되살릴 수 있게 한다.
2. 청크는 세 가지 조건 중 하나를 만나면 닫힌다 — 목표 크기에 도달(chunk_target_size), 일정 시간 새 줄이 없음(chunk_idle_period), 열린 지 너무 오래됨(max_chunk_age).
3. 닫힌 청크는 객체 저장소로 올라가고, 색인에는 그 스트림과 시간 범위가 기록된다.

읽기 경로는 두 갈래다. 질의는 저장소에 묻고, 최근 구간이면 아직 저장소에 안 내려간 줄을 위해 인제스터에도 묻는다. 여기서 "최근" 을 정하는 것이 querier.query_ingesters_within 이고 기본값은 3시간이다. 구간의 끝이 그보다 과거면 질의는 인제스터를 건너뛴다.

그래서 과거 타임스탬프로 넣은 줄 은 이 두 경로 사이의 틈에 빠진다. 저장소에는 아직 없고, 인제스터에는 있지만 아무도 묻지 않는다. 시간이 지나 청크가 자연히 닫히고 올라가면 보이기 시작한다 — 그래서 "한참 뒤에 저절로 나타났다" 는 이야기가 나온다.

이 설계는 실수가 아니다. 인제스터에 묻는 일은 비싸고, 오래된 구간까지 매번 물으면 모든 질의가 느려진다. 다만 뒤늦게 밀어 넣는 복구 작업에서는 이 가정이 깨진다.

운영에서 기억할 것은 세 가지다. 첫째, 복구로 과거 자료를 밀어 넣었다면 플러시를 기다리거나 강제로 돌린다. 둘째, 너무 오래된 자료는 애초에 거부될 수도 있다 — reject_old_samples 와 reject_old_samples_max_age 가 그 손잡이다(이 실습 설정은 일부러 꺼 두었다). 셋째, 이 파드의 Loki 는 모든 구성 요소가 한 프로세스에 든 단일 바이너리 모드다. 운영에서 인제스터·쿼리어·컴팩터가 따로 뜨면 같은 원리가 그대로 적용되지만, 플러시를 부르는 자리와 지켜볼 지표가 달라진다.

현장에서 만나는 모습

가장 자주 보는 증상은 "대시보드의 최근 15분은 멀쩡한데 어제 구간이 비어 있다" 이다. 최근 구간은 인제스터가 답해 주고 과거 구간은 저장소가 답하는데, 저장소로 올라가는 길이 막혀 있으면 정확히 이 모양이 된다. 객체 저장소 자격 증명이 만료된 사고에서 늘 이렇게 나타난다.

두 번째는 인제스터 재시작 직후의 빈 구간이다. WAL 재생이 끝나기 전에는 그 구간이 비어 보이고, 재생이 끝나면 채워진다. 그래서 인제스터를 굴리는 배포 중에 "로그가 사라졌다" 는 신고가 들어오면, 먼저 몇 분 기다려 보는 것이 맞다.

세 번째는 청크 크기 튜닝이다. 목표 크기를 너무 작게 잡으면 객체가 수없이 많아져 색인과 질의가 느려지고, 너무 크게 잡으면 인제스터 메모리가 커지고 재시작 시 잃을 것이 많아진다.

다음 실습에서 할 것

파드의 Loki 에 최근 자료와 다섯 시간 전 자료를 각각 넣고, 두 번째 것이 접수는 되는데 질의에서는 비어 있는 것을 직접 본다. 그 경계를 정하는 설정을 서버의 /config 에서 찾아 확인하고, 강제 플러시 전후로 저장소의 청크 파일 수와 질의 결과가 어떻게 달라지는지 숫자로 기록한다. 마지막에는 여섯 시간 전 줄 하나를 직접 넣어 보이게 만드는 데까지 해 본다.