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
>>>> >
>>>>
>>>

Reply via email to