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
Is your feature request related to a problem? Please describe.
Python and Typescript use snake_case for all outputs. Java uses a mix of snake_case and camel_case.
Customers will use the same tool (CloudWatch Logs, Loggly, Datadog, etc.) to search data across logs, and if main keys are different they will find half of the information when using multiple runtimes.
At the sametime, if we break language consistency and the other application(not using powertools but standard logging libs) loose that tracking on single visibility.
Considering both the above rationale, for now, we should standardize on the same key name (snake_case) for logging output - we, Golang will also using snake_case albeit in the early phase. As it’s a breaking change for Java, let’s strive for making it configurable but a v2 should standardize it on snake_case.
Describe the solution you'd like
Ability to configure if customers want consistent logging keys same as used in powertools logging for other runtimes.
Describe alternatives you've considered
None
Additional context
The text was updated successfully, but these errors were encountered:
@heitorlessa, do we have a page somewhere to find the log keys used in the different languages? Or should I go in the code (ex: here and potentially elsewhere)
Is your feature request related to a problem? Please describe.
Python and Typescript use snake_case for all outputs. Java uses a mix of snake_case and camel_case.
Customers will use the same tool (CloudWatch Logs, Loggly, Datadog, etc.) to search data across logs, and if main keys are different they will find half of the information when using multiple runtimes.
At the sametime, if we break language consistency and the other application(not using powertools but standard logging libs) loose that tracking on single visibility.
Considering both the above rationale, for now, we should standardize on the same key name (snake_case) for logging output - we, Golang will also using snake_case albeit in the early phase. As it’s a breaking change for Java, let’s strive for making it configurable but a v2 should standardize it on snake_case.
Describe the solution you'd like
Ability to configure if customers want consistent logging keys same as used in powertools logging for other runtimes.
Describe alternatives you've considered
None
Additional context
The text was updated successfully, but these errors were encountered: