On Wed, 23 Nov 2016, Bob Gregory wrote:
There've been a few discussions over the last few days that are all
pointing in the same direction:
* Is it better to use Rsyslog's omelasticsearch rather than pushing to
logstash?
* Should we have a minimal log shipper component as distinct from rsyslog's
processing capabilities?
* Ought we to have an imhiredis module?
Really what we're talking about is replacing Logstash (and the various
beats) with rsyslog. I'm perfectly happy with that, Logstash is a
resource-expensive and fickle beast that spoils my otherwise pristine log
pipeline, but I do think the community ought to think about whether this is
the direction they want to take.
if you look at the graphic on the main page of rsyslog.com you see that we have
a very large number of inputs and outputs. We already have omelasticsearch, and
onhiredis, adding an imhiredis just adds symetry to things and is not a large
deviation
Rsyslog is a log processing engine that accepts logs from many sources and
delivers them to many destinations, the more sources and destinations we support
the better.
For my part, I'm quite happy to help build an imhiredis (and imkafka?)
module but only if I can actually dogfood it, which means replacing
Logstash in our own environment.
good, we are aiming to make that not only possible, but a generally accepted
practice :-)
For that, I'd like to see better support for GeoIP tagging, a Riemann
output plugin, some better guidance on "failed message queues", etc. etc.
etc.
for GeoIP tagging, take a look at the table lookup capability. It was designed
with the maxmind GeoIP database in mind.
what do you mena by a Riemann output plugin
Are we jointly interested in building the REK stack and, if so, can we
start to work out the feature set we're missing, and the documentation we'd
need for this to work? I'm a little concerned that if we tackle the usecase
piece-meal, we'll end up with lots of disjointed parts that don't really
solve the problem: logstash is not an adequate logstash.
We are always interested in expanding rsyslog to fill in gaps in routing and
formatting logs, we try to avoid getting involved in analyzing and summarizing
logs (but do a bit of that), leaving that job for other tools.
Please do list the things you think are missing.
Documentation is always needed. Unfortunantly, too many of us deep in the guts
of rsyslog are bad at writing docs.
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.
