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.
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.
Hey, Lewis from Sentry here. "Sentry doesn't give you local variable state" is not entirely accurate - it varies from platform to platform. We don't do it for Java (you're obviously ahead of us there), but we do with at least Python and PHP off the top of my head. I wish we could do it for JavaScript too, but it's only partially feasible and only in a very questionable way.
Note that in your browser JS use case, we capture breadcrumbs to show you console logs, user interaction events, XHRs, navigation events, prior errors, etc leading up to the error, so you should be able to easily just reproduce the error state rather than digging through logs to find out what it was. If you still find yourself needing to dig through logs to troubleshoot JS errors reported via Sentry, I'd really like to hear more about your experience to see if we can make it better.
If you have the time (probably not :) ), there was a really cool project that took names from GitHub and generated random names using Markov Chains... maybe use the same for the class names :) .
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.
I don't know why, but the fact that this is an actual tool that's been designed to solve a real problem that you guys faced (as opposed to being a random project that somebody dreamed up to make fun of Java or to see if they could do it) makes me really happy.
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! :)
I've been wanting to build a generic version of this type of tool for quite some time.
When I'm waiting several minutes for our app server to startup, I often ponder what life would be like if we had chosen language X or another stack for our application.
I've primarily worked on JRE-based stacks for some time and once a project reaches a certain size developer happiness begins to decline due to large compilation times, app startup times, etc. Even incremental compiling or hot-reloading of classes seems unreliable at a certain app size (either due to memory or some other reason).
It would be neat if there were a tool to generate large and complex apps with various stacks to get a feeling what the developer experience would be like 1-2 years down the road once the app reaches a critical mass.
That is a good idea for testing out new stacks for that shiny new rewrite. One thing I've realized is most projects are not designed for 100+ developers working on it at +400kloc of code.
We adopted https://buckbuild.com/ at work for our android builds, and it has sped it up a lot compared to our previous gradle build process.
We have a self-hosted Jira/Confluence server running on Windows that's reached end of life....I can relate to this. Fortunately no Oracle in the mix other than Java.
I did once work on a project that had a class FluxCapacitor. It was used in testing to set the time. It worked, but had about as many zany unexpected consequences as its fictional namesake.
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.
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
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.
I'm really excited about Takipi (I guess OverOps now) but the per-JVM pricing kills it for us, especially as we look to moving to microservices. Any plans for alternative pricing, such as per-GB or per-exception?
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
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 giving copies to other people, that's distribution, which is dicey, but if you're making copies for your own use, that's reproduction, which is fine.
I'm agreeing with you because the alternative would make deployment processes of snapshotting built images for faster startup time against the law. If you couldn't use AMIs in AWS because the Oracle JRE is installed but instead are forced to install at launch time then that makes Oracle largely irrelevant to use in the cloud - no one wants to limit their startup time by a multiple minutes to download and install for a scaling event (and barring any network issues on their servers if hosting the installer package is seen as distribution as well). I haven't heard of any issues with moving around your own internally built virtual images with Oracle Java if you have accepted the licensing agreement for during the build and snapshot process, and using docker seems no different.
This has absolutely nothing to do with installing at launch time. This has to do with installing, then not distributing. Distributing is a very well defined term in the industry, and does not simply mean making copies, or deploying to your own machines.
Distributing means giving the built artifact to a 3rd party.
Yes, you can create your own JDK docker base image. Yes, you can deploy it at will on any of your systems. No, you can't push it to a public respository for other people to use.
Is there an actual legal distinction between the two? Even if there is it seems like in a corporate world that could be quite messy because the corporation it self could be split into multiple legal entities so if you have a group wide IT department that provides the images for developers to use it could still count as distribution.
Well that's a whole another issue than "running jdk on docker is breaking teh law!!1!", now isn't it? If you run "photoshop on docker" that doesn't magically make it ok to distribute your image willy-nilly.
Oracle JDK has a licence, news at 11.
It gets all the required information (source, stack and variable state), through a native JVM agent that transmits everything directly to the tool.