Satoris — Metering is Profiling & More
Better Java Performance Profiling Tooling for the New Year
At this point, you’d expect me to list of many “noble” reasons for making available the software free of charge but to be frank I’m not exactly sure which factors truly contributed to my decision one day to say let’s release it!
I know of at least 50 reasons for not wishing to release the product to the general public. That’s the number of metering extensions I designed and developed for Satoris over the years. Making them readily available and fully documented is a double-edged sword. You show the power of extensibility built into the metering engine but you also scare off many with the perceived “complexity” in needing to understand each one in turn and then to select and configure those particular to a situation and investigation. So, for now, I decided to defer the publication of supporting documentation for the extensions until a community of experienced users is established.
That said there are some recent developments which I’m sure spurred such action. I’ve been very concerned to witness some in the industry getting behind what I regard as a flawed Open API for distributed tracing. I’ve not being persuaded of the need to make the distinction between distributed and local tracing of code execution. Never mind one that thinks that the only measurement needed in tracing flow is wall clock in milliseconds. It has been disappointing not seeing the Probes Open API get the attention it rightly deserves. But that could be attributed to my naivety in not providing a reference implementation. A decision I took so as to encourage the development of different implementations as I felt if I put my own one out there it would become the de-facto implementation — limiting competition and adoption. In the end, people need to get stuff done and going from a design to an implementation is not so easy if you’ve not been through the design process from the very inception of an Open API. Hopefully, I can remedy this mistake somewhat in providing access to Satoris which fully implements the Probes Open API though I accept that I need to go further with a reference implementation in source code form. Working on it!
Another thing that has troubled me is that we’re still seeing companies use “heavy-weight” application performance monitoring solutions such as AppDynamics, NewRelic, and DynaTrace to catch code level issues in production, rarely in test or development. I’m not discounting the need for such products in the big scheme of things but it seems overkill to say the least for the type of low hanging fruit “found in production” that’s promoted in marketing material — stuff that should be confined to the history books.
We need to do better, and much sooner.
Most commercial application performance monitoring vendors have already moved up the value chain and stack offering software analytics and now “artificial intelligence” but unfortunately the measurement foundation underlying these solutions was never really strong and has been weakened by new demands and changes in the environment. Satoris offers a solid foundation for building amazing new capabilities into monitoring stacks such as recording of episodic machine memories, mirroring and simulation of machine execution, and adaptive control of service request processing. These are some of the big ideas I got around to developing and delivering once I had solved the measurement problem. There are many bigger ideas I have brewing, given more time and resources, but such ideas are not exclusive to one individual. So why not give Satoris a try. Learn how it adaptively instruments and measures Java code execution. Then build your own extensions offering new metering strategies, data collection, monitoring integration, and more using the Probes Open API extension points.
Here’s hoping 2017 will be a small bit better than 2016!