Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make TCP logstash work #284

Merged
merged 4 commits into from
Mar 4, 2018
Merged

Make TCP logstash work #284

merged 4 commits into from
Mar 4, 2018

Conversation

kc0bfv
Copy link
Contributor

@kc0bfv kc0bfv commented Mar 2, 2018

Currently, logstash.LogstashHandler is an alias for UDPLogstashHandler - thus, handler TCP is ignored, and glastopf always uses UDP logstash. This change makes it work properly.

kc0bfv added 2 commits March 2, 2018 18:22
Currently, logstash.LogstashHandler is an alias for UDPLogstashHandler - thus, handler TCP is ignored, and glastopf always uses UDP logstash.  This change makes it work properly.
Python logstash has a feature that lets you supply extra options to the
logger.  These extra options are in the format of a dictionary, and
those get passed along to logstash and the rest of the chain.

This patch breaks out the things that form the message, and supplies
those as extra options.  Without this - logstash users have to use a
grok expression to split things out, and that's silly.
@kc0bfv
Copy link
Contributor Author

kc0bfv commented Mar 3, 2018

Also - I broke the log message components out into their constituent parts, and used a feature of python-logstash to send them to logstash. That makes ingest into logstash much simpler - it eliminates what would become a complicated grok statement, that probably wouldn't work that well anyway.

@glaslos
Copy link
Member

glaslos commented Mar 4, 2018

Thanks for taking a look at this. If I'm not mistaken, if you are changing this line to sudo service mongod start the test should pass again.

@kc0bfv
Copy link
Contributor Author

kc0bfv commented Mar 4, 2018

Not sure exactly what's up at this point - the PHP includes configure finds for BFR seem to be very different from what my build found - I got:
checking for PHP includes... -I/usr/include/php/20151012 -I/usr/include/php/20151012/main -I/usr/include/php/20151012/TSRM -I/usr/include/php/20151012/Zend -I/usr/include/php/20151012/ext -I/usr/include/php/20151012/ext/date/lib

This one seems to have found a bunch of junk for PHP 5 maybe.

@kc0bfv
Copy link
Contributor Author

kc0bfv commented Mar 4, 2018

Also - I need to check out SNARE/TANNER - didn't realize there was a successor to this project until I stumbled on mushmush.org

@glaslos
Copy link
Member

glaslos commented Mar 4, 2018

Argh, this is related to the changes we did in BFR for PHP7. ignore the issues, I'll merge your PR and I might fix it some other time 👍

@glaslos glaslos merged commit 9b18983 into mushorg:master Mar 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants