On Mon, 5 Dec 2016, Bob Gregory wrote:
action(type="omriemann" metric="1") will send {host:$hostname, time:
$timereported, service: $programname}
One point of clarification, rsyslog doesn't currently have a config parameter
type that allows for a parameter to sometimes be a constant and som
; mentioned
> in the video you posted.
>
> David Lang
>
> On Mon, 5 Dec 2016, Bob Gregory wrote:
>
> > Date: Mon, 05 Dec 2016 12:26:17 +
> > From: Bob Gregory
> > Reply-To: rsyslog-users
> > To: rsyslog-users
> > Subject: Re: [rsyslog] omriemann
I still have a question about what the attributes are. They weren't mentioned
in the video you posted.
David Lang
On Mon, 5 Dec 2016, Bob Gregory wrote:
Date: Mon, 05 Dec 2016 12:26:17 +
From: Bob Gregory
Reply-To: rsyslog-users
To: rsyslog-users
Subject: Re: [rsyslog] omri
> what about status? is it normally/commonly left blank?
It depends on the use case, for something like cpu usage, the state would
be blank; likewise for rsyslog message throughput. I would expect to see a
state for something like monitoring redis operations, or HTTP calls, where
the metric repres
On Mon, 5 Dec 2016, Bob Gregory wrote:
Yo yo, David.
I think you're convincing me, at least on the service/programname. That
means we can default all of the required host, service, timestamp fields. I
also like the simpler approach of using the fractional part to decide which
kind of metric we'
Yo yo, David.
I think you're convincing me, at least on the service/programname. That
means we can default all of the required host, service, timestamp fields. I
also like the simpler approach of using the fractional part to decide which
kind of metric we're sending. That's a better user-experienc
On Mon, 5 Dec 2016, Bob Gregory wrote:
@ David Lang, moving omriemann discussion back over here.
we need to try and come up with a reasonable default value for parameters.
I think I disagree with that. Most of the fields aren't required, and we
shouldn't send them unless configured otherwise
@ David Lang, moving omriemann discussion back over here.
> we need to try and come up with a reasonable default value for parameters.
I think I disagree with that. Most of the fields aren't required, and we
shouldn't send them unless configured otherwise. The intention isn't that
all logs will g
2016-12-02 9:30 GMT+01:00 Bob Gregory :
> The problem there is that I'd need to reformat the json output of impstats
> in order for it to fit this module. I might be tempted to add a separate
> output format to impstats for that case, though, because it seems perverse
> to make people do that templ
The problem there is that I'd need to reformat the json output of impstats
in order for it to fit this module. I might be tempted to add a separate
output format to impstats for that case, though, because it seems perverse
to make people do that templating themselves.
We can amortize that work if
I need to think a bit before casting a ballot, but
a) json blob sounds great
b) sounds useful for impstats -- impstats can generate json
Raienr
2016-12-02 8:41 GMT+01:00 Bob Gregory :
> Evening all,
>
> I've mostly finished my last personal project, so my thoughts are turning
> to omriemann.
>
>
For almost all of the parameters to the module, they _must_ vary by
message. The only exceptions are things like TLS settings, or the remote
host endpoint. Everything else is structured data about an event that
happened elsewhere. Most fields can be omitted if there's no parameter set
- it's unusua
On Fri, 2 Dec 2016, Bob Gregory wrote:
Evening all,
I've mostly finished my last personal project, so my thoughts are turning
to omriemann.
I'm trying to work out how we might configure the module. Riemann requires
that we send a protobuf encoded message containing a few pre-set fields,
plus w
13 matches
Mail list logo
