In the previous article in this series I shared the basics around assembling an XEvent session. The method used in that article was via TSQL script. In this article, I will introduce the Extended Events GUI. While I prefer to use TSQL to create and manage my sessions, the GUI can help to visually better understand some of these concepts.

If you are a bit behind in the series, here is the table of contents so you can get caught up again. Now is as good a time as any to catch up on the series. right?

As I was saying, I prefer to use TSQL to create my XEvent Sessions. The biggest reason being that a script can be saved and used to easily recreate the session on multiple servers. The next big reason is that the script can also explain exactly what is being done to create the session. With the Extended Event GUI, extra steps need to be taken to ensure the session will be created as desired (albeit small steps but extra nonetheless). The third big reason I prefer to use a script is that the GUI was not available until SQL Server 2012.

The GUI

Gaining access to the Extended Events GUI is rather easy to do from within SSMS. Simply expand the Management Node and then the Extended Events node. Once there, right click “Sessions” and select “New Session…” or “New Session Wizard” from the context menu. Here is a nice visual on that with the following image.

The option I will focus on is the “New Session…” option. I would hope that the Wizard is avoided if the GUI must be used to create sessions. Once “New Session…” is selected, the following screen will be presented to you:

In this image, I have color coded some of the sections of this screen to match the previous article and the components previously discussed. From this screen, one will not be able to see all of the components that compose an Extended Event Session. To reach the remaining components, a little more digging is necessary.

Also of importance is to note that a warning will pop up on this screen that after giving the session a name, the minimum requirements to create an XEvent Session have not been met. The minimum requirements being that a name and event be supplied to the session. Nothing said about the remaining components. This is a small niggle for me in that, while technically an Action and a predicate are optional, a target really should be defined (more on that in a bit). I also recommend that predicates be used because of the benefit to performance and event collection they can provide.

After giving the session a name, it is required to click “Events” highlighted in that orange-ish color in the previous image. This will bring up the next screen:

This screen will present you with many options / events that can be used in the session. In this example I have chosen the auto_stats event. By double-clicking the event or single-clicking then clicking the arrows between panes, the event will be selected and populate the right hand pane. Though hard to tell from this image, after the event is selected, the OK button becomes enabled and the session creation can be concluded here. I recommend not clicking that OK button – ever.

At this point, find the “Configure” button in the top right of the screen. This will bring us to the additional components that have been hidden from view to this point.

On the new screen, we can see the Actions and Predicates – color coded for ease of tying these components together as was done previously. A note on the Actions tab is that they are called “Global Fields” here with “Actions” in parenthesis. These actions can be viewed as “fields” that can be applied globally to many events.

After perusing the list of Actions, next up is Predicates/Filters. Clicking that tab will produce a screen like this:

Here I can select from any of the fields attached to the event payload or the Actions seen on the previous screen. This gives me the chance to configure multiple filters for this event to meet my specific requirements.

Next up is the Event Fields tab. This is the event payload.

In this image I have circled an interesting item in the payload. This item has a checkbox. This means the item is one of those boolean data types that is “customizable”. When I select this item, it performs a “SET” operation within the creation of the Event Session. I will speak more to that in a moment.

Let’s now turn our attention to the next screen – Data Storage.

When I open this screen, I will have multiple options in the type menu. For this example, I have only selected the event_file target. Once selected, there will be target specific options that populate the bottom section of the screen. In this case, I need to give the target file a name. I can supply a path or just a name. If I supply just the name, then the target will be created in the default “log” directory for the instance. If no target is specified, then a default target will be used. This is the event_stream target aka “Asynchronous live stream target.” I recommend specifying a target so the data can be stored and evaluated at a later time.

And now I will conclude with the Advanced options. While these are optional settings with defaults in place for them, I recommend at least taking a look to understand what options are available.

I won’t explain these options just yet. This is just for reference and introductory purposes. After looking at this screen, click “Script” and then Cancel. As I mentioned previously, I prefer to use scripts instead of the GUI. If the GUI is necessary, then script the session and evaluate the script. This is the “minor” additional step mentioned earlier.

Now looking at a sample script generated from the GUI:

In this script, I added an additional target, and multiple Actions over what was shown in the images for this demo. Apart from that, the rest remains the same. I color coded each segment of the script to not only map to the components of an Extended Event Session, but also to the color coded screens in the examples. In addition, I added notes about some of the “SET” operations and on which screens those can be found.

I have just shown how to configure a single event within an Event Session. It is important to mention that the configuration screen (with actions and predicates) needs to be done separately for each of the events within the session. This is reinforced by the script where it shows the Predicate and Actions are directly attached to the Event. This makes using the GUI a bit repetitive and slow if deploying several Events within a Session.