Structured logging: facilitate additional fields in log lines
- Dominant language
- Go
- Stars
- 2.6k
- Forks
- 147
- PR merge metrics
- No merged PRs in 30d
Description
We're working on adding more structure to our logging to help us be able to correlate things in a complex environment. To facilitate this, we'd like to have supercronic facilitate adding additional key+value pairs to it's JSON log output.
For our specific use case, we could fork supercronic to do something like:
```go
return logrus.Fields{
"logger": "supercronic",
"environment_name": os.GetEnv("ENVIRONMENT_NAME"),
"service_name": os.GetEnv("SERVICE_NAME"),
"release_version": os.GetEnv("RELEASE_VERSION"),
}
```
Maintaining a fork isn't great, so alternatively the ability to pass this in via command lines flags would work. Either "dynamically":
```json
"command": [
"/usr/bin/supercronic",
"-json",
"-passthrough-logs",
"-log-metadata-from-env environment_name=ENVIRONMENT_NAME",
"-log-metadata-from-env service_name=SERVICE_NAME",
"-log-metadata-from-env release_version=RELEASE_VERSION",
"./crontab"
]
```
or statically:
```json
"command": [
"/usr/bin/supercronic",
"-json",
"-passthrough-logs",
"-log-metadata environment_name=foo",
"-log-metadata service_name=bar",
"-log-metadata release_version=baz",
"./crontab"
],
```
Are either of these approaches preferable? Would you accept a pull requests for it?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the existing JSON log output and command-line option handling. Compare the proposed environment-derived and static key-value metadata approaches, then define and document the accepted interface and verify that added fields appear in JSON log lines without breaking existing output.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100