I'm guessing @fdans or @Ottomata would be the right people to talk to about this (see T185233)

for more info: https://phabricator.wikimedia.org/T185233

See also:
Event Platform - Product Usage design document and https://wikitech.wikimedia.org/wiki/Event_Platform and its subpages.

We are just starting to work on EventLogging Analytics quote 'replacement' unquote (don't worry we aren't making it go away any time soon). More and more documentation forthcoming as we figure it out, but I'm happy to jump in a hangout sometime and talk.

We probably won't be ready to send events from client side until sometime Q3 at the earliest, so if you need to start collecting these measurements before then you should probably keep using EventLogging. However! We are looking for some new instrumentation use case early adopters, in case you want to sign up for that :) Ping @kchapman

Okay. I took a stab at this in Sam's absence. I've tried to simplify this analysis as much as possible from a reading web POV (so have purposely omitted details about the underlying technologies of the new system, which don't seem important from our POV)... I would appreciate scrutiny from another team member and/or analytics to point out anything I may have missed or misunderstood.

How is the eventlogging pipeline changing?

• Schemas are going to be moved to git. We will set the schema up in a single repo. A config change will then be needed to activate it. We will continue to write event producing application code (using provided APIs)
• There will be new JS inside the EventLogging extension - a client library will be provided as part of https://phabricator.wikimedia.org/T228175
• We won't need to write our own config - that will be built in.
• We will also be able to define timeframes for eventlogging to run

This feels very similar to our current approach, just using different repos however it's exciting to see we'll have to worry less about things such as sampling and enabling experiments which will be handled by the platform.

Would this affect the way we write schemas and the things we are capable of measuring?

It sounds like we'd be able to measure the same things, but the platform will become more reliable as we will not have to spin up our own versions of sampling. I don't think it impacts the way we write schemas.

What impact would these changes have on our current instrumentation?

The only changes I would advise is to take care when writing anything new that we maintain a clear separation of the code enabling the schema (and dealing with sampling) from the code producing events so that in future it will be easier for us to migrate to the new system. We currently use mw.track in our event producing code and it seems like we should continue to do so.

We will likely want to monitor progress in T228175 and write our application code in WikimediaEvents so that we keep in sync with the latest changes to the repo. If we were to work inside our own repos we may be at more risk of deviating from current best practices.

A think a big conceptual difference is the distinction between a schema and a stream. In EventLogging world, every 'schema' corresponds with a single dataset. This dataset starts out as an event stream but eventually makes it to a downstream datastore table. In Modern Event Platform world, these concepts are separated. You can think of a schema as the type of the dataset. Both the in flight event stream and the static downstream datastore tables share this type. Multiple dataset/stream/tables can share the same schema type.

A config change will then be needed to activate it

This is where the event stream will be declared. At a minimum, this config will declare the name of the stream and it's schema. All events destined to a stream must validated with the configured schema.

Schemas are going to be moved to git.

This will make the development workflow different than in EventLogging. Since schemas are in git, they are decentralized. You will be able to develop new schemas and instrumentation code using usual code development practices, instead of having to make edits to a production schema repository (on meta.wikimedia.org) before code changes can be implemented.

Just wanted to chime in here as I'm really glad to see these discussions getting started. In a couple of weeks I'm going to start reaching out to folks on Web to try and do a brief of where we are with the cilent, what exactly will be delivered and when we expect that to happen, and some kind of outline of what the new workflow will look like.

Like has been discussed, there will be changes, and there are things we know right now but also a few things that are still being decided. The aim of having this discussion will mostly be to start the process on our end of tailoring documentation, tools for convenient testing/debugging, and sketching out plans for starting to use the new features and/or porting old bits to use the new features.

It will also be a chance for engineers on Web to ask questions, contribute feedback, throw out ideas, chime in on integration plans, and generally get a better understanding of what's coming. That goes for our group too -- we're really interested to hear the team's thoughts. Hopefully this isn't redundant given this spike.

I am at an offsite this week but will try to get something scheduled in the next couple days for sometime... probably mid-November-ish. We'll have lots of artifacts, including code, for you to look at.