접근 로그 확인

요청을 보냈는데 접근 로그 파일이 비어 있다. 가장 먼저 확인할 것은?

• 파일 싱크가 버퍼에 모았다가 비우는 주기(기본 10초)가 아직 지나지 않았는지
• access_log 가 route_config 아래에 있어야 하는데 자리를 잘못 잡았는지
• 로그 파일의 소유자가 Envoy 프로세스와 달라 쓰기가 막혔는지
• %RESPONSE_CODE% 연산자 이름을 대문자로 적었는지

싱크에 filter 를 달았더니 설정이 통째로 거절됐다. 가장 그럴듯한 원인은?

• status_code_filter 는 JSON 형식 싱크에만 쓸 수 있다
• filter 를 typed_config 안에 적었다. name 과 같은 층에 적어야 한다
• 비교 연산자에 GE 대신 >= 를 써야 한다
• 필터를 쓰려면 싱크가 두 개 이상이어야 한다

direct_response 로 돌려준 요청의 로그에서 %UPSTREAM_HOST% 자리는 어떻게 되는가?

• 리스너의 주소와 포트가 대신 들어간다
• 그 줄 자체가 로그에 남지 않는다
• 빈 문자열이 들어가 칸이 하나 사라진다
• 값이 없음을 뜻하는 정해진 표시가 들어간다

전체 로그는 짧은 형식으로, 오류 로그는 자세한 형식으로 따로 보관하려면?

• 싱크를 두 개 두고 각각 다른 형식과 다른 필터를 단다
• 형식 문자열 안에 조건문을 넣어 상태 코드에 따라 칸을 바꾼다
• 리스너를 두 개 만들어 오류 트래픽을 다른 리스너로 보낸다
• json_format 으로 두고 수집기 쪽에서 나눈다

클라이언트가 x-request-id 를 붙여 보냈다. 기본 동작에서 로그의 %REQ(X-REQUEST-ID)% 는?

• Envoy 가 새로 만든 값으로 덮어써서 찍힌다
• 클라이언트가 보낸 값이 그대로 찍힌다
• 보안상 지워져 값 없음 표시가 찍힌다
• 두 값이 쉼표로 이어져 함께 찍힌다

텍스트 형식 대신 json_format 을 고르는 가장 실질적인 이유는?

• JSON 이 텍스트보다 디스크를 덜 쓴다
• JSON 형식에서만 응답 플래그 연산자를 쓸 수 있다
• 값 안에 구분자가 들어가도 칸이 밀리지 않아 기계로 읽기에 안전하다
• JSON 형식은 버퍼 없이 요청마다 곧바로 기록된다