Quiz: Log Levels and Sampling

로그 표본을 줄 단위로 10% 만 남기면 무엇이 문제인가?

• 압축률이 떨어져 저장 비용이 오히려 올라간다
• 같은 요청의 줄이 일부만 남아 어느 요청도 끝까지 읽을 수 없다
• 타임스탬프 순서가 어긋나 검색 색인이 깨진다
• 수준별 비율이 달라져 경보 임계값이 어긋난다

일관된 머리 표본에서 request_id 를 해시하는 이유는?

• 아이디를 감춰 개인정보 노출을 막기 위해서
• 아이디 길이를 줄여 저장 공간을 아끼기 위해서
• 같은 아이디에 대해 어디서 계산해도 같은 판정이 나오게 하기 위해서
• 해시 충돌을 이용해 표본 수를 자동으로 조절하기 위해서

표본률 10% 에 '오류로 끝난 요청은 전부 남긴다' 를 더하면 어떤 일이 벌어지나?

• 줄 수가 조금 늘어나는 대신 실패한 요청의 보존율이 100% 가 된다
• 오류 요청이 전체의 절반이라 줄 수가 두 배로 늘어난다
• 표본률이 사실상 무의미해져 전체를 남기는 것과 같아진다
• 정상 요청의 보존율이 함께 올라가 비용 예측이 불가능해진다

연속된 같은 로그 줄을 하나로 접고 repeated=<k> 를 붙이는 방식의 장점은?

• 원본 줄을 복원할 수 있어 무손실 압축과 같다
• 검색 색인의 카디널리티가 줄어 질의가 빨라진다
• 반복 횟수라는 정보를 잃지 않으면서 부피만 줄인다
• 재시도 고리 자체를 코드 수정 없이 멈출 수 있다

초당 로그 상한을 걸 때 반드시 지켜야 할 것은?

• 상한에 걸린 줄을 별도 파일로 옮겨 나중에 합친다
• 상한을 DEBUG 같은 낮은 수준에만 걸고 ERROR 는 제외한다
• 상한 값을 평소 로그 발생량의 절반으로 잡는다
• 상한을 초가 아니라 분 단위로 걸어 폭주를 흡수한다

로그 정책 문서에서 수준별 보존 기간을 따로 정하는 이유는?

• 저장소가 수준별로 다른 압축 알고리즘을 쓰기 때문에
• 수준마다 색인 비용이 달라 질의 속도가 달라지기 때문에
• 규제가 수준별로 다른 보존 기간을 요구하기 때문에
• 며칠 뒤에 다시 찾을 일이 있는 수준과 없는 수준이 다르기 때문에