This list does not accept these attachments, please link to some other location.
Gary On Tue, Sep 26, 2023, 12:19 AM Scott Deboy <scott.de...@gmail.com> wrote: > Here's how it looks if you hide the tree - note the search results are at > the bottom. If you're not searching, that search area is hidden as well. > > Because it's parsing the log, you can filter on logger, level, the message > - any field resolved during parsing. > > The annotated lines show up as green by default. > > The UI supports multiple tabs (log sources) and will live tail for you as > well. > > Note the search results show up as blue in the log panel, and the gutter > on the right displays the individual line colors (black is a search match). > > > > On Mon, Sep 25, 2023 at 8:46 PM Scott Deboy <scott.de...@gmail.com> wrote: > >> Your screenshot didn't come through. >> >> My mental model is usually: >> >> * Hide logs from packages you know aren't relevant - the tree-based >> (package-level) filtering and focus-on actions in the tree are super >> helpful for doing that quickly >> * Once you've filtered the view down to the set of packages that may be >> relevant, hide logs that are getting in the way - via the 'always hide' >> expression box, available at the bottom of the tree view >> * Use filter expressions to further narrow results >> * Annotate those filtered results (the 'marker' column is editable) >> * Clear the filter and search the remaining results, annotating if needed >> * Optionally save off the logs and share with other devs (they can import >> your filtered logs) >> >> All of this and a lot more is possible with the existing set of features. >> >> UI-wise I agree, less is more most of the time. You don't need to parse >> the logs, you can put the entire log line in the 'msg' field, but that >> prevents you from using some expression support facilitated by the parsing, >> such as "level > INFO" or "exception exists". >> >> On Mon, Sep 25, 2023 at 7:28 PM Robert Middleton <rmiddle...@apache.org> >> wrote: >> >>> I do know that there are a bunch of settings to hide things that aren't >>> useful, I'm just saying that even hiding things I still don't find it super >>> useful. The table view that exists is theoretically useful, but I find >>> that it likes to cut off information because it is, well, a table. >>> >>> The VfsLogFilePatternReceiver I have never gotten to work properly. I >>> think it's good and needed, but it definitely needs a user-friendly way of >>> selecting a log file and viewing a live example of how it will parse the >>> log file. Although for my purposes, we don't actually write to a log file, >>> so it's a bit of a moot point. >>> >>> The next question of course is what do I feel would be better? I spent >>> some time working on that tonight as a proof of concept, and here's what I >>> came up with(with chainsaw in the background for reference): >>> [image: Screenshot from 2023-09-25 22-12-07.png] >>> >>> Note: this picture is from my VM, so it's definitely squashed since it >>> was running at a weird resolution so I could take the screenshot. But this >>> shows a good point: in this screenshot, only about 60% of the UI is >>> actually used to view logs. From the top there's the GNOME title bar, >>> title bar, file menu bar, toolbar, tabs, search bar, column headers, and >>> then we finally get to what chainsaw is supposed to do - display logs. >>> >>> What I've done is intentionally a proof of concept at the moment, but it >>> provides a much simpler view. Think of it like viewing logs on the >>> terminal, but adding in the capability to do more advanced operations(e.g. >>> what chainsaw does with the right-click context menu). The GUI is at the >>> moment just a JTextPane instead of a table, so that fields do not get cut >>> off(like they currently do in the table) and it can better scroll like a >>> real terminal when new messages come in. Right-clicking will open up a >>> pop-up menu contextually depending on what it is you have clicked on(the >>> time, logger name, level, or the message). >>> >>> Anyway, that's what I personally feel would be more useful, but I would >>> love to hear some other ideas. >>> >>> -Robert Middleton >>> >>> On Sat, Sep 23, 2023 at 11:35 PM Scott Deboy <scott.de...@gmail.com> >>> wrote: >>> >>>> Please review the various display setting controls. Most of what you >>>> mention can be toggled from visible to hidden. >>>> >>>> VfsLogFilePatternReceiver does exactly what you're describing. Allowing >>>> live remote tailing of logs over an ssh accessible path. >>>> >>>> You control if these logs end up in separate tabs or the same tab via >>>> the >>>> routing expression in preferences. >>>> >>>> We should slack sometime so I can go over the main features and what was >>>> nuked in the log4j1 removal path and what of those are worth restoring. >>>> >>>> Scott >>>> >>>> On Sat, Sep 23, 2023, 6:08 PM Robert Middleton <rmiddle...@apache.org> >>>> wrote: >>>> >>>> > Since Scott has said that he would help with maintenance and Rob T >>>> has also >>>> > indicated that he would perhaps help, this is my view of the current >>>> status >>>> > of Chainsaw and what I feel its current deficiencies are. >>>> > >>>> > Current status: Master builds and mostly works. The last thing that >>>> I had >>>> > been working on was updating the config files in order to remove >>>> xstream >>>> > and better standardize on using commons configuration. I think some >>>> of the >>>> > configuration settings don't save/load correctly, but some do. All of >>>> > log4j1 has been removed. Certain features have been removed too that >>>> were >>>> > largely dependent on log4j1. >>>> > >>>> > What I feel would be useful for Chainsaw: For me, I do a lot of >>>> embedded >>>> > work. Most of the log files that we have at my current job just go to >>>> > syslog on our device(syslog is provided by busybox). So viewing logs >>>> is a >>>> > matter of SSHing into the system and just reading from the buffer. >>>> Having >>>> > a utility running on a separate computer that lets me see the >>>> > logs(especially if it can connect automatically to a device) could be >>>> very >>>> > useful. Specific potential use-case: at my last job, I wrote a quick >>>> log >>>> > viewing utility that would correlate log messages between two separate >>>> > devices. This was needed because one device was embedded that logged >>>> out >>>> > the serial port, the other was Linux and would log over the network, >>>> but >>>> > neither had reliable time. >>>> > >>>> > Current limitations that I find with Chainsaw: The current GUI is not >>>> very >>>> > useful. A large portion of the screen is taken up by toolbars/context >>>> > information that I generally don't find useful. I think most of the >>>> > features that are in the GUI are very useful(for example, being able >>>> to >>>> > trace messages and add matches) but is limited by the fact that I >>>> only see >>>> > a small portion of the context at a time. In my mind, an ideal >>>> solution >>>> > would be to get rid of the toolbars as much as possible and to focus >>>> more >>>> > on the log messages like you would see in a terminal, but still >>>> having the >>>> > capability to right-click on a message/message components and >>>> investigate >>>> > individual messages or flag them appropriately. >>>> > >>>> > Perhaps the best way to organize this would be to have a logical >>>> split in >>>> > the code: the backend(which receives and routes log messages) and the >>>> > front-end portion. The front-end could be something like Swing for a >>>> GUI, >>>> > or some sort of command-line interface like ncurses. >>>> > >>>> > Thoughts? What is something that people want to see/think could be >>>> > useful/would want to try and code up? >>>> > >>>> > -Robert Middleton >>>> > >>>> >>>
