Log messages can be pretty verbose, typically having a mix of message + property1=val1, property2=val2, ...
This is causing unnecessary hardness when reading / browsing logs, as those properties are needed typically only as a "drill-down"
Describe the solution you'd like
Having a way to push logs - where the property1=val1, property2=val2, ... can be extracted as structured data (as a drilldown) on the log entry itself in the UI - keeping only the message available for immediate browsing/read.
What problem are you trying to solve?
Log messages can be pretty verbose, typically having a mix of
message+property1=val1, property2=val2, ...This is causing unnecessary hardness when reading / browsing logs, as those properties are needed typically only as a "drill-down"
Describe the solution you'd like
Having a way to push logs - where the
property1=val1, property2=val2, ...can be extracted as structured data (as a drilldown) on the log entry itself in the UI - keeping only themessageavailable for immediate browsing/read.For example:
could be seen on the https://dash.deno.com/***/logs website as the following entry:
[a]and[b]could be expanded (tooltip or expand/collapse) whenever needed for this log statement.Describe alternatives you've considered
None really - those properties are needed when dealing with concurrent requests
Documentation, Adoption, Migration Strategy
If new construct/message format is needed - doc update is needed. No migration needed.