tkfx

joda-time + java.util.delorean

Java is alive and kicking. It's the most popular programming language in the world. As such, it also attracts most of the fire. We hope to see more colorful projects like these go open source. Thanks for the comment! :)

Sentry doesn't give you the local variable state at the moment of error. Only environment related data. We use it as well, but only for JS frontend. It's more of an error tracker, rather than a root cause analysis tool. The benefit is that it's wider and doesn't only focus on Java, but you'll still need to spend time going through logs to actually troubleshoot those errors and understand what was wrong with the state that caused them.

With OverOps, you go deep on Java, with every variable value, overlaid on the code across the call stack. Without looking at / relying on logs.

There's a short video here (http://www.overops.com/) and you can see some more samples after you sign up.

I think the tool that we're building (http://www.overops.com) could be something that might help with the log data overload. It basically gives you everything you need to troubleshoot an error - without relying on log files, while deduping recurrences of the same event.

It gets all the required information (source, stack and variable state), through a native JVM agent that transmits everything directly to the tool.

Heh, this might actually be useful for v2.0 :)

Cool, sounds similar to the site on the other comment here: http://projects.haykranen.nl/java/

Working on it as we speak ;)

Hey, at the moment we're only interested in JVM languages, so Java was the best fit for this project. We'll be adding .NET support for OverOps in the future so that might be something we'll be looking at for Bullshifier as well.

There are a bit more details about the design on our blog: http://blog.takipi.com/java-bullshifier-generate-massive-ran...

And the full source code is available on Github: https://github.com/takipi/java-bullshifier

Basically, the tool is built with Groovy (many projects use it as a scripting language for Java), and there are 4 sections to each randomly generated class:

1. Variable definition, with random types, random names, and values.

2. A section that throws exceptions, or prints to the log, according to the config settings for the rate of events. This also includes a “suicide” function that stops the execution of the program.

3. Calls the next method.

4. Random code that never runs.

There are some advanced config settings described in the Github README.md

It's not only that. OverOps also shows the variable state and source code of every stack frame. It's like using a debugger in production.

We've actually thought of using a random pool of Star Wars related names, will have to wait for the next version. Pull requests are welcome though :P

Hi, Alex from OverOps here. We've created the "Bullshifier" internally to stress test edge cases with our own monitoring tool (http://www.overops.com).

Whenever an exception or a logged error / warning happens in production, it shows you the complete source code leading to it, and the full variable state across the entire call stack.

Using Java Bullshifier, we're able to generate random applications with call stacks that can go thousands of frames deep and other quirky behaviors. This helps us make sure the overhead is unnoticed, even in the most extreme cases.

Would be happy to answer any questions.

Hey, no, not at the moment, but we'll be able to offer discounted prices depending on your specific requirements. If you're working with a startup we also have discounted pricing for that. Drop up an email on hello@overops.com and I'll make sure someone follows up

Whoops, thanks, edited the last message

We covered this topic quite extensively on the Takipi blog. Grepping through huge unstructured text is quite frustrating.

Sumo Logic, Graylog, Loggly, PaperTrail, Logentries, Stackify: http://blog.takipi.com/how-to-choose-the-right-log-managemen...

ELK vs Splunk: http://blog.takipi.com/splunk-vs-elk-the-log-management-tool...

Hosted ELK tools: http://blog.takipi.com/hosted-elasticsearch-the-future-of-yo...

We're actually building (and using) a log alternative called OverOps (https://www.overops.com), it's a native JVM agent that adds links to each log warning / error / exception that lead to the actual variable state and code that caused them, across the entire call stack. Disclaimer: I work there, would be happy to answer any question.

Correct, JVM only

Re Distributed Debugging / Centralized Monitoring, Logging and Alerting, this is exactly the kind of problems that our team at Takipi (www.takipi.com) tackles. It's a new way to get all of the information you need (source, stack, and state) to understand what's going on in a large distributed deployment in production - without relying on logs

If you're distributing your image in any way / creating copies etc. then you do

It just came in as a total surprise for me (and I guess for Mashable too, although they did write something about it: http://mashable.com/2015/09/23/twitter-share-counts/)

Announced on: https://blog.twitter.com/2015/hard-decisions-for-a-sustainab...

And went live this weekend. Surprised it didn't make any headlines.

I've been looking for this comment :)

The Takipi blog deals a lot with debugging related issues: http://blog.takipi.com/

Some more posts worth checking out in the JVM domain:

http://highscalability.com/blog/2015/1/7/the-ultimate-guide-...

http://www.infoq.com/articles/Advanced-Java-Debugging-Techni...

(Disclaimer: I'm from Takipi)

Hi ejain, check out this post by Takipi, the 7 log management tools you need to know: http://www.takipiblog.com/the-7-log-management-tools-you-nee...

found a bug: /dev/game/flappy/ should be /devil/game/flappy

looks like it, thanks for the mirror!

Cool way to find out and visualize which smartphones your friends are using!