Community
Participate
Working Groups
As highlighted in mattermost discussion [#1], we should find a way to integrate logs (lightweight traces) in the IDE. The user should be able to save a log (trace). Then, another user should be able to load the saved log, and see it in a debug like view, so you can virtually step through it. [#1] https://mattermost.eclipse.org/eclipse/pl/iryxqftdnidnzq7yz3ij1a5poy
(In reply to Patrik Suzzi from comment #0) > ... and see it in a debug like view ... Why a "debug-like"? Given that the logs can be also thread dumps (I actually do lot of thread dumps analysis) it would be cool to see the *Debug* view containing that dump or stack. Something similar what the JUnit view does - it allows you to "Import" a junit xml file and see/navigate through all the data for your tests.
Note that in this case we are not talking about the .log file in eclipse that includes mostly errors, but the logs as being used to capture what is going on at runtime (think slf4j). Andrey, the two use cases are complementary. The first one tries to answer to the question: "Why is my program behaving this way?" (because it does not do what it is expected to do) and hopefully with enough logs one is able to figure that out. To that extend, I see this as being similar to debugging a program where you go from one instruction to the next, except that in this case you would go from one log entry to the next. Now if you also manage to capture the value of some variable / or parameters, you can see that showing the value in the variable view could also be nice. The second case where you have stacktraces answers to the question "Why did it crash in prod?" and even though the junit view seems the "typical" place where you show stacktraces, you may need to get more info about the why you got here.
I've been meaning to try logback-beagle, a view for logback-based logging: http://logback.qos.ch/beagle/ Doesn't load logs post-hoc though.
Eclipse Trace Compass has been mentioned in the mattermost discussion and I'd like to give some clarification about what it can do and why it could be an option for viewing logs from Eclipse plug-ins. One observation I made is that Trace Compass is perceived to be Linux specific. It's true that many visualizations are available for traces coming from Linux. However, Trace Compass was designed to be able to integrate with many formats of logs and trace types. It already has some trace parser integrated (Common trace format, libPcap, BTF from OSEK and GDB tracepoint). Beside that it's possible to create parser for text formats on-the-fly using a parser wizard that comes with Trace Compass. The Trace Compass project added tracepoints (JUL logging) into it's code base to analyze Trace Compass with Trace Compass, e.g. do timing analysis on how long it takes to analyze and visualize a Linux Kernel trace in a certain view. It would be interesting to analyze other logs coming from Eclipse project. Certain log parsers can be created to show the data in Trace Compass. Secondly, I think Trace Compass is perceived to be able to show mainly raw data, i.e. log viewing and the user needs look for the "needle in the haystack" mentioned before. However, Trace Compass offers a way to analyze and visualize beyond showing the raw data in a table. There ways to measure execution times, show them in distribution or scatter charts, show state of entities over time and so on. These analysis can be defined on-the-fly using XML description as well as as Java extension. One of my colleagues wrote a parser to load maven output logs into Trace Compass and measure the duration of each build step. It is also possible to look at call stacks and generate flame graphs when analyzing traces containing function entry and function exit information. Right now there is a reference implementation for Linux UST traces. However, there is currently an effort to make customizable for other trace formats. Long story short, I think there is potential to use Trace Compass for analyzing logs generated from Eclipse plug-ins and analyze the data further. We just need to invest some time to provide these log parsers and to customize the existing visualizations in Trace Compass.
As Bernd said, we've been doing some work on analyzing TraceCompass with Trace Compass using JUL log records. Just to give an idea of what can be done, we wanted to analyze how the various view threads were interacting and how much time was spent querying the backend. We obtained a trace with the logs that we could read (depending on the log format, we can add a custom text or XML parser to read the file). Then added XML-defined analyzes that allowed us to visualize our program's behavior. I presented that at the Tracing Summit in october. The slides are here and contain some screenshots of the results http://tracingsummit.org/w/images/8/8b/TracingSummit2016_JUL.pdf But the very first step here (once the logs are available) would be to define the log parser, whether slf4j, JUL or other format and records and fields can be visualized in an event editor.
(In reply to Patrik Suzzi from comment #0) > [#1] https://mattermost.eclipse.org/eclipse/pl/iryxqftdnidnzq7yz3ij1a5poy The discussion is not publicly available. One needs a mattermost account to access it :(
(In reply to Genevieve Bastien from comment #6) > (In reply to Patrik Suzzi from comment #0) > > [#1] https://mattermost.eclipse.org/eclipse/pl/iryxqftdnidnzq7yz3ij1a5poy > > The discussion is not publicly available. One needs a mattermost account to > access it :( Anyone can create a Mattermost account :)
