Also, their shitty Debian repo management resulted in a bug that caused my company to lose $30,000.
The world needs more ELK hate.
> Also, their shitty Debian repo management resulted in a bug that caused my company to lose $30,000.
Well, this is not their fault that much. If you had put any thought about using repositories, you wouldn't use random packages from random sources over which you have no control and no trust with regard to package retention policy or packages quality.
Or maybe you would happily install also MongoDB from Mongo's site?
While I don't have the tiniest font in my terminal, I still couldn't read the entire Elasticsearch process line in htop, even when I'd stretched the terminal all the way across three monitors! The middle one was an ultrawide! I really wish Java would stop using arguments instead of storing config somewhere...
Not really. It's just logstash, along with some plugins (and what the heck are Maven bindings doing there?).
ElasticSearch is another 29MB compressed, which is fine for a database-like thing, and Kibana 4.x takes 30MB compressed (150MB uncompressed, of which not the biggest part is Node.js copy).
FWIW, I inherited a thrice-removed infrastructure in a latency-sensitive environment. It was fun ;)
Logstash was installed on a couple machines the night before I was going to load some configs from my machine. I didn't load anything yet, except that logstash-web was running at 2s uptime. For some reason, (with upstart's help), the logstash installation included a broken webservice with a bad config. It got stuck in a JVM-birthing restart loop that was enough to cause significant impact. It happens.
(Funny enough, same place used mongodb. We ran into an issue once where database cleanups failed once mongodb reached around 50% of the disk. Local copy cleanups are fun.)
I've never actually come across that in a service before, one that shuts itself down due to inactivity. I mean, they must be out there, but I never would have guessed it'd be intentionally designed into a log shipper.
I maintain some Ansible roles, as well as some well-worn examples of ELK in production... And this marks the fourth time I'll have to basically rework _everything_ due to Elastic changing up the core architecture, naming, logos, etc.
I'm also less-than-thrilled with the performance for larger deployments. Having to babysit my log aggregation infrastructure (average about 50-100 events/sec across a few dozen hosts) is not very thrilling.
You could go really far with Fluentd using or writing only few plugins.
For the love of internet-god, please stop your constant moving of stuff around. Now we have new logos.
Last year's fun, I was using logstash-shipper to ship logs. Early on, the package got pulled completely - sucks to be you if it's in your deployment script or in your documentation. Then it had a name change. Then it moved to one domain. Then it moved to another domain. Then it got switched out for Beats.
Not everyone finds setting up and maintaining an ELK stack so fascinating that they want to keep up to date with exactly where everything is this month. While you can do other things with ELK, the primary use-case is logging. Logging is supposed to be reliable and 'just work'. Every time I see the elastic website, something else has changed, and everyone is pushing the new stuff.
ELK is cool and all, but it's frustrating to follow when you just poke your nose in every few months.
Love,
- Vacri