_logLevel and log tag seems repetitive #29
Assignees
Labels
Comments
|
@tulsidas I agree that it is repetitive and was added originally to allow for different methods of querying logs within CloudWatch. I will think through some options to make these default tags optional or overridable. |
KyleRoss
added a commit
that referenced
this issue
Apr 12, 2021
BREAKING CHANGE: There are no longer any built-in tags added to the tags array for each log message.
github-actions bot
pushed a commit
that referenced
this issue
Apr 12, 2021
# [3.0.0](v2.4.0...v3.0.0) (2021-04-12) ### Bug Fixes * add `.npmignore` file to help reduce the size of the package ([c21bd7f](c21bd7f)) * add `.npmignore` file to help reduce the size of the package ([9ccdc69](9ccdc69)) * do not use husky when on a CI environment ([a17ac76](a17ac76)) * reverse the check for LAMBDALOG_SILENT env variable ([95828b1](95828b1)) * reverse the check for LAMBDALOG_SILENT env variable ([5ab6dc5](5ab6dc5)) ### Code Refactoring * move message.tags to a getter and setter ([201a6fe](201a6fe)) ### Features * add ability for tags to be functions ([459380f](459380f)) * add ability for tags to be functions ([87ea24d](87ea24d)) * add ability to change the key names of the message output ([4a71909](4a71909)) * add ability to change the key names of the message output ([bc1169b](bc1169b)) * add new method `addLevel()` to LambdaLog ([9fde2e3](9fde2e3)) * add new method `addLevel()` to LambdaLog ([f7dbfd0](f7dbfd0)) * add new options `levelKey`, `messageKey`, and `tagsKey` ([bb5ba70](bb5ba70)) * add new options `levelKey`, `messageKey`, and `tagsKey` ([4d10968](4d10968)) * add new website! ([44a15dc](44a15dc)) * add new website! ([9aa6e2e](9aa6e2e)) * add symbols for referencing private properties in LogMessage ([f4b1c99](f4b1c99)) * add symbols for referencing private properties in LogMessage ([beb5e39](beb5e39)) * add symbols to reference certain private properties ([b502366](b502366)) * add symbols to reference certain private properties on LogMessage class ([952b62d](952b62d)) * convert Errors in metadata to plain objects [#31](#31) ([f55d474](f55d474)) * convert Errors in metadata to plain objects [#31](#31) ([576052a](576052a)) * remove default tags and add tag variable support [#29](#29) ([a43b0ae](a43b0ae)) * remove default tags and add tag variable support [#29](#29) ([ae686ef](ae686ef)) * set node engine to >= 10.0.0 ([0b5e564](0b5e564)) * set node engine to >= 10.0.0 ([2d022ec](2d022ec)) * switch from travis to github actions ([6ca053f](6ca053f)) * use jest for testing and coverage ([216141d](216141d)) * **internal:** add function to stub errors with a toJSON method ([b5e3dbe](b5e3dbe)) * switch from travis to github actions ([f2d418e](f2d418e)) * use jest for testing and coverage ([fafed5d](fafed5d)) * **internal:** add function to stub errors with a toJSON method ([d0707bd](d0707bd)) ### BREAKING CHANGES * There are no longer any built-in tags added to the tags array for each log message. * `message.tags` is no longer a property of the LogMessage class that can be directly changed. * Whenever an Error object is passed into the metadata for a log message, it will automatically be converted to a plain object as stringifying the an Error object will always yield `{}`. * Previously you could directly access the private properties of LogMessage. In order to add some integrity, they are no longer using standard property names starting with an underscore and are instead referenced using symbols instead. For advanced usage, these symbols are exported as a static property on the LogMessage class under `LogMessage.symbols`. * Previously you could directly access the private properties of LambdaLog. In order to add some integrity, they are no longer using standard property names starting with an underscore and are instead referenced using symbols instead. For advanced usage, these symbols are exported as a static property on the LambdaLog class under `LambdaLog.symbols`.
|
@tulsidas This has been implemented and published in v3.0.0. I'm still waiting for the new documentation site to go live with the details. In short, the default tags Thanks for the idea! |
|
@all-contributors please add @tulsidas for ideas |
|
I've put up a pull request to add @tulsidas! 🎉 |
|
yaaaaay! 💪 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On all the logs there is both _logLevel and the log tag, that seems repetitive in the sense that I'm having the same info twice (thrice, considering that AWS CloudWatch also adds the level), can this be customized to remove the log tag for example? I saw that it is hardcoded on the source code
{"_logLevel":"info","msg":"hiya","_tags":["log","info"]}
The text was updated successfully, but these errors were encountered: