I am using Lttng in an application. I have enabled heavy traces and I have found that there is a loss in traces. Is there any way of knowing if there is any trace loss or any information regarding about it . Are there any API calls to know about them.
Thanks & Regards.,
K.V.Ranganadh.
Both viewers for LTTng traces should both be able to report if a trace has lost events in them.
Babeltrace, the command-line trace reading tool, prints lost events on stderr. So a quick way to locate these is to reroute stdout elsewhere, so you only see the lost events in the console, using a command like:
babeltrace /path/to/trace > /dev/null
Alternatively, the graphical viewer Trace Compass displays lost events in its Statistics View.
In general, lost events happen when the machine is too loaded and the tracer cannot keep up with the events coming in. To reduce the chance of losing events, you can look at increasing the subbuffer sizes and number (see the 'lttng' man page), or enabling less events in your tracing session (instead of doing 'lttng enable-event ... -a', only enable the events you need).
Related
Being new to systematic debugging, I asked myself what these three terms mean:
Debugging
Profiling
Tracing
Anyone could provide definitions?
Well... as I was typing the tags for my question, it appeared that stack overflow already had defined the terms in the tags description. Here their definitions which I found very good:
Remote debugging is the process of running a debug session in a local development environment attached to a remotely deployed application.
Profiling is the process of measuring an application or system by running an analysis tool called a profiler. Profiling tools can focus on many aspects: functions call times and count, memory usage, cpu load, and resource usage.
Tracing is a specialized use of logging to record information about a program's execution.
In addition to the answer from Samuel:
Debugging is the process of looking for bugs and their cause in applications. a bug can be an error or just some unexpected behaviour (e.g. a user complains that he/she receives an error when he/she uses an invalid date format). typically a debugger is used that can pause the execution of an application, examine variables and manipulate them.
Profiling is a dynamic analysis process that collects information about the execution of an application. the type of information that is collected depends on your use case, e.g. the number of requests. the result of profiling is a profile with the collected information. the source for a profile can be exact events (see tracing below) or a sample of events that occured.
because the data is aggregated in a profile it is irrelevant when and in which order the events happened.
Tracing "trace is a log of events within to the program"(Whitham). those events can be ordered chronologically. thats why they often contain a timestamp. Tracing is the process of generating and collecting those events. the use case is typically flow analysis.
example tracing vs profiling:
Trace:
[2021-06-12T11:22:09.815479Z] [INFO] [Thread-1] Request started
[2021-06-12T11:22:09.935612Z] [INFO] [Thread-1] Request finished
[2021-06-12T11:22:59.344566Z] [INFO] [Thread-1] Request started
[2021-06-12T11:22:59.425697Z] [INFO] [Thread-1] Request finished
Profile:
2 "Request finished" Events
2 "Request started" Events
so if tracing and profiling measure the same events you can construct a profile from a trace but not the other way around.
source
Whitham: https://www.jwhitham.org/2016/02/profiling-versus-tracing.html
IPM: http://ipm-hpc.sourceforge.net/profilingvstracing.html
I receive letting_statedump events when I enable these events and start the tracing. I noticed that I receive this only once for the life of the trace session. How would I initiate the generation of statedump events without stopping the trace and restarting?
As far as I know, there is no way at the moment to trigger a statedump manually.
However I would ask, why would you need to do so? The goal of the statedump is for trace viewers or analysers to be able to have an idea of the initial state of the system. Afterwards, they can use the actual trace events to update their state trackers.
If you do not wish to write your own state tracker, another option that may help are the event contexts. If you enable a context like pid or procname, that information will be dumped as part of every trace event. This can be used to get up-to-date state information more easily. You can use
lttng add-context --help
to list the available contexts.
I am absolutely not familiar with WebSphere and haven't found anything about this within the last 30 of minutes web research.
Is there a view where i can obtain a list of server events such as starts-, stops- or restarts in the web console of a WAS 8.5 application server?
What i tried:
30 Minute Web research.
My workaround :I always used our Splunk to filter for example "Starting Application..." to identify the time a Application was started based on the log events. I apply similar filters to recognize server restarts.
By default there is no such view. There are at least 2 potential solutions, that you could use, but your workaround might be easier ;-) :
Enable Runtime Messages
In the web console go to Troubleshooting > Runtime Messages > Runtime information.
Enable Info level, save and restart. Then you will be able to filter massages using filter in the table and providing message fragment.
Use HPEL logging and filtering
You can switch default logging to HPEL in the Logging and tracing > server1 > Switch to HPEL. After that your logging will be done in binary form (much better performance) and you will be able to do searches based on the event code, message content etc. You will be able to view log either from the console Logging and tracing > server1 > JVM Logs > Runtime with search/filtering capability, or from command line using logviewer tool. Tool can be used a bit like tail/grep combination and print only relevant information or information from specified application. In this case you will also be able to view past events also, as in Runtime messages you see only events from server startup.
Custom MBean listener
You could write code to listen on events generated by the server, but probably too much effort for your need.
See also:
Runtime events
HPEL overview
LogViewer tool
I'm trying to found a more detailed and focused way to get error message from views in Tryton Client for speed development. I'm using
tryton -v -d -l DEBUG
but only bring UNICODE strings arriving to client. Is there a better approach?
I usually work with eclipse and pydev plugin. The installation is the same as OpenERP [1].
[1] http://domatix.com/entorno-desarrollo-eclipse-openerp-parte-tres/
Just like the client, the server can be run in verbose mode where stack traces are sent out to stderr and stdout. But this stack trace is no different from the unicode stack trace displayed by the tryton client. So the better way to debug once you find such an error would be to set a breakpoint around the code where the stacktrace frame indicates the exception occurred.
See: https://pythonconquerstheuniverse.wordpress.com/2009/09/10/debugging-in-python/ for a quick guide on pdb if you are using pdb for the first time.
OTOH, if you want to capture more information in production when exceptions occur, use the trytond-sentry integration module(See: http://www.openlabs.co.in/article/sentry-tryton-v-1-0)
We have a system where there are typically two processes running on the same system. One process handles the GUI and the other runs like a service (although for historical reasons, it's not a service, just an exe with no visible window).
The two processes undertake IPC mainly via registered messages asynchronously - i.e. we use RegisterWindowMessage() in both processes to define a large'ish set of messages that effectively form the API to the server process.
I have written a "hands-free" monitoring application that uses SetWindowsHookEx() to monitor and display the message queues of both processes and provide some level of decoding of the way the API is being utilised and how notifications are being propagated to the GUI process (each individual window can subscribe to notifications from the server directly).
So, there are a large number of messages in both directions so I have filtering and summary counts etc. so I can focus on particular activity. All this can be done without affecting the live code, which is good.
This all works well, but it now would be very useful to be able to "tag" a message originating in the GUI so I can trace the same message when it's processed by the server. This would be enormously useful for debugging and diagnosing system issues, but I can't find a clean way (actually I can't find any way!) of doing this without adding such support to our registered message API, which would be a lot of work and involves more risk than I'm comfortable with at the moment. It gets further complicated by the fact that the server pre-processes some messages and then does a PostMessage() back to itself to perform the action, so the originating message can get "lost".
Has anyone here tackled this type of problem? If so, can you give me some pointers? If not, then are there any documented or undocumented ways of adding a small block of data to a Windows message and retrieving it later? I've looked at SetMessageExtraInfo() but that seems to be per-queue rather than per-message.
FindWindow or FindWindowEx will give you the details of the GUI Window. Compare the details with message intercepted