The easiest way of using ET, is to just use it as a graphical tool for displaying message sequence charts. In order to do that you need to first start a Viewer (which by default starts a Collector):

Then you send events to the Collector with the function et_collector:report_event/6 like this:

The Viewer will automatically pull events from the Collector and display them on the screen.

The number (in this case 85) is an integer from 1 to 100 that specifies the "detail level" of the message. The higher the number, the more important it is. This provides a crude form of priority filtering.

The from, to, and message parameters are exactly what they sound like. from and to are visualized in the Viewer as "lifelines", with the message passing from one to the other. If from and to are the same value, then it is displayed next to the lifeline as an "action". The extra_stuff value is simply data that you can attach that will be displayed when someone actually clicks on the action or message in the Viewer window.

The module et/examples/et_display_demo.erl illustrates how it can be used:

When you run the et_display_demo:test(). function in the example above, the Viewer window will look like this:

The event tracer framework is made up of four modules:

In addition, you'll probably want to familiarize yourself with the dbg module and possibly seq_trace module as well.

The et module is not like other modules. It contains a function called et:trace_me/5. Which is a function that does not do any useful stuff at all. Its sole purpose is to be a function that is easy to trace. A call to it may be something like:

The parameters to et:trace_me/5 are the same as to et_collector:report_event/6 in the previous chapter. The big difference between the two is in the semantics of the two functions. The second actually reports an Event to the Collector while the first does nothing, it just returns the atom hopefully_traced. In order to make the parameters to et:trace_me/5 turn up in the Collector, tracing of that function must be activated and the Collector must be registered as a Tracer of the Raw Trace Data.

Erlang tracing is a seething pile of pain that involves reasonably complex knowledge of clever ports, tracing return formats, and specialized tracing MatchSpecs (which are really their own special kind of hell). The tracing mechanism is very powerful indeed, but it can be hard to grasp.

Luckily there is a simplified way to start tracing of et:trace_me/5 function calls. The idea is that you should instrument your code with calls to et:trace_me/5 in strategic places where you have interesting information available in your program. Then you just start the Collector with global tracing enabled:

This will start a Collector, a Viewer and also start the tracing of et:trace_me/5 function calls. The Raw Trace Data is collected by the Collector and a view of it is displayed on the screen by the Viewer. You can define your own "views" of the data by implementing your own Filter functions and register them in the Viewer.

These two pieces work in concert. Basically, the Collector receives Raw Trace Data and processes it into Events in a et specific format (defined in et/include/et.hrl). The Viewer interrogates the Collector and displays an interactive representation of the data.

You might wonder why these aren't just one module. The Collector is a generic full-fledged framework that allows processes to "subscribe" to the Events that it collects. One Collector can serve several Viewers. The typical case is that you have one Viewer that visualizes Events in one flavor and another Viewer that visualizes them in another flavor. If you for example are tracing a text based protocol like HTML (or Megaco/H.248) it would be useful to be able to display the Events as plain text as well as the internal representation of the message. The architecture does also allow you to implement your own Viewer program as long as it complies to the protocol between the Collector/Viewer protocol. Currently two kinds of Viewers exists. That is the old GS based one and the new based on wxWidgets. But if you feel for it you may implement your own Viewer, which for example could display the Events as ASCII art or whatever you feel useful.

The Viewer will by default create a Collector for you. With a few options and some configuration settings you can start collecting Events.

The Collector API does also allow you to save the collected Events to file and later load them in a later session.

This is perhaps the most central module in the entirety of the et suite. The Collector needs "filters" to convert the Raw Trace Data into "events" that it can display. The et_selector module provides the default Filter and some API calls to manage the Trace Pattern. The Selector provides various functions that achieve the following:

The Trace Pattern is basically a tuple of a module and a detail level (either an integer or the atom max for full detail). In most cases the Trace Pattern {et,max} does suffice. But if you do not want any runtime dependency of et you can implement your own trace_me/5 function in some module and refer to that module in the Trace Pattern.

The specified module flows from your instantiation of the Viewer, to the Collector that it automatically creates, gets stashed in as the Trace Pattern, and eventually goes down into the bowels of the Selector.

The module that you specify gets passed down (eventually) into Selector's default Filter. The format of the et:trace_me/5 function call is hardcoded in that Filter.

The Collector automatically registers itself to listen for trace Events, so all you have to do is enable them.

For those people who want to do general tracing, consult the dbg module on how to trace whatever you're interested in and let it work its magic. If you just want et:trace_me/5 to work, do the following:

The module et/examples/et_trace_demo.erl achieves this.

Running through the above, the most important points are:

When you run the et_trace_demo:test() function above, the Viewer window will look like this screenshot: