log_append

为当前请求的访问日志追加一个字段。

此指令应与 log 指令一起使用，因为首先需要 log 启用访问日志。

值可以是静态字符串，也可以是一个占位符，该占位符会在请求时被替换为对应值。

语法

log_append [<matcher>] [<]<key> <value>

默认情况下，日志字段会在中间件链返回时添加（即“late”模式），也就是在后续所有处理器完成之后添加（例如在 reverse_proxy、respond 或 file_server 等会写出响应的处理器之后），因此它会捕获请求和响应的最终状态。

如果使用 < 作为键名前缀，则该字段会被标记为“early”模式，意味着日志字段会在调用链中的下一个处理器之前添加到日志中，因此可以在请求被后续处理器修改之前读取它。

仅用于调试目的（不要在生产环境中使用）：当值为以下占位符之一时，此处理器有特殊处理：{http.request.body}、{http.request.body_base64}、{http.response.body} 或 {http.response.body_base64}。如果使用请求体占位符，则会隐式启用“early”模式，并缓冲请求体。如果使用响应体占位符，则会启用响应缓冲以捕获响应体，并在写出响应时以“late”模式将该字段添加到日志中。

示例

在日志中显示请求所服务的站点区域，是 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
}

打赏支持