Open chriskellyrelay opened 6 months ago
The dynamic example looks good! My first thought was whether the option could be provided more tersely, eg, inferring the field name if only an ENV variable is specified?
For example, I would think the most common case would be that the field name and environment variable match --log-metadata ENVIRONMENT_NAME
could be specified to log the value of $ENVIRONMENT_NAME to the field name "environment_name"
In the (slightly) more complex case you could specify both the field and variable names, when they differ: --log-megadata release_version=APTIBLE_GIT_REF
would log the value of $APTIBLE_GIT_REF to the field name "release_version"
Would you accept a pull requests for it?
If it includes appropriate tests, and doesn't alter any existing use cases, we'd be happy to review such a PR!
Sounds good, --log-metadata ENVIRONMENT_NAME
works for us and could help a lot of people. Once things are in logs it is "easy enough" to transform them later if needed.
I have a ticket internally for this, will update here if/when we get the bandwidth to work on it.
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:
Maintaining a fork isn't great, so alternatively the ability to pass this in via command lines flags would work. Either "dynamically":
or statically:
Are either of these approaches preferable? Would you accept a pull requests for it?