-
-
Notifications
You must be signed in to change notification settings - Fork 229
feat: implement unified JSON/text logging format #4392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -132,6 +132,20 @@ | |
| label="Log Level" | ||
| ></v-select> | ||
| </v-col> | ||
| <v-col | ||
| cols="12" | ||
| sm="6" | ||
| md="4" | ||
| v-if="newGateway.logEnabled" | ||
| > | ||
| <v-select | ||
| :items="logFormats" | ||
| v-model="newGateway.logFormat" | ||
| label="Log Format" | ||
| hint="Choose between human-readable text or structured JSON logging" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm a bit afraid that making users choose hinders our troubleshooting capabilities. Everything from the automated bot comments when users post the wrong log, over the automatic log analyzer, to my feeble brain expects the text-based logging format. Can we instead just add the JSON based logs as an additional transport that can be toggled?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm trying to think about how best to do this. My use case for JSON logs is to ship them to centralized logging tools - ideally this reads the STDOUT of the container/process. Alternatively, it would read known files, but that's less ideal as the files then need to be specified whereas STDOUT is assumed. I see no problem in always making the web console text format. I actually almost did that, but decided consistency was better. But, I think it would make sense to do so. Where I'm stuck is - what is your expectation of the format of STDOUT and file logs in the case where the additional JSON transport is toggled on?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think configuring the STDOUT should be fine. Our most common troubleshooting use case is having users write debug logs to file and uploading those files.
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It just occurred to me that this presents a conflict I believe: Driver's raw option is global - it affects ALL transports (console, file, web UI)
We could move human parsing logic to the UI, but that's duplicative to what the driver already does in text mode so it feels a bit hacky. Is there another way to solve this that I'm missing?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess I'll have to tie the message formatting into the transport format, so it can be toggled on a per-transport basis. |
||
| persistent-hint | ||
| ></v-select> | ||
| </v-col> | ||
| <v-col | ||
| cols="12" | ||
| sm="6" | ||
|
|
@@ -2269,6 +2283,10 @@ export default { | |
| { title: 'Debug', value: 'debug' }, | ||
| { title: 'Silly', value: 'silly' }, | ||
| ], | ||
| logFormats: [ | ||
| { title: 'Text (Human-readable)', value: 'text' }, | ||
| { title: 'JSON (Structured)', value: 'json' }, | ||
| ], | ||
| headers: [ | ||
| { title: 'Device', key: 'device' }, | ||
| { title: 'Value', key: 'value', sortable: false }, | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the code in this function is overcomplicated and introduces lot of repeated code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I broke this up into more manageable functions and made it more DRY.