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.
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.