Re: [rsyslog] non-C output plugins

[David Lang]

so what exactly is being proposed?

It sounds as if we are talking about omprog, but that also captures stderr of 
the program that's executed, and watches that stderr for specific keywords.

what keywords are you talking about, and what actions will be taken? how would 
these actions differ from the program just stalling reading of the pipe or 
exiting with an error code?

This is not going to be able to support batch mode, some number of logs are 
going to be lost in any case because we will dequeue messages (consider them 
delivered) when we put them in the pipe to the program, any feedback we get from 
stderr can only affect logs that haven't been sent to the pipe yet.

what other restrictions are there?

David Lang

On Thu, 23 Jan 2014, Radu Gheorghe wrote:

Or, maybe it's easy to add imthrift&omthrift?

2014/1/23 Radu Gheorghe <radu0gheor...@gmail.com>

+1. Let's make what we already have (and maybe add some stuff with minimum
effort) easy to use. Let's see what the adoption is. Let's see people
complain about performance, if that's ever going to happen and then we can
"do it right" according to demand.

2014/1/23 Boylan, James <james.boy...@orbitz.com>

I agree with Rainer.

While 'doing it right' from from the start and building from the ground
up perspective is a fantastic goal, the reality of trying to fit that in
with an entirely new direction is difficult at best. When you have a
mounting list of items that need to be worked on already, sometimes taking
that fast to implement first step to just show how much better something
can be is critical to get stakeholders to back investing the kind of time
required to make a major overhaul to something.

-- James

-----Original Message-----
From: rsyslog-boun...@lists.adiscon.com [mailto:
rsyslog-boun...@lists.adiscon.com] On Behalf Of Rainer Gerhards
On Thu, Jan 23, 2014 at 9:09 AM, David Lang <da...@lang.hm> wrote:

On Thu, 23 Jan 2014, Rainer Gerhards wrote:

 On Thu, Jan 23, 2014 at 8:00 AM, David Lang <da...@lang.hm> wrote:

 On Thu, 23 Jan 2014, Radu Gheorghe wrote:

 2014/1/22 Rainer Gerhards <rgerha...@hq.adiscon.com>


 On Wed, Jan 22, 2014 at 3:17 PM, Radu Gheorghe <
radu0gheor...@gmail.com


I think it all depends on how much work we are going to have to do.

why do we need to do anything? can't omprog with a JSON template
already do what's needed?


IMHO quite some things, but it lacks some others (like a feedback
capability, see below). My interest is to extend it in a way that mostly
solves these issues.



as long as we stick to pipes, we aren't going to be able to get per
message success/failure messages (the buffering in the pipe will
prevent that from working well)


That's right, but we get pretty close to "around when it begins to fail".
Per message is hard in any case. Think e.g. TCP forwarding: we never know
exactly when the connection broke, so this is also approximate.


I guess I'm not fully understanding what's being proposed for the
short term.


Let me coin it into a non-technical statement: I try to do the minimal
thing necessary to make it easier for people to connect to destinations for
which rsyslog does not yet have any native plugins. Among the tech issues,
this probably means make folks aware that they actually *can do that* (as
you say, to a large extent even with what we have today, but that seems to
be too well-hidden). Once this is done, I'd like to sit back, relax, gain
some experience and then see how to proceed further.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 
THAT.