So there's Graylog, then there's Graylog2, then there's the new-and-improved Graylog.... If someone forks it will there be a new-and-improved Graylog2?
Yea I am confused, is this different from Graylog2?
Announcing Graylog v1.0 GA
41–50 of 67 posts
Re: Announcing Graylog v1.0 GA
#42So there's Graylog, then there's Graylog2, then there's the new-and-improved Graylog.... If someone forks it will there be a new-and-improved Graylog2?
Yea I am confused, is this different from Graylog2?
We decided to drop the "2" from the name to have less confusion with "Graylog(2) 2.0" - Point taken here, the initial "2" was not a good idea :D
(The documentation may need a "History" page)
Re: Announcing Graylog v1.0 GA
#43"Users who tested the beta and release candidate versions of v1.0 reported huge improvements in performance and stability. Some of them were unable to crash the system no matter how hard they tried." This statement from the page makes me conclude that others were indeed able to crash the system, perhaps without even trying too hard. My guess is that the statement should be re-worded.
I was able to crash the system without even trying. After waiting for a 500MB something docker image download and running the container halted the host OSX machine while looping with errors (failed API connections, failed to load SIGAR, ...) The screenshots looked great but the first steps experience were a deal breaker.
[deleted]
Re: Announcing Graylog v1.0 GA
#44Earlier quoted context omitted.
Yes! We have put a lot of effort into making this one thing. The graylog-web-interface connects to the graylog-server REST APIs and that is it. You can manage and monitor the whole system from the graylog-web-interface. Both components are always released together.
Finally, less flexibility!
[deleted]
Re: Announcing Graylog v1.0 GA
#45I'm evaluating Graylog as a piece in our monitoring infrastructure. Does anybody have some experience using it in production?
+1 The solution seems neat. It'd be nice to know who is using it in production, how big is their environment, etc. I couldn't find much information online.
We're receiving roughly 200 msgs/s in our environment. We have it set up in an active/active environment across two data centers. It's been rock solid for us. It takes a little bit of time to get certain applications to send messages properly, but once you do, it's pure gold.
We are using NXLog on our Windows servers to send event log messages in GELF format. This allows us to truly delve in and search event logs so much easier than what we normally would be able to in Windows.
Re: Announcing Graylog v1.0 GA
#46I looked around a little bit on the web page but the answer to my two questions was not immediately apparent to me. (Note: I might just be blind) 1. Can I set up a second Graylog Server as a failover with automated recovery and log syncing when both nodes come back up? 2. Can I run it on any cheap cheap embedded platforms like a raspberry pi or beagleboard?
Yes, you can set up as many Graylog servers as you want and put them behind a load balancer or integrate any kind of failover you want. We do not recommend it running on extremely small platforms like a raspberry pi, but a very small VM (we have OVAs and other virtual appliances ready) is able to process a lot of messages already.
> and put them behind a load balancer
Only if your load balancer supports UDP, which most don't. You'll most likely need to use DNS load balancing in this case unless you're sending GELF messages with TCP.
Re: Announcing Graylog v1.0 GA
#47I'm evaluating Graylog as a piece in our monitoring infrastructure. Does anybody have some experience using it in production?
I've used it and have colleagues that have used it a few companies. I would suggest to get the most out of it, you should set up some sort of tagged logging. In Ruby, there's log4r + log4r-gelf to add additional context (e.g., Rails request GUID), that way you can easily and quickly link related messages. If you lack that flexibility, Graylog's extractors work rather nicely too. It's just a lot harder to manage, IMHO.
It's really helpful being able to pull up all requests for a single user across the cluster. Or track the status of all components of a Sidekiq job. Or see which API requests are most popular. Etc.
Re: Announcing Graylog v1.0 GA
#48Some folks in the Fluentd community uses Graylog2+Fluentd as an alternative to EFK (Elasticsearch Fluentd Kibana) See http://www.fluentd.org/guides/recipes/graylog2
Re: Announcing Graylog v1.0 GA
#49Earlier quoted context omitted.
Yea I am confused, is this different from Graylog2?
We decided to drop the "2" from the name to have less confusion with "Graylog(2) 2.0" - Point taken here, the initial "2" was not a good idea :D (The documentation may need a "History" page)
No Graylog3?
Re: Announcing Graylog v1.0 GA
#50Oh maaaaan the old graylog2 site had probably my /favorite/ branding in all of software. The heading was "Manage your logs in the dark and have lasers going and make it look like you're from space."
https://web.archive.org/web/20130302051347/http://graylog2.o...
Sad to see it's gone all "professional" now :(
The web service had some hilarious bits too. Does it still say "enraging gorillas... | mounting party hats" etc when you log in?