Extended Events is an event-driven framework built for monitoring Windows server systems. It allows you to correlate data generated from events within SQL Server and can also, in some cases, correlate data generated from the operating system and the applications running on it. In order for you to correlate the data gathered from within SQL Server with outside applications your event output must be directed to Event Tracing for Windows (ETW). The Extended Events architecture can be broken up into 5 main concepts. These are:
An Extended Event package is simply a container for the objects used by Extended Events. It contains all the metadata for the objects that exist within Extended Events. When creating an Extended Events session you can use objects from one or more packages and there are many different packages available. Querying the sys.dm_xe_packages view you can get a listing of all of the available packages.
In many cases, when troubleshooting or monitoring SQL Server, most of the objects required will be in one of the following packages:
If you are looking to for more information for a specific feature within SQL Server some of these have their own package as well. A few examples of these are SecAudit, filestream and sqlclr. As mentioned earlier for a complete list of what's available you can query the sys.dm_xe_packages view.
Because an Extended Events session can contain objects from multiple packages a package does not need to contain all types of objects. For example, you can have a package that only contains events and actions and when you create a session you just use one of the targets defined in the default package. That said here is a list of the types of objects that a package can contain any or all of:
An event is pretty self-explanatory. It's basically a point of execution within your program, in this case SQL Server, that you are interested in tracking. When an event fires along with the time the event occurred (and the inherent fact that the event occurred) the state information is also logged. The state information is stored in a versioned schema and once a package is registered with Extended Events the set of events and their definition cannot be changed. What can be changed though is the consumer of the event does not have to consume all of the state information in the schema, it can just use what it needs. Also, once registered, these events can be used for tracing your application as well as for triggering other events which can be either synchronous or asynchronous. It is important to note that Extended Events also use an event categorization model. This model is similar to the one that is used for Event Tracing for Windows (ETW) mainly so that these two tools can be integrated. The two event properties used for categorization are channel and keyword. A channel identifies the audience of the event and can be one of Admin, Operational, Analytic or Debug. The keyword is application specific and can be used to group related events.
A target is the event consumer. Extended Events provide multiple targets that can be used to direct event output to a file, memory buffer or aggregate event data. The way that Extended Events is designed guarantees that a target will receive an event only once per session. Event targets can process events synchronously (Event file, Event pairing, Histogram, Ring buffer) or asynchronously (Event Tracing for Windows).
An action is a programmed response to an event. Actions must be tied to an event and each event can have its own unique set of actions. When an event fires each action is invoked synchronously. There are many different things that can be done within an action. This can include aggregating or appending to event data, storing state information or capturing a stack dump.
The type object is what defines what is contained in the event data string. The following types are provided for package objects:
Predicates are sets of rules that are used to evaluate events when they fire. Predicates allow Extended Events to filter the captured event data on specific criteria. Predicates can also store local context information which allow them to only fire on a specified time interval or after a specified number of times the event fires. This allows you to reduce the amount of data collected when each event contains similar data.
A map table maps an internal numeric value to a more descriptive string which makes it easier for users to under the event data. A complete list of map values can be queried in the sys.dm_xe_map_values view.
As mentioned earlier, targets are the event consumers and events are consumed by a target either synchronously or asynchronously. An important thing to note is that the database engine will disconnect from any synchronous extended events session that is processing data too slowly so that database performance is not affected by the session. It’s because of this that most targets, especially ones that can perform some extra processing/filtering, are asynchronous. Below is a short description of each of the different targets.
The Extended Events engine does not do any processing of events or perform any actions when an event fires. The engine is actually a collection of services and objects that handle the management of the SQL Server Extended Events sessions. It enables you to define events, enables processing of events, manages services and objects in the system and also maintains a list of Extended Events sessions.
Each Extended Events session is created within the SQL Server process hosting the Extended Events engine. Throughout the lifecycle of a session it can be in any one of the following states.
Even though events and targets can be used in multiple Extended Events sessions, each session is confined to its own boundary. That is, the configuration of one session cannot be affected by and also cannot have any effect on another sessions configuration. The following diagram taken from this link explains this concept.
SQL Server provides the following tools that you can use to create and manage extended events sessions.