The Elastic Stack: Future of ELK Platform
elastic.co
elastic.co
> Don't see a button? You may have to disable your ad blocker.
What a shitty experience. You're pitching a product that you're clearly intending to sell commercially (which is both fine and dandy), and your first interaction of this brave new World Stack is to tell me I'm browsing wrong! And that's immediately after I click the previous "Get 5.0 Alpha" Call To Action (which was a button that appeared just fine, mind you) and I'm faced with the bitter realization that it's not Get, it's Get In Our CRM.
This kind of thing rubs me the wrong way, hard. I live in the B2B world, I totally get the pitch and the signup, but don't mislead me on the call to action, and don't make me distrust your intentions (or web development skills, for that matter) by telling me I need to open my privacy and performance preserving ad blocking gate and let you come over to my yard just to fill out a damn signup form on your fancy clipboard.
It's inauthentic, and I don't think I'm the only one who feels that way.
The idea of forcing the user to change a browser setting to get work done is a very "enterprisey" mindset. An old way of thinking that it's the user's fault if they can't use the software.
> Success! We've got your information and will send you a note when 5.0 Alpha is available.
With no links to documentation or github or anything. Having me sign up and get told I'll be emailed at some unspecified time when it's available was very disappointing.
Sorry, I'm not going to register just to watch the videos.
It has an very long way ahead to catch up with Lucene, but it's a very promising start.
I find ElasticSearch somewhat brittle (I need to restart it every few weeks or so, because it stops accepting any data or queries), and I really do want to replace it, since it's a memory hog (no data, and it already needs 230MB RAM), but I haven't found any sensible log storage yet. All I got is this document searching engine.
230MB RSS, and this is not "ES usage", it's just after starting it with no data whatsoever. I've seen databases which use less memory than that when working.
> I run some very large clusters [...] without problems for 4-6 months without any restarts.
Well, good for you. Being a sysadmin, I understand very well that my ES server may be a specimen combining bad kernel compilation, broken JVM version, unstable ES release, and ground water emanating bad energy, so I don't complain much. Still, I would be very, very happy to see any alternative for storing JSONified logs.
The preceding has been an unpaid endorsement for Loggly.
Basically I need ELK, but I need it to be a lot more stable and documented better.
What the hell has happened to Elastic?!
https://www.elastic.co/guide/en/elasticsearch/reference/1.7/...
I have SEVERAL elasticsearch-hellride.txt files stored in my documents folder with a bunch of example queries, because it's so wordy I can't keep it all in my head. I just refer to those every few months when I'm adding functionality. I wouldn't get caught up with having to google for basics. Find some things that work FOR YOU and save those, with your personal notes added in the right places.
Here is what I can recommend as far as plugins go:
http://www.elastichq.org/ - clean, simple interface, but not quite as powerful as:
KOPF: https://github.com/lmenezes/elasticsearch-kopf
This will give you access to a great query interface. You can use the GUIs here to build a few queries until you get a feel for what the JSON should look like.
How I use elasticsearch is kind of... Well. It's just what I do. We have PDFs that are OCRed and we store the text in the document along with ~50 fields that are entered by humans. It's probably too complex, but it's financial data and people love to be super verbose with their queries. I can't rely on the OCR to be perfect for SEC filings.
1. https://www.elastic.co/guide/en/elasticsearch/guide/current/...
2. https://www.elastic.co/guide/en/elasticsearch/client/index.h...
I have an open issue on Logstash, spent a fair amount of time detailing it, but have gotten no feedback. And then I realized there's 600+ open issues! https://github.com/elastic/logstash/issues/4389
I'm considering using Syslog-ng and would love to hear if anyone has comments on that. Based on other comments here, will be checking out Riemann and Fluentd as well. https://syslog-ng.org/
syslog-ng and its competitor, rsyslog, are fine, but they are concentrated around logs specifically. Fluentd (and logstash) can be used to transport other data, too, like monitoring or inventory.
At OVH, both turned out to be way too slow, so we wrote Flowgger which is heavily used by all our services: https://github.com/jedisct1/flowgger
Feel free to hop on the IRC if you have further questions, there's usually somebody qualified to answer.
I have hopped on the logstash IRC at times to ask about some of this, though I guess not this exact item. In fact, there's a different (well-known issue) that the init script for logstash has the config path hard-coded: https://botbot.me/freenode/logstash/2015-11-17/?msg=54338903...
There's also the problem that logstash (and forwarder) doesn't seem to let me do anything useful with the file names. I could work around that, sure, but it would be nice to have meaningful file names (not the "ls." thing that LS uses). Syslog-ng, for comparison, gives you a lot of control of that.
Yes certainly. It's totally fine to place multiple config files there, I do as well. I split up my configs in the various outputs, inputs etc. It's just that logstash combines them to a single pipeline and does not run a pipeline per config file. Nginx doesn't run a webserver per config file either :).
It's certainly something that's unexpected and could be much better documented, but alas, I'm just a user :)
(and I do agree, your issue could have been handled much better, especially since it's not actually a bug)
Yeah, my point was more that they accepted my issue, but there's no action and there are more than 600+ other open issues. Seems Elastic is too busy branding and pushing breaking changes to their APIs.
I do sincerely appreciate your clarifications and comments on this one, though.
I myself have hoped for a Go rewrite of Logstash for a long time, but there are apparently no plans for this. They are creating lightweight forwarders with their *beats, though. But they are only for forwarding to ElasticSearch, not a general log pipeline processor like Logstash.
FWIW there is a thing that's like Logstash in Go, it's Heka by Mozilla. I am very fond of it, but for some reason not many people seem to be aware of it or deploy it.
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
You could go really far with Fluentd using or writing only few plugins.
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.