Hello,
I would like to be able to send events from the new logging system (twisted.logger) to a remote log collection system. If I'm using twist then it seems options for configuring this part of logging are limited. The choices appear to be logging to stdout, stdout, or a file on the filesystem.
This is definitely a desirable goal, something that I am also wrestling with.
If I write my own command-line entrypoint then I can probably do whatever I want by writing a custom observer and hooking it up appropriately. I'd rather not have to do that, though.
I could also go back to twistd and use --logger. But since interest in twistd appears to be on the decline, in favor of twist, I'd rather avoid that as well.
The hope is that `twist` can fully supplant it, yes.
It seems like the idea would be something like --logger for twist, perhaps replacing the --log-file option. If there were a way to pass some arguments that would be pretty nice as well.
This looks like a pretty reasonable idea.
twist --logger myapp.something:x=y,a=b
twist --logger twisted.logger.FileLogObserver.fromPath:path=/foo/bar
(Actual syntax not that important to me; consistency with endpoint syntax would have some advantages; something that deals with the necessities of quoting and nesting would be better, of course. Also, I know everyone hates Twisted's plugins but they would make for a nicer UI than FQPNs here.)
I don't hate Twisted's plugins.
The first thing I'm likely to do with this is bridge twisted.logger events to Eliot. I think this will provide the most useful logs (at least some of the logs from Twisted will have a meaningful Eliot context, though certainly nowhere near all). Also I already have a system for configuring Eliot log destinations (which supports passing along arguments, so I can already tell Eliot where my remote log collector is with a command-line argument).
What are the chances of getting support for this scenario into twist itself?
I take it that Eliot "log destinations" are sufficient for the purposes of remotely transmitting your logs to a collection system, so you're mainly asking about the extension point, and not any particular collector?
I'd say that chances are extremely good that this could be accepted. I'd really like log configuration generally to be more robust.
Also, possibly the hypothetical "+" plugin which has come up a few times (i.e. "a command line syntax for running more than one plugin in the same process") would be an interesting idea here. 'twist + eliot --to=<some eliot place> + web --port le:certificates:tcp:443' might be a way to express this without any specific logging support from `twist`; the "eliot" plugin could just add a global log observer when it starts.
-glyph