Metering is Monitoring, Memories, Mirroring & Management for the JVM
A question that keeps coming up since making Satoris freely available from the autoletics.com website is “How do Stenos, Simz, and Sentris relate to Satoris?”. From the relatively short descriptions of each product listed under the tools section of the website, it’s not easy to discern. I can admit that.
Satoris is at the core of all the other products but in slightly different ways. Without the metering engine included in Satoris, there would not be a Stenos, Simz, or Sentris product as they build on and extend the metering engine included within Satoris with new capabilities such as record and playback, multi-machine mirrored simulation, and adaptive runtime control.
To best describe the relationships between the products let’s start with the default setup of Satoris within a metered Java runtime. Whilst the product comes with 50 plus metering extensions by default it only enables 2 of these. The hotspot metering extension for adaptive measurement and the console extension for connecting the Satoris client monitoring console to the JVM.
Wouldn’t it be great if the execution of software could be experienced over and over again, from the perspective of the metering engine, in such a way that from our client monitoring console there is no distinction between the real original execution and the simulated playback down to the thread and method level? This is exactly what Stenos delivers. It does this with a metering extension enabled in the real application runtime metered by Satoris. The extension writes a metering event stream to a binary file that’s later read by the Stenos playback tool to reconstruct the episodic memory.
A metering extension is referred to as a probes provider by the engine.
The playback tool, is in fact, the Satoris metering engine and more. The Stenos playback tool assumes the role of the instrumentation agent in the real application in calling into the metering engine, via the Probes Open API, and in the creation and running of mirrored threads simulating the call execution of instrumented methods metered within the original runtime.
What’s extremely nice about this is that it’s possible to enable any of the metering extensions included in Satoris within the Stenos playback, that includes the Stenos metering extension allowing for the creation of new memories from old ones transformed by other metering extensions enabled. It also means that relatively expensive data collection extensions such a trace trees, called tracking in Satoris, can be deferred to playback time.
In the re-experience of a recorded memory the level of detail monitored can be altered as can the types of data collected and the visualizations employed.
What if a single software process could mirror, simulated playback, the execution of an entire system of metered application runtimes streaming episodic metering memories over the network in near real-time? Simz builds on the concept of event simulation introduced in Stenos with the ability to support hundreds of application runtime, making it appear to the underlying metering engine that all threads within the real source application runtimes are present within this simulated machine universe — a machine Matrix!
Much like the Stenos playback tool, Simz is basically an episodic memory recollection layer on top of the Satoris metering engine running within another mirrored runtime with its own engine and extension configuration.
Want to create a memory of the entire machine universe? Simply turn on the Stenos metering extension within the Simz playback runtime. No need to have the monitoring console pull large amounts of duplicate data from each individual application runtime in order to understand what is globally happening. Just enable the console extension in the Simz playback runtime.
Satoris is to adaptive runtime monitoring what Sentris is to adaptive runtime management. Management follows monitoring. But this is not management in the typical application performance monitoring sense, where human operators and their processes watch over monitored applications via junk laden charts, alerts, and “management” dashboards.
Sentris is effectively Satoris with a number of extensions that can be configured and enabled within the application runtime to adaptively control the throughput, response time, and jitter across executing threads invoking instrumented and metered methods. Sentris is the Big Brother of Satoris. It uses the metering data and the probe event hooks offered by the metering engine to inject and employ various quality of service (QoS) techniques such as rate limiting, prioritization, quotas, and auto-safe throttling — techniques typically found in network management and flow based control systems.
The QoS metering extension included in Sentris is based on a resource reservation mechanism with a resource being mapped to a meter’s metering for a particular probe which is mapped to a QoS service policy definition.
Policing Software Service Processing - Part 1
This article is part of a series of articles on effective ways of controlling concurrent code execution using…