Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>On live systems we rarely trace to shell. If the system is well configured then it is already collecting your Erlang logs that were printed to the shell. I need not emphasize why this is crucial in any live node...</p> <p><strong>Let me elaborate on tracing to files:</strong></p> <p>It is possible to trace to file, which will produce a binary output that can be converted and parsed later. (for further analysis or automated controlling system, etc.)</p> <p>An example could be:</p> <ul> <li><p>Trace to multiple files wrapped (12x50 Mbytes).<strong>Please always check the available disk space before using such a big trace!</strong></p> <pre><code>dbg:tracer(port,dbg:trace_port(file,{"/log/trace",wrap,atom_to_list(node()),50000000,12})). </code></pre> <p><code>dbg:p(all,[call,timestamp,return_to]).</code></p> <ul> <li>Always test on a test node before entering anything to a live node's shell!</li> <li>It is most advised to have a test node or replica node to try the scripts first.</li> </ul></li> </ul> <p><strong>That said let's have a look at a basic tracing command sequence:</strong></p> <p><strong>&lt;1></strong> <code>dbg:stop_clear().</code></p> <ul> <li>Always start by flushing trace ports and ensuring that no previous tracing interferes with the current trace.</li> </ul> <p><strong>&lt;2></strong> <code>dbg:tracer().</code></p> <ul> <li>Start the tracer process.</li> </ul> <p><strong>&lt;3></strong> <code>dbg:p(all,[call, timestamp]).</code></p> <ul> <li>In this case we are tracing for all processes and for function calls.</li> </ul> <p><strong>&lt;4></strong> <code>dbg:tp( ... ).</code></p> <ul> <li>As seen in Zed's answer.</li> </ul> <p><strong>&lt;5></strong> <code>dbg:tpl( ... ).</code></p> <ul> <li>As seen in Zed's answer.</li> </ul> <p><strong>&lt;42></strong> <code>dbg:stop_clear().</code></p> <ul> <li>Again it is to ensure that all traces were written to the output and to evade any later inconvenience.</li> </ul> <p><strong>You can:</strong> </p> <ul> <li><p>add triggers by defining some fun()-s in the shell to stop the trace at a given time or event. Recursive fun()-s are the best to achieve this, but be very careful when applying those. </p></li> <li><p>apply a vast variety of pattern matching to ensure that you only trace for the specific process with the specific function call with the specific type of arguments...</p></li> </ul> <p>I had an issue a while back, when we had to check the content of an ETS table and on appearance of a certain entry we had to stop the trace within 2-3 minutes.</p> <p>I also suggest the book Erlang Programming written by Francesco Cesarini. (<a href="http://rads.stackoverflow.com/amzn/click/0596518188" rel="noreferrer">Erlang Programming @ Amazon</a>)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload