Loki 라벨 확인

문항 7개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 실습 4단계에서 `request_id` 를 라벨로 넣고 30줄을 더 보냈더니 `/series` 가 돌려주는 스트림 수가 크게 늘었습니다. 왜 그런가요?

   1. 로그 줄이 늘면 스트림도 그만큼 늘기 때문에
   2. 라벨 값이 한 종류라도 달라지면 그것이 별개의 스트림이 되기 때문에
   3. Loki 가 30줄마다 스트림을 하나씩 나누기 때문에
   4. 라벨을 추가하면 기존 스트림이 둘로 쪼개지기 때문에

2. 스트림 하나는 무엇인가?

   1. 같은 파일에서 온 로그 한 줄
   2. 서로 다른 라벨 조합 하나
   3. 수집기가 여는 파일 하나
   4. 로그를 보내는 서비스 하나

3. `{app="web"} |= "500"` 에서 `|= "500"` 은?

   1. 본문 역색인을 바로 조회하는 연산
   2. 정규식으로 만든 색인을 타는 연산
   3. 앞의 라벨 선택으로 좁힌 범위를 훑는 필터
   4. 미리 계산해 둔 캐시를 조회하는 연산

4. request_id 를 라벨로 넣으면?

   1. 색인이 늘어 그 값 검색이 빨라진다
   2. 값이 본문에 있을 때와 차이가 없다
   3. 같은 값끼리 모여 압축이 잘 된다
   4. 줄마다 스트림이 하나씩 생겨 폭발한다

5. 그 값을 내용에 두면 필터링을 못 하나?

   1. `| logfmt` 같은 파서로 그대로 걸 수 있다
   2. 라벨이 아니면 아예 걸 수 없다
   3. `|~` 정규식으로만 걸 수 있다
   4. 따로 색인해 두어야 걸 수 있다

6. 라벨로 써도 되는지 가르는 기준은?

   1. 값의 글자 수가 충분히 짧은가
   2. 값이 영문과 숫자로만 되어 있는가
   3. 질의에서 자주 쓰는 필드인가
   4. 값의 가짓수가 시간이 지나도 늘지 않는가

7. 서서히 터지는 라벨의 흔한 예는?

   1. pod 이나 container_id — 배포마다 새 값이 생긴다
   2. level — 값이 대여섯 개로 고정된다
   3. env — 값이 운영·스테이징 정도로 끝난다
   4. app — 서비스가 늘어도 수십 개 수준이다