Strawman Demo of EventLogging #1
Conversation
This removes the consent GUI screen since I couldn't figure out how to make that work
This lets me play with event schemas without having to worry about packaging them in my package
Not done when using an editable pip install by default
|
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/potential-collaboration-on-user-research/866/15 |
| # As an example, let's write these to local file | ||
| return [logging.FileHandler('events.log')] | ||
|
|
||
| c.EventLog.handlers_maker = make_eventlog_sinks |
There was a problem hiding this comment.
Hm. I think what I want here is an event_sinks trait, instead. This would be a list of "EventSink" objects that route events wherever my sinks live. For some external service to become a sink, it would need its own EventSink subclass (equivalent to the logging.FileHandler in this example). The telemetry package can provide base classes for different types of sinks.
Making this trait a Callable confuses me. It offers a little too much freedom for routing to sinks. I wouldn't know how to begin without seeing a thorough example. I think I would rather be given a defined interface (i.e. EventSink) that has a clear entry point and just list these sinks in my configuration file.
There was a problem hiding this comment.
Unless this is a constraint of Jupyter's config system...
i.e. I don't know how these things get ordered—do we need to instantiate the logging handlers after the event log has been instantiated and that's why this needs to be a callable?
There was a problem hiding this comment.
Thinking about this more, I'm realizing handling (i.e. routing) events and consuming events (i.e. event sinks) are two separate pieces. Maybe this trait should maintain the name handlers, but become a List of handlers. We don't ask users to make the handlers. We provide base handlers the can choose from and extend.
There was a problem hiding this comment.
See response at jupyterhub/jupyterhub#2542 (comment)
|
@yuvipanda do you want to move this PR over to jupyter/telemetry? |
|
@Zsailer the python side of this is now part of jupyter/notebook#4752, but I think the JupyterLab side should probably remain here... |
This is a pure prototype demo of how the EventLogging
system as described in the strawman design PR
can be implemented. It's a way to play with how things may work, and help us
figure out how to do eventlogging / telemetry in a way
that works for everyone in the community.
The binder link for this PR puts you in a JupyterLab
instance with this set of extensions running.
All JupyterLab command invocations are logged into a file
in the home directory called
events.log.The events will conform to a well defined, versioned
JSON Schema.
This can be used by analysts to understand their data,
and hopefully can help auto-generate a view for users
to see what data is being collected.,
By default, this data is thrown away. In this PR,
I've configured it to be saved as a file into ~/events.log.
I've had to remove the consent dialog box, since it
no longer built with current JupyterLab - and my JS
skills are not good enough to figure out what has changed
in the last year.
The Python code for doing validation, emission etc
is coming from this unmerged PR in JupyterHub,
which itself is adopted from production BinderHub code.
Let's keep technical discussions about this there.