log: make sink encodable

[mohammed90]

sink logs have, thus far, been printed not encoded in any format. This does not play friendly with log parsers expecting a specific format from a particular source. In other words, it becomes a hassle to tell the log parser, e.g. Loki, Caddy logs are json-formated if some lines aren't.

[mholt]

I wonder if we can embed one type within another (StandardLibLog or CustomLog) to reduce duplication. If StandardLibLog used CustomLog, I'd be pretty confident that the change is good 👍

[mohammed90]

I wonder if we can embed one type within another (StandardLibLog or CustomLog) to reduce duplication. If StandardLibLog used CustomLog, I'd be pretty confident that the change is good 👍

Now that I've tried it, embedding introduces more invasive changes than the duplication. I even tried to have a third struct type for the common fields, but same limitation incurred, keyed fields had to be wrapped with the embedded type. The CustomLogger cannot be the one that's embedded because it contains Include and Exclude fields which don't operate outside of it and have no semantics for anything besides it.

I don't like how invasive this attempt at duplication. I wonder if there's another way by means of an unexported function.

In case you want to play with it, here's a working config:

{
	"logging": {
		"sink" : {
			"level": "DEBUG",
			"encoder": {
				"format": "json"
			}
		},
		"logs": {
			"default": {
				"level": "DEBUG",
				"encoder": {
					"format": "json"
				}
			}
		}
	},
	"apps": {
		"http": {
			"servers": {
				"srv0": {
					"listen": [
						":443"
					],
					"routes": [
						{
							"match": [
								{
									"host": [
										"localhost"
									]
								}
							],
							"handle": [
								{
									"handler": "subroute",
									"routes": [
										{
											"handle": [
												{
													"body": "Howdy!",
													"handler": "static_response"
												}
											]
										}
									]
								}
							],
							"terminal": true
						}
					]
				}
			}
		}
	}
}

[francislavoie]

I highly doubt any plugin is directly using the StandardLibLog type right now. Could we just rename it to BaseLog or something, and use that as sink? That would make it read less weird.

[mohammed90]

I highly doubt any plugin is directly using the StandardLibLog type right now. Could we just rename it to BaseLog or something, and use that as sink? That would make it read less weird.

How about now?

[francislavoie]

Looks great to me 👍

I want Matt's review before merging tho

[mholt]

Awesome -- yeah, let's give it a try!