Log events
dbrgn opened this issue · comments
It would be nice to be able to log certain events, like connection start and connection end, to tools like http://grafana.org/.
To keep things generic, the user could specify a script on the commandline that is invoked as a "callback" with the event data (e.g. {"name": "connect"} or {"name": "disconnect"}) to stdin whenever an event happens.
@lgrahl probably wouldn't be a lot of effort, right?
This is new to me, so I don't know what would be best practice. Maybe logbook already provides a handler that would help?
I think I wouldn't do that through the logger. Instead, through some kind of StatsHelper that simply prints to stdout sends events to stdin of a script.
Making statistics available via an API sounds more reasonable to me. That should be sufficient for your use case, right?
No, that's much more complicated than logging events like a new session etc. First of all you'd be responsible for storing them. Second, if we have 10 server instances we'd have to query all of them.
By simply sending the events (like "new connection") to stdin of a script (and ignoring any errors that might occur) you aren't responsible for collecting statistics. The event handling script could then aggregate all data and send it to whereever it wants.
Something like this:
import json
from subprocess import Popen, PIPE, STDOUT
def log_event(event_name, event_data):
if stats_script is not None:
try:
p = Popen([stats_script], stdout=PIPE, stdin=PIPE, stderr=STDOUT)
data = json.dumps({'name': event_name, 'data': event_data})
p.communicate(input=data)
except Exception:
# Log and ignore
Sounds awkward to me but if this is best practice, fair enough.
Can't make any promises that I'll be able to implement it before Mar 2017 as I'm blocked by studying.
Sounds awkward to me but if this is best practice, fair enough.
If you have a better idea, let me know. Coturn logs into a Redis database, but I think that's too much coupling. With a generic script, a user could write code that still logs into Redis, while keeping flexibility.
Maybe we should step even further back and simply offer an event API in form of a function callback.
@asyncio.coroutine
def event_handler(name, data):
pass # You can do whatever the hell you want here as long as it's non-blockingYou could then implement logging JSON to stdout for your use case and even provide an example for that.
Edit: As the function is async, you probably want to use https://docs.python.org/3/library/asyncio-subprocess.html which is nearly identical to subprocess.
Downside is that I have to modify saltyrtc-sourcecode for this to work. I can't just deploy a packaged version on my server and then configure an event handler script. What do you think?
There should be no need to modify source code as long as you don't use the CLI. My opinion is that the CLI will never be as sophisticated as a custom script that starts the server. We already provide an example that should help users on getting started. The callback function could then be an optional argument to saltyrtc.server.serve.
I think that would be a good starting point and of course we should be open for PR's that add further functionality to the CLI and the utils package. But let's start with that first. Agree?
Alright.
So, what kind of events do we want to gather? :)
- initiator-connected(path)
- responder-connected(path)
- handover(path)
- closed(path)
Something like this?
- initiator-connected/responder-connected: https://github.com/saltyrtc/saltyrtc-server-python/blob/master/saltyrtc/server/server.py#L231
- closed/handover: Add the reason code to
Disconnectedexception, find all raise occurrences and update them and catch the exception here
Raising the event could be done by adding a method to the ServerProtocol:
def _raise_event(self, type, data):
# lookup callback
self._loop.create_task(event_callback(data))The handover and closed events can be combined into closed(path, close_code).