Consistent logging

[Southclaws]

trafficstars

goals:

• log natives with invalid args passed - this will help server owners surface issues they may not have known about
• use a consistent log format, not sentences with specifiers in them but structured logs that are easy to search/filter/parse

some additional notes:

• not JSON logs - maybe in future if there's demand but this is way too verbose I think for now
• keep interface simple
• common events can have composable templates:

SCRIPT_API(SendDeathMessage, bool(IPlayer* killer, IPlayer* killee, int weapon))
{
	if(killee != nullptr)
	{
		PawnManager::Get()->players->sendDeathMessageToAll(killer, *killee, weapon);
	}
	else
	{
                 // args: component name, native name, argument name
		LogTemplates::InvalidArguments("player", "SendDeathMessage", "playerid");
	}

	return true;
}

Would, potentially (if using logfmt) output:

ts=2021-01-01T12:04:11 component="player" native="SendDeathMessage" arg="playerid" msg="invalid native argument"

Which would construct a properly formatted log using a well-known structure, this would keep logs of the same types of events consistent and allow for easier searching/filtering.

In this scenario, if a server owner wants to find all the points where their script is making invalid native calls, they can filter for invalid native argument and be certain that there are no other patterns to look for - they get the native name, argument name all in one, easy to read event.

This also facilitates the ability for larger more complex servers to ingest logs into a proper log aggregator for searching and filtering. Though I'd imagine I could count on one hand how many servers would find the need for this. That being said, by facilitating this, it may help server owners investigate new tools to make their operational tasks easier.

[Cheaterman]

IMHO logfmt would be optional, equally as JSON or even sqlite ; all valid and convenient options for structured logging. (and yes, JSON is verbose AF, but it's also fairly convenient hehe - more for machines than logfmt, but logfmt is more for machines than standard unformatted text logs anyway, so I feel like more options can't hurt)

[Southclaws]

So are you proposing every single log call must have two entries? one for humans and one structured?

[Hual]

imo there should be a human readable entry and a secondary entry the type of which is specified in config (could be json, logfmt)

[Southclaws]

the msg= component is typically the human readable entry, no need for multiple, i've never seen any software do two independent log entries