[feature]: Include Git Commit Short Hash in Log Messages

[ffranr]

We would like to enhance our log messages by including the git commit hash (first 5 characters, 1,048,576 combinations) in each log entry. This will help us accurately track the version of the software generating the logs, even if users only provide partial log snippets.

Proposed Log Format

2024-08-13 18:54:19.852 <commit_short_hash> [...] ...

Where <commit_short_hash> is replaced with the short commit hash (e.g. a1b42).

Motivation

Users frequently report issues by providing only a few log lines without including the entire log file or specifying the running version of the software. Including the short git commit hash in each log message will allow us to determine the exact version of the codebase that generated the logs, enabling quicker and more accurate troubleshooting.

Considerations

By adding the commit short hash to each log message, we should be aware that the log files will increase in size, as each log entry will have an additional 6 characters (5 for the commit hash and 1 for the space). Over time, this could lead to a significant increase in the total size of the log files, especially in systems that generate a high volume of logs.

Currently, the system manages log retention by truncating logs based on the total size of all log files. This means that increasing the size of individual log entries could result in log files reaching their maximum allowed size more quickly, leading to more frequent truncation.

We should review the current log retention policy to ensure it still meets our needs with the increased log file size. This might involve adjusting the total allowed log size or the number of log files retained.

(Log files are gzip compressed, which should efficiently handle the repeated commit short hash strings.)

[ffranr]

Implementation notes

• Add git commit short hash optional argument (btclog.BackendOption) which can be passed into btclog.Backend when constructing a new instance via btclog.NewBackend. Perhaps store the commit short hash value as a field on btclog.Backend. See: https://github.com/btcsuite/btclog

• Modify function formatHeader in repository btcsuite/btclog such that the new git commit short hash value, if set, is written into the header.

• Modify NewRotatingLogWriter in LND repository to allow passing through btclog.BackendOption arguments to the btclog.NewBackend call.

---

Alternative method:

• Add a btclog.BackendOption method which allows redirecting calls to formatHeader. Allowing us to provide our own formatHeader function to btclog.Backend. And in addition, break up the existing btclog.formatHeader function such that it can be called in parts.

This will then allow us to output the git commit short hash for debug messages only for example.

[guggero]

A way easier option would be to use PrefixLog.

Then this block can just become:

	// Return a function which will create a sublogger from our root logger
	// without shutdown fn.
	return func(tag string) btclog.Logger {
		return build.NewPrefixLog(
			"0000:", root.GenSubLogger(tag, shutdown),
		)
	}

Where 0000: is the git tag. I'd opt to go for 4 digits only.

[guggero]

In lnd we now have the WithBuildInfo function that adds rev=xxxx to the main server context. So every log statement that uses the new context aware LogS() functions will output the commit/revision short hash. Something similar should be done in tapd, since we use lnd's build.LogConfig struct that already defines the NoCommitHash boolean (that is currently unused in tapd and has no effect).