Jason Brimhall has two recent blog posts on figuring out Extended Events information. First is a republication of an older article:
First let’s tackle the problem of discovery. When we want to use extended events to try and troubleshoot a problem or to capture more information, it is really good to know if such an event exists. There are many events that capture data for various different things within SQL Server. More and more events are being added with each release. More and more data is being made available to the DBA to help perform a better job and to help the DBA better understand what is really happening within the database environment.
In order to determine if there might be an event, that can provide the data for that one “thing” that may be happening within your environment, we could start by querying the SQL Server Internals. This next query will do just that for us.
After you read that article and check out the queries there, Jason has another post on finding the right event:
In my previous article I demonstrated how to find an event based solely on the name or description of the event. This is fantastic if the event name (or description) contains one of the magical words you have used. What if the event name or description has nothing to do with the terms you selected? Or, what if the data you seek may be attached to the event but wouldn’t necessarily stand out as a description for that event (by name or description details for that event)?
Now comes the more difficult task right? If the name or description of the event doesn’t relate to the search terms then you just might overlook a few events and be stuck trying to troubleshoot a problem. An equally big problem this could cause is yet another invisible barrier to using Extended Events. It would be easy to slide down the slippery slope and not transition to Extended Events just because an event, applicable to the problem at hand, could not be found.
Check out both of these posts.