You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.)
The text was updated successfully, but these errors were encountered:
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.
// 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.
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
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.)
The text was updated successfully, but these errors were encountered: