log_append
출처: Caddy 공식 문서
본문
현재 요청에 대한 액세스 로그에 필드를 추가해요.
이 지시문은 우선 액세스 로깅을 활성화하는 데 필요한 log지시문과 함께 사용해야 해요.
값은 정적 문자열이거나, 요청 시점에 플레이스홀더 값으로 치환되는 플레이스홀더일 수 있어요.
문법
log_append [<matcher>] [<]<key> <value>
기본적으로 로그 필드는 미들웨어 체인을 거슬러 올라가는(즉 "늦게") 과정에서, 이후의 모든 핸들러가 완료된 후에 추가돼요(예: 응답을 쓰는 reverse_proxy, respond, file_server 같은 핸들러 이후). 그래서 요청과 응답의 최종 상태를 포착해요.
키 앞에 < 를 접두사로 붙이면 "early(이른)"로 표시돼요. 즉 체인에서 다음 핸들러를 호출하기 전에 로그 필드가 로그에 추가되므로, 이후 핸들러에 의해 수정되기 전에 요청을 읽을 수 있어요.
디버깅 목적 전용으로(프로덕션에서는 사용하지 말 것), 값이 {http.request.body}, {http.request.body_base64}, {http.response.body}, {http.response.body_base64} 중 하나일 때 핸들러는 특수 처리를 해요. 요청 본문 플레이스홀더를 사용하면 "early" 모드가 암시적으로 활성화되고 요청 본문이 버퍼링돼요. 응답 본문 플레이스홀더를 사용하면 응답 버퍼링이 활성화되어 응답 본문을 포착하고, 응답이 작성되는 동안 필드가 "늦게" 로그에 추가돼요.
예제
요청이 서빙되는 사이트 영역(static 또는 dynamic)을 로그에 표시하는 예시예요:
example.com {
log
handle /static* {
log_append area "static"
respond "Static response!"
}
handle {
log_append area "dynamic"
reverse_proxy localhost:9000
}
}
실제로 사용된 리버스 프록시 업스트림(node1, node2 또는 node3)과 업스트림 프록싱에 걸린 시간(밀리초), 그리고 프록시 업스트림이 응답 헤더를 쓰는 데 걸린 시간을 로그에 표시하는 예시예요:
example.com {
log
handle {
reverse_proxy node1:80 node2:80 node3:80 {
lb_policy random_choose 2
}
log_append upstream_host {rp.upstream.host}
log_append upstream_duration_ms {rp.upstream.duration_ms}
log_append upstream_latency_ms {rp.upstream.latency_ms}
}
}
키 앞에 < 를 붙여 로그 필드를 "early"로 추가할 수 있어요. 이러면 이후 핸들러에 의해 수정되기 전의 요청 상태를 포착할 수 있어요. 예를 들어 다시 쓰기 전의 원래 요청 경로를 로그로 남기려면 이렇게 해요(원래 요청 경로는 어차피 이미 로그로 남기 때문에 다소 억지스러운 예시지만, 개념을 설명하는 데는 도움이 돼요):
example.com {
log
log_append <original_path {http.request.uri.path}
rewrite /new-base{uri}
reverse_proxy localhost:9000
}
디버깅 목적으로 요청과 응답 본문을 로그에 추가하는 예시예요(프로덕션에서는 성능을 해치고 로그를 매우 시끄럽게 만들기 때문에 사용하지 말 것). 본문이 인쇄 불가능한 문자가 있는 이진 데이터일 것으로 예상된다면 대신 플레이스홀더의 base64 변형(예: {http.request.body_base64}, {http.response.body_base64})을 사용하면 복사하고 검사하기 더 쉬워요:
example.com {
log
log_append req_body {http.request.body}
log_append resp_body {http.response.body}
reverse_proxy localhost:9000
}