Closed nCubed closed 8 minutes ago
Hi @nCubed, thanks for opening this issue.
I've tried to reproduce the issue and I am unsure about the report.
Our Logger emits JSON structured data, and based on that boolean values are represented as true
and false
. These values are represented as they are in CloudWatch Logs, since they are valid JSON data types.
Once the logs are indexed in CloudWatch Log Insights, discovered fields within the structured logs appear to be stored as 1
and 0
for true
and false
respectively. This is not something we can control, since we only emit valid JSON objects.
It's important to note also that at no point CloudWatch Log Insights, nor CloudWatch Logs, change the data type of what we output. What you appear to be observing is only limited to how CloudWatch Log Insights stores fields, which then has implications on how you must query the data.
I tested this with another version of Powertools for AWS - which has similar outputs - and used the following query:
fields @timestamp, someVal, message, @message
| filter someVal = 1
| sort @timestamp desc
| limit 10000
As you can see from the image below, the @message
(which is the reserved keyword in Log Insights to refer to the logged blob) still contains the boolean value represented as such. The discovered field however is now treated as a 1
:
I could not find a mention of this behavior in the CloudWatch docs, however if I were to guess this is the result of how CloudWatch Insights stores the indexed data. Using small integers rather than boolean values might be either a cost saving measure or a necessity based on the underlying architecture of the service (which I have no knowledge of).
Back to the point at hand, I am not sure Powertools for AWS should be opinionated in regards to how boolean values are treated. I don't think indiscriminately converting them to 1
s and 0
s is the right choice and it would indubitably have impact on other customers.
I however understand and acknowledge that seeing boolean values in the logs, and having to use numbers to query these same logs might feel counterintuitive and inconsistent. To work around this I would suggest you to look into adopting a custom log formatter for Logger which would allow you to coerce boolean values to their corresponding numbers before each log is emitted.
Thanks for the detailed reply @dreamorosi. Everything you're mentioned makes sense and what I had expected for the most part. Feel free to close out this issue report, unless there's anything else I can do to assist here.
Thanks @dreamorosi! @nCubed I will be closing the issue, thank you!
Expected Behaviour
bool
value, the log entry is true/false.bool
value should be queryable with true/falseCurrent Behaviour
bool
value as a 1/0bool
valueCode snippet
Logger.LogInformation(new { @true = true, @false = false });
Cloud Insights
message.true=1 message.false=0
Possible Solution
No response
Steps to Reproduce
Powertools for AWS Lambda (.NET) version
latest
AWS Lambda function runtime
dotnet8
Debugging logs
No response