クイズ: ラベルと本文の整形

스트림 라벨에 level 이 있는데 | logfmt 가 본문에서 또 level 을 꺼냈다. 어떻게 되나?

• 파서가 __error__ 를 붙이고 그 줄을 건너뛴다
• 본문에서 꺼낸 쪽이 level_extracted 로 밀려나고 원래 라벨은 남는다
• 본문 값이 스트림 라벨을 덮어쓴다
• 질의가 400 으로 거부된다

label_format 으로 라벨을 새로 만들면 Loki 의 비용은 어떻게 되나?

• 스트림이 늘어나 색인 비용이 커진다
• 다음 압축 때 색인에 반영되어 그때부터 늘어난다
• 결과에만 작용하므로 저장 비용은 그대로다
• 라벨 수만큼 청크가 복제된다

| line_format 을 줄 필터보다 앞 에 두면 무슨 일이 생기나?

• 뒤따르는 줄 필터가 다시 쓴 본문을 보게 된다
• 파서가 만든 라벨이 전부 사라진다
• 결과가 시간순이 아니라 라벨순으로 정렬된다
• line_format 이 무시된다

지표 질의에서 keep 이나 drop 이 필요한 이유는?

• 파서 오류가 난 줄을 제거하기 위해
• 값이 제각각인 라벨이 남아 있으면 계열이 쪼개지기 때문
• sum by 가 라벨 이름을 세 개까지만 받기 때문
• 읽는 바이트를 줄이기 위해

수집기가 붙이는 라벨과 애플리케이션이 찍는 필드의 이름 충돌을 구조적으로 막는 방법은?

• 수집기 라벨에 공통 접두어를 두는 규약을 정한다
• 모든 질의에 | drop 을 기본으로 붙인다
• 애플리케이션 로그를 JSON 으로만 찍게 한다
• 보존 기간을 나눠 두 종류를 다른 스트림으로 만든다

대시보드의 로그 패널이 200자짜리 JSON 으로 읽기 어렵다. 가장 알맞은 조치는?

• 패널의 새로 고침 주기를 늘린다
• 스트림 라벨을 늘려 줄을 나눈다
• line_format 으로 필요한 몇 칸만 남겨 다시 쓴다
• 보존 기간을 줄여 자료를 가볍게 한다