Extension:EventLogging/Status

Temporary? placeholder for status of EventLogging on Wikimedia Foundation wikis.

Current status

 * 2013-01-15T00:00
 * client-side-events-json.log has not updated since 2013-01-14 21:29 (UTC)
 * client-side events are not updating SQL tables on stat1.


 * vanadium packet-loss-8421 reports lots of packet gaps, perhaps these are old-style ClickTracking events going out on the same port as the shiny clean ServerSideAccountCreation events

Client-side

 * Client-side requests to bits.wikimedia.org/event.gif are routed from varnish web request buffers to emery
 * emery logs these and re-logs them to vanadium (on UDP port XXX)
 * vanadium
 * logs these to /var/log/eventlogging/client-side-events.log
 * publishes them using ZeroMQ on TCP port 8484
 * There are various subscribers to TCP port 8484
 * vanadium zmq2log converts these to readable JSON and logs to /var/log/eventlogging/client-side-events.log
 * vanadium json2sql load these events into tables in the staging DB on s1-analytics-slave.eqiad.wmnet (accessible from stat1)
 * on stat1, spage logs these client-side events to ~spage/vanadium_8484
 * every event has a sequence number. vanadium seqmon detects gaps in this and writes to packet-loss-8422.log (??)

Server-side (event logging)

 * Server-side writes log lines to a log "file" that is routed to emery
 * emery logs these and re-logs them to vanadium
 * vanadium
 * logs these to /var/log/eventlogging/server-side-events.log
 * publishes them using ZeroMQ on TCP port 8421
 * There are various subscribers to TCP port 8421
 * vanadium zmq2log converts these and logs to /var/log/eventlogging/server-side-events.log
 * on stat1, spage logs these server-side events to ~spage/vanadium_8421
 * every event has a sequence number. vanadium seqmon detects gaps in this and writes to packet-loss-8421.log

Server-side (old-style ClickTracking)
Who cares.
 * These are written on the same UDP port as clean EventLogging events.