「Caddy」 logging 设计哲学

【Caddy】 logging 设计哲学

结构化日志

跟大多数应用程序一样，Caddy 日志是结构化的。这意味着消息中的信息不仅仅是不透明的字符串或字节片。相反，数据保持强类型，并由各个字段名称作为键，直到需要对消息进行编码并将其写出。

127.0.0.1 - - [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.1" 200 2326

这种格式“有结构”但不是“结构化”：它只能用于记录 HTTP 请求。没有（有效的）方法可以对其进行不同的编码，因为它是一个不透明的字节串。它也缺少很多信息。它甚至不包括请求的 Host 标头！这种日志格式仅在单个站点获取有关请求的最基本信息时才有用。

Caddy 日志的输出如下：

{
	"level": "info",
	"ts": 1585597114.7687502,
	"logger": "http.log.access",
	"msg": "handled request",
	"request": {
		"method": "GET",
		"uri": "/",
		"proto": "HTTP/2.0",
		"remote_addr": "127.0.0.1:50876",
		"host": "example.com",
		"headers": {

			"User-Agent": [
				"curl/7.64.1"
			],
			"Accept": [
				"*/*"
			]
		},
		"tls": {
			"resumed": false,
			"version": 771,
			"ciphersuite": 49196,
			"proto": "h2",
			"proto_mutual": true,
			"server_name": "example.com"
		}
	},
	"user_id": "",
	"duration": 0.000014711,
	"size": 2326,
	"status": 200,

	"resp_headers": {
		"Server": [
			"Caddy"
		],
		"Content-Type": ["text/html"]
	}
}

结构化日志对数据类型没有限制：它们可以用于任何代码路径并包含任何类型的信息。因为日志是结构化的和强类型的，它们可以被编码成任何格式。因此，如果您不想使用 JSON，可以将日志编码为任何其他表示形式（或者自定义）。

3个设计哲学

In essence, efficient, structured logging generally promotes these philosophies:
1. Too many logs are better than too few
2. Filtering is better than discarding
3. Defer encoding for greater flexibility and interoperability

大概意思：

多日志总比少日志好过滤比丢弃好“延迟编码”以获得更大的灵活性和互操作性

在生产环境中，需要尽量在关键的节点打日志应用程序日志，不要吝啬;

有些bug难以复现，更多的日志（上下文）可以帮助我们快速定位到bug的根本原因。

参考地址：

[1]:

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!