The 1.2 releases of Satoris, Stenos and Simz have been published. The releases include a new
budget metering extension that compliments the adaptive
hotspot metering extension with call path based budgetary cost control of measurement overhead. The metering extension can be used in online mode, online simulated mode and offline simulated mode.
The Sentris 1.2 release, which also includes the
budget metering extension, includes two new metering extensions,
rvalve, that adaptively control the concurrent execution of instrumented methods for optimal throughout and/or response time.
Seeing is believing! Check out our video channel.
The first official release of Sentris (Sentry + Satoris) has been published. In this initial release we have packaged up our
qos metering extension that brings Quality of Service (QoS) techniques to the application runtime. A subsequent release of Sentris will make available the many adaptive control valve metering extensions we have designed and developed over the last year and more.
We have also released a bug fix update to the metering engine that is applicable to all products. We recommend that you upgrade.
The Satoris for JRuby 1.1.1 includes an important bug fix caused by the accidental inclusion of an experimental condition statement within the instrumentation agent in determining whether the particular instrumented
DynamicMethod instance should indeed be metered. The condition checked whether the JRuby
DynamicMethod.getRealMethod returned the call target. If the result returned did not match the call target then it was assumed to be a wrapper like extension of
DynamicMethod implementation and ignored. Unfortunately this is not the always case especially for methods that are “jitted” by the JRuby compiler.
Our vision of application monitoring and management is founded on the belief that the “future is simulated”. All software execution behavior will eventually be simultaneously recorded, replicated and replayed in one or more simulated application universes, and in near real-time. The focus will shift from querying data in order to reason about the world, both digital and physical, to observing, evening participating in, mirrored metered behavior…time and again.
The vision is both incredibly exciting and hugely empowering. It is also novel and mystifying so to help you envisage what the future will be and to stimulate interest in this particular approach to application management complexity we are providing FREE editions of both Stenos and Simz, licensed for non-production usage only.
We have also updated Satoris to include both the
simz metering extensions that enable the magic of mirrored simulation, both in time and out of time. In addition we have added the
entrypoint metering extension into both the Community and Subscriber Packages.
The Satoris 1.0.4 includes a number of miscellaneous load-time class instrumentation corrections as well as some additional built-in filtering of known problematic classes. The monitoring console client toolbar will now only enables
tag functionality when the appropriate extensions are detected as enabled within the server runtime.
Note: You must deploy the new agent library, that includes an updated
console metering extension, to all connected server runtimes.
The instrumentation approach used by the Satoris for JRuby agent has been changed to give greater Ruby code coverage. Previously the agent only metered
DynamicMethod.call() method invocations originating from instrumented
CallSite class implementations. With the new approach the
DynamicMethod class is instead instrumented with the collapsing of chained overloaded
call() methods performed at runtime so as not to overstate the count.
By default the agent will not performance measure (meter) the execution of methods marked as “builtin” in by JRuby runtime. To change this behavior add the following to the
Alternatively in short form.
The first official release of Satoris for JRuby Community Package is now available. The agent bundled within this distribution will instrument the
org.jruby.* codebase and during the execution of the JRuby runtime translate
DynamicMethod.call() method invocations into the corresponding Ruby language versions.
Because by default the JRuby command line utilities places the
jruby.jar on the
bootclasspath there is an additional setup step.
To run a
loop.rb script you would normally execute
jruby -J-server loop.rb
There are 3 approaches to integrating Satoris. The first approach uses the
-J-ea flag to prevent the
jruby script using the bootclasspath.
jruby --server -J-ea -J-javaagent:/Applications/satoris-jruby-1.0.3/bundle/satoris-javaagent.jar loop.rb
The second approach uses the
VERIFY_JRUBY environment variable to prevent the
jruby script using the bootclasspath.
export VERIFY_JRUBY=yes jruby --server -J-javaagent:/Applications/satoris-jruby-1.0.3/bundle/satoris-javaagent.jar loop.rb
-J-ea as a command argument actually causes
VERIFY_JRUBY to be set to
yes within the default ruby script.
Finally you can use the
JAVA_OPTS environment variables.
export VERIFY_JRUBY=yes export JAVA_OPTS=-javaagent:/Applications/satoris-jruby-1.0.3/bundle/satoris-javaagent.jar jruby --server loop.rb
The JRuby agent much like the Java agent will search for configuration files within the working directory of the process if the
jxinsight.home system property is not set. To override any default settings such as the
hotspot metering extension
threshold, create a
jxinsight.override.config and then path to the enclosing directory as follows:
export VERIFY_JRUBY=false jruby --server -J-Djxinsight.home=/Applications/satoris-jruby-1.0.3/conf/ -J-javaagent:/Applications/satoris-jruby-1.0.3/bundle/javaagent.jar loop.rb
The Satoris 1.0.3 probes metering engine is now better optimized for profiling methods that appear repeatedly, in large numbers, on the instrumented thread call (probe) stack. This particular phenomenon is all too familiar with functional (styled) programming languages and libraries running within the JVM.
As well as optimizing the performance of the underlying probe pooling we have added the Recursive Pack to both the Community and Subscriber packages, which includes the NonReentrant and NonRecursive metering extensions.
All navigation and toolbar icons have been updated to support Retina displays including those within user dialog windows. We have also improved the spacing and grouping of toolbar icons.
Note: You can change the font used by the console with the
-Djxinsight.console.font="Open Sans" system property.
The Satoris 1.0.1 release includes a number of Console UI enhancements, refinements and corrections that speed-up and simplify the initial user experience as well as offering a more consistent visual style and graphical quality across platforms and runtimes.
We have redesigned the icon set for labeled probes and it looks beautiful on Retina displays. Table column headings are now colored to make it easier to visualizing and mentally associate statistical measures in tables wit chart points. To conserve precious screen real-estate column values are displayed abbreviated though the actual values are still available for inspection in the underlying table cells as well as in tooltips.
The icon represents an aggregate, a probe name group. The icon represents a specific Java class aggregate. Actual probes that have yet to be classified by the
hotspot metering extension have as an icon. For tagged probe, injected into runtime from within the console via the
tag metering extension, we use as an icon. When a probe is classified as a hotspot it gets as an icon. Eventually a hotspot labeled probe becomes unmanaged hotspot and gets as an icon.
Note: By default the
console metering extension does not include disabled probes in snapshots returned to the monitoring client console. When included such probes have as an icon.
We have refined the hotspot timeline visualization and added charting of both the inherent total and inherent average for the selected probe.