pkg/logger/lk: new package for log key glossary

[jmank88]

This PR introduces a new package logkey to serve as a glossary of logger keys in order to align common fields.

Supports:

• https://github.com/smartcontractkit/chainlink/pull/15936

[pavel-raykov]

This PR introduces a new package logkey to serve as a glossary of logger keys in order to align common fields.

What is the intended use of the keys from logkey? Is this for labelling with ZAP's zap.String(key, value) construction, or is it for arbitrary string / int constants that can be used for logging in a centralized way?

[jmank88]

This PR introduces a new package logkey to serve as a glossary of logger keys in order to align common fields.

What is the intended use of the keys from logkey? Is this for labelling with ZAP's zap.String(key, value) construction, or is it for arbitrary string / int constants that can be used for logging in a centralized way?

We don't typically use the zap field API like that, but that would be valid. More often we just call the w variants: Logger.<level>w("<message>", logkey.ChainID, chainID)

[pavel-raykov]

This PR introduces a new package logkey to serve as a glossary of logger keys in order to align common fields.

What is the intended use of the keys from logkey? Is this for labelling with ZAP's zap.String(key, value) construction, or is it for arbitrary string / int constants that can be used for logging in a centralized way?

We don't typically use the zap field API like that, but that would be valid. More often we just call the w variants: Logger.<level>w("<message>", logkey.ChainID, chainID)

I see, so are you planning to extract all the possible keys in some kind of automatic way? Or would you just keep adding them here continuously?

[jmank88]

This PR introduces a new package logkey to serve as a glossary of logger keys in order to align common fields.

What is the intended use of the keys from logkey? Is this for labelling with ZAP's zap.String(key, value) construction, or is it for arbitrary string / int constants that can be used for logging in a centralized way?

We don't typically use the zap field API like that, but that would be valid. More often we just call the w variants: Logger.<level>w("<message>", logkey.ChainID, chainID)

I see, so are you planning to extract all the possible keys in some kind of automatic way? Or would you just keep adding them here continuously?

We could try to start with some automation, but adding keys manually would be sufficient for most common inconsistencies.

I did consider providing zap field support as well, but I'm not sure how that should work. Even just ChainID is an interesting example. We probably would want to encourage (or even enforce) string based chain IDs, but we don't want to force callers to make a string to pass in, since that is inefficient in cases where the log message does not need to be serialized. We'd rather also accept fmt.Stringer. So zapfield.ChainID("string") isn't flexible enough, we'd want a fmt.Stringer version, and probably int64 too. It wasn't obvious to me how to sort that out in a clean way, so I left it out of scope for now.

[pavel-raykov]

This PR introduces a new package logkey to serve as a glossary of logger keys in order to align common fields.

What is the intended use of the keys from logkey? Is this for labelling with ZAP's zap.String(key, value) construction, or is it for arbitrary string / int constants that can be used for logging in a centralized way?

We don't typically use the zap field API like that, but that would be valid. More often we just call the w variants: Logger.<level>w("<message>", logkey.ChainID, chainID)

I see, so are you planning to extract all the possible keys in some kind of automatic way? Or would you just keep adding them here continuously?

We could try to start with some automation, but adding keys manually would be sufficient for most common inconsistencies.

I did consider providing zap field support as well, but I'm not sure how that should work. Even just ChainID is an interesting example. We probably would want to encourage (or even enforce) string based chain IDs, but we don't want to force callers to make a string to pass in, since that is inefficient in cases where the log message does not need to be serialized. We'd rather also accept fmt.Stringer. So zapfield.ChainID("string") isn't flexible enough, we'd want a fmt.Stringer version, and probably int64 too. It wasn't obvious to me how to sort that out in a clean way, so I left it out of scope for now.

Sound good. Thanks for explaining!

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove the stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove the stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This PR has been automatically closed because it has been stale for > 30 days. If you wish to continue working on this PR, please reopen it and make any necessary changes.