SeeExtension:EventLogging/Guide for a comprehensive introduction to EventLogging, developing and deploying EventLogging schemas, and more.

After you havecreated a schema, you must add an entry to $wgEventStreams stream configuration, and also to $wgEventLoggingStreamNames. $wgEventStreams is where your event stream is declared, and it specifies which schema the events in the stream have. $wgEventLoggingStreamNames registers the stream for use with the EventLogging extension. Seehttps://wikitech.wikimedia.org/wiki/Event_Platform/Instrumentation_How_To for more in depth instructions.

• The WikimediaEvents extension has working code to log server-side events in PHP inincludes/WikimediaEventsHooks.php.

• require your schema wherever you need to log events (it will pull in theext.eventLogging module which contains themw.eventLog object).
• Seemw.eventLog for API documentation.

Seedoc.wikimedia.org: EventLogging debug.js for API documentation.

• Client-side event logging works by sending POST HTTP request to$wgEventLoggingServiceUri with the JSON events in the POST body. To see the log events you can
  • watch for this request in your browser's network console,
  • look for it in your web server's access logs, or
  • run the toy web serverserver/bin/eventlogging-devserver in the EventLogging extension which pretty-prints the query string.

• An alternative to the above is to enable the more user-friendly debugging UI introduced inGerrit #I1ac4a5, which will show a popup notice for each event and also log them to the console. Currently, the debugging UI is shipped to all users but is enabled via a hidden user preference, which can only be set by pasting the following into your browser's JavaScript console:

mw.loader.using('mediawiki.api').then(()=>newmw.Api().saveOption('eventlogging-display-web','1'));

• You can useeventlogging-display-console instead ofeventlogging-display-web in the above snippet to enable console logs without the popups. Use the same snippets withnull instead of'1' to disable.
• To monitor events after processing, you can append anthen callback after alogEvent call, for example:

mw.eventLog.logEvent('MySchema',{foo:'bar'}).then(()=>{console.log('A MySchema event has been sent!');// All validation errors will have been tracked via the// 'eventlogging.error' topic. Since I0bf3bd91, however, there's no// easy way to detect if the event that was logged was valid.},()=>console.warn('Couldn\'t log the MySchema event!'));

Often you want to log clicks on links. If these take the user away from the current page, there's a chance that the browser will move to the new page before the request for the beacon image makes it onto the network, and the browser will drop the request.The E3 team experimented with using deferred promises to deal with this, but that introduced known and unknown unknowns.T44815 is related to this issue.

There are significant performance concerns regarding logging before showing the next page and our recommendation is not to do that until the new beacon API becomes available[1]. Details on performance issues can be found here:https://bugzilla.wikimedia.org/show_bug.cgi?id=52287

• wikitech:Event_Platform/Instrumentation_How_To
• Extension:EventLogging/Guide: comprehensive guide
• wikitech:EventLogging: WMF'sevolving network architecture that routes events from beacon image requests to databases