On Mon, 5 Dec 2016, Dave Cottlehuber wrote:
https://github.com/algernon/riemann-c-client may be of interest to use
it directly -- its been dropped into collectd as a library now as well,
and is ported to Debian & FreeBSD already, that I know of. The protobuf
wire format is
https://github.com/algernon/riemann-c-client/blob/master/lib/riemann/proto/riemann.proto
if that's helpful.
it is.
What I've found useful with collectd and riemann was to be able to set
specific custom tags per instance (rsyslog server in our case) which
makes the sorting in riemann very easy prior to parsing any specific
message output. Mainly source & instance type:
it looks like the protobuf allows a lot of options in terms of how to store the
data.
We can make educated guesses as to what makes sense fro the riemann point of
view, but they will only be guesses
as far as tags go, tagging it as being from rsyslog is an obvious item, and if
we have tags from mmnormalize, they should go here. What else?
should service be the programname or the faclity?
where would facility/severity be stored? is severity == metric?
what sort of stuff normally goes in the description field?
for the attributes, one obvious one is the message, but beyond that it's less
clear. Given that rsyslog internally tracks things as JSON, I think putting each
json object as an attribute makes sense, but attributes can't be nested.
Internally to rsyslog, we deal with nested objects by flattening them and
seperating the tiers with a ! (i.e. {foo:{bar:baz}} == foo!bar:baz), is this
reasonable from a riemann point of view? should we use a different character
instead?
David Lang
_______________________________________________
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.
