Quiz: query cost

Loki 질의에서 totalLinesProcessed 를 예측 가능하게 줄이는 것은 무엇인가?

• 줄 필터를 파서 앞으로 옮기는 것
• limit 을 작게 주는 것
• 스트림 선택자를 좁히거나 시간 구간을 줄이는 것
• direction 을 backward 로 바꾸는 것

그렇다면 줄 필터를 파서 앞에 두는 것은 왜 여전히 권장되나?

• 파서가 볼 줄 수가 줄어 CPU 를 아낀다
• 색인 조회 횟수가 줄어든다
• 청크를 더 적게 열게 된다
• 네트워크로 전송되는 청크가 줄어든다

응답 통계에서 totalPostFilterLines 가 뜻하는 것은?

• 구간에 걸친 청크에서 읽어 낸 전체 줄 수
• 필터를 통과해 남은 줄 수
• 색인에서 고른 스트림 수
• 결과로 돌려준 줄 수의 상한

대시보드가 Loki 비용을 밀어 올리는 일이 잦은 이유는?

• 대시보드 질의는 항상 캐시를 우회한다
• 패널이 자동으로 자주 돌아 헐거운 선택자가 반복 실행된다
• 패널마다 별도의 테넌트로 집계되어 한도가 곱해진다
• 그래프 패널은 로그 질의를 지표 질의로 바꿔 두 번 읽는다

사고 조사에서 로그 구간을 좁히기 전에 먼저 해야 하는 일은?

• 지표나 경보로 사고 시각을 못박는다
• 보존 기간을 늘려 과거 자료를 확보한다
• 모든 스트림의 라벨 목록을 먼저 내려받는다
• 질의에 limit 을 걸어 응답 크기를 줄인다

라벨 설계가 결국 질의 성능이 되는 이유로 맞는 것은?

• 라벨 값이 본문보다 먼저 압축되어 읽기가 빨라진다
• 라벨이 많을수록 청크가 커져 한 번에 더 많이 읽는다
• 좁힐 수 있는 라벨이 없으면 애초에 읽는 양을 줄일 방법이 없다
• 라벨 수가 곧 질의 병렬도를 정한다