On Fri, 16 Dec 2016, Micah Yoder wrote:
On 11/21/2016 05:21 PM, David Lang wrote:
On Mon, 21 Nov 2016, Micah Yoder wrote:
The other reason I preferred Logstash was the configuration format was
a bit more user-friendly than some of the equivalent rsyslog rules.
can you provide some more info about the issues you had?
Hi David, sorry I was going to reply but didn't right away and got behind!
Actually it's been over a year and I don't remember all the specifics. Part
of it (most of it probably) were segfaults with mmnormalize and/or
mmjsonparse. And they've probably been fixed by now.
that was the timeframe when we were battling the json-c issues, so that was
probably the cause of the grief there.
But since we want
maximum stability for our other log messages, we knew then that we wanted to
separate this out from our main rsyslog process. The alternatives would have
been a secondary rsyslog process or logstash.
a separate queue inside rsyslog gives you almost the same separation.
I just liked the way logstash
config file works a bit more than how you set up rsyslog for this sort of
thing.
This is what I was trying to probe for. What is it that you liked better about
logstash, is it something that we can adapt, or address the problem in a
different way that makes it even easier, or ...
There were some performance concerns, but logstash is keeping up fine
and server load is low.
Would I switch back to rsyslog for this processing? In this particular
application probably not, because we don't really want to touch it again! :p
Would I consider rsyslog in the future for something similar? Probably.
Looks like it's come a long way. Especially with the ERK conversations. I
like what I'm seeing. Main things are great documentation and easy to read
config files. Progress could be made on both....
Maybe I could jump in on some of the documentation at some point. I once
wrote an rsyslog+elasticsearch tutorial that got reposted a couple places
(Rackspace dev blog and Puppet blog). It's ancient now though.
the documentation can be improved, we know that, so any help there is gratefully
accepted :-)
in terms of the config file, what is it that you see as being hard to read?
(Assuming that the config file is written using the v6+ config syntax, which was
created because the adaptation of the legacy config was getting _really_ ugly)
I might consider jumping in the code if it were written in modern C++ instead
of C. I'm a bit baffled why C is still used, but that will probably get me
flamed to a crisp here! :p
the project has been around a while, and started life as a fork of a C program,
so there's just never been a push (or the manpower) to re-write it in a
different language.
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.
