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
I suggest to add an option to render structured logs (e.g. JSON) as table view and select the most relevant fields to display (like "@timestamp","message","host","severity"). If one forwards e.g. journald JSON there are simply too many fields to see the most relevant "MESSAGE" field.
The text was updated successfully, but these errors were encountered:
That's a good idea, how do you envision defining such fields? It sounds like a map is needed as part of the rtail client CLI, but something in the webapp could work as well... the only issue is missing persistence so you would not be able to carry your settings with you on a different browser or after a cache cleanup.
The default could be some standard fields like 'msg' (bunyan), 'message' or 'MESSAGE' (journald).
Well I'm not good in UI design:
Place a field selector with field names (seen in last N Logs per stream) on next to the filter area to select fields.
Or expand the side panel area and display the field names below a stream and list there the possible fields.
For the start and experiment with it: The minimum option would be to set a list of fields during server startup in the CLI (handy if you look just to journald logs ...). Or placing configs per stream name somewhere.
Ah, and if one tells rtail the timestamp field (in my case with logagent-js and other tools working with Elasticsearch "@timestamp") - it could use the existing timestamp in JSON logs.
I suggest to add an option to render structured logs (e.g. JSON) as table view and select the most relevant fields to display (like "@timestamp","message","host","severity"). If one forwards e.g. journald JSON there are simply too many fields to see the most relevant "MESSAGE" field.
The text was updated successfully, but these errors were encountered: