One of the most powerful things we do with Splunk is the "transaction" filter. I don't see any direct replacement with logstash... this is statically configured and seems to have limitations, but it's somewhere in the ballpark: http://logstash.net/docs/1.4.2/filters/multiline
not quite close enough, transaction is an ad-hoc query: http://docs.splunk.com/Documentation/Splunk/6.2.1/SearchReference/Transaction
probably one would want something like that:
this is the logstash alternative:
(the credativ guys work with it)
Another tool /me wouldn't use... but may be interesting ;-)
I like very much this one:
(have a look at the crazy videos ;-)
It uses a pimped collectd as some of the data sources.
OK, for one thing, I hadn't correctly understood how logstash fits together with the rest of its ecosystem. Logstash is like splunkforwarder, I guess- it's a piece of low-level plumbing.
The querying all happens in elasticsearch: http://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-queries.html
Not similar at all, but I do use this for viewing / checking combined logs from systems:
Epylog - https://fedorahosted.org/epylog/
It lets you boil down combined syslogs from multiple systems, and get rolled up reports on logins, and a free-for-all report of anything that was not parsed in an email.
It takes quite a bit of time to get what they call the "weeder" to build up to rid yourself of the background noise from the reports, and it does take ocasional changes to regexes on lines to account for some daemons changed log output for warnings, etc, but I find it worthwhile. Once you have your "don't care" lines out of the report, you will be left with the ones to either investigate and act on or just add to the don't care if they turn out to be a more of just miss-placed info output.
You can set up your own roll up reports, but I have not played with that as of yet.
Not the splunk way - there are no "don't care" records, you throw everything in the big index and figure out how to query it later.
Been talking to some former coworkers (now at NYTimes, ghod help them) and one of the Splunk alternatives they are looking at is Sumologic:
(^^ one of my litmus tests for a Splunk replacement)
When you go to this site, you may be treated to the following popup:
This page ws unable to display a Google Maps element. The provided Google API key is invalid or this site is not authorized to use it. Error Code:
So, they hope to supplant Splunk, but...?
Evidently their Big Data got so big it popped out of the screen.
(By the way, we ended up just buying a bigger Splunk license.)
Wow, this is funny and pathetic at the same time. I found this on the web site of a fairly popular piece of software today:
$i_understand_file_permissions_and_how_to_fix_them = false;
$i_understand_file_permissions_and_how_to_fix_them = true;
Now you have the button, the following explains the issues in detail."
Hmmm... someone has obviously been torn between wanting to help people, and not wanting to deal with the same stupid problem repeatedly.
LOL. The real problem is using anything written in PHP ;)
Yeah, I'm trying to migrate us to rails.
LOL. The real problem is using anything written in PHP ;)
Real developers write web applications in C.
(Ok, maybe not. But PHP does have a tendency to encourage an unhealthy mingling of markup and code.)
The software in question here is a Cacti plugin. And yes, I'm sure the developer was very frustrated with getting the same stupid question over and over again.
As many of you know, I've dealt with this. It's not a fixable problem. When you make a piece of software easier to use, you simply move to a lower stratum of people who have an even stupider problem. It's infinitely nested and there is no bottom.
(Ok, maybe not. But PHP does have a tendency to encourage an
unhealthy mingling of markup and code.)
That can be worked around. The semantics are horrible... take a look at the truth table for the == operator.
I still maintain that PHP was never meant to be a serious language but it "had greatness thrust upon it" by baristas-turned-programmers during the dotcom years.
The language selection wasn't what I was focusing on, though. Even a unix superfan like me can appreciate the fact that when you throw people out there into the world of file permissions without giving them the right mental tools to deal with it, bad things can happen. That developer's approach was snarky, which I totally love. It won't work, though. People ignore clearly written instructions and ask stupid questions anyway.
(Just do a "chmod -R 777 /" and everything will be ok!)
Hey, at least on a mainframe, file permissions are an add-on feature. So you can just shut off RACF and everything "just works" :)
I still maintain that PHP was never meant to be a serious language but
it "had greatness thrust upon it" by baristas-turned-programmers during
Sure it was. It just happens that it wasn't designed by people who were really, like, a language-designer's language designer.
It could be argued, for example, that COBOL matches the CGI model better than Perl ever did.
I don't necessarily think Smalltalk is ridiculously over-the-top for web programming. Although, I don't think Seaside is a particularly good implementation, based on how ugly their pages wind up looking.
And with the web, presentation is pretty much everything.
I suck at making web pages look good. When it comes to that stuff, I feel like I'm a troglodyte pretending to have competence at web pages, as I get more involved with making the thing work properly than look nice (when, really, both are required).
But the work I did in Ruby made the pages look very nice in spite of my efforts to make it look like shit. Or, rather, I would have to go out of my way to make the pages look like shit in Ruby, where in the other languages I've used, shitty-looking web pages were the norm.