ETW is a system built into Windows that accepts events from a provider and routes the events to any consumers that are interested in them.
The provider identifies its events with a provider GUID, event level, and event keyword (categories), and just sends them to ETW. If nobody is interested in the event, ETW ignores it. (One of most important things about ETW is how efficiently it can ignore events.)
The consumer creates an ETW listening session and tells ETW the GUID, level, and keyword of the events it wants to record. ETW then collects any events matching the request and sends the matching events to the consumer. The consumer can ask ETW to put the events into a file. The consumer can also ask ETW to deliver the events in real-time as they occur. The consumer can also ask ETW to just save the most recent N megabytes of events in memory, and then upon request it can save those events to disk.
Because there are thousands of components that all write events to ETW, it is possible to mix data from your program together with information from other event sources.
The main benefit of ETW comes from being able to start consuming events without needing to interact with the program that creates the events. You just tell ETW "please collect events X, Y, and Z", and ETW figures out how to turn those events on and send them to your file. However, this is a very powerful feature, so it requires higher privileges. In addition, it has a fairly significant resource cost, so we only want to be collecting data when we're conducting a specific investigation (we don't just want to always start logs).
Of special note, the default Windows system can only have 64 log collection sessions running at a time. The limit can be raised by changing a registry key and rebooting, but Microsoft wants to keep it at a low level to help avoid letting people go crazy with too many sessions since the sessions use system resources.
TraceLogging is a specific kind of ETW. In other kinds of ETW, you have to figure out how to decode the event by looking up an XML manifest or a WPP PDB file, and you have to edit the XML file to add your new event before you can generate it. TraceLogging is easier because you never have to find anything to decode the event -- the information needed for decoding your event is always right there in the ETL log file. Also, you don't need to edit an XML file to add a new event -- you just write the code to generate the event.
Like most other kinds of ETW, TraceLogging is designed around structured data, like fields of a struct. TraceLogging event providers have a name, each TraceLogging event has a name, and each field in the event has a name and a type. So you use your provider to log an event with a name, and several fields with names and values.
Contrast this with some other logging systems (and the WPP flavor of ETW) which are designed around message strings. In those systems, you log a message, potentially containing values inserted into the message. This can be easier to read as a story, but it's harder to analyze.
