We are pleased to announce the immediate availability of JXInsight/Simz 1.0 delivering a revolutionary new application performance monitoring (APM) approach based on a highly scalable discrete event simulation engine that replays, in near real-time, the execution behavior and resource consumption of metered activities (code, requests, transactions, interactions) across an entire infrastructure of instrumented application runtimes within a single simulated (virtual) application runtime.
Seven Key Features
- Simulated: Replay of metered execution behavior across an entire application runtime through a convergence of both time and space
- Simplified: An incredibly easy way to tackle behavioral analysis and runtime diagnosis across distributed/parallel executions
- Singular: A single application/activity monitoring glass plane and resource metering model
- Speed: Near real-time (sub ms delay) application performance monitoring and service level agreement reporting/alerting
- Standardized: An universal binary protocol, model and plugin API irrespective of topology, language or runtime
- Secure: An isolated monitoring environment for both developers and operations staff for runtime observation and inspection
- Scalable: Monitor execution performance and behavior across hundreds or thousands of processes and threads
Benchmarks: Local – Distributed – Cloud (coming)
Time contributes to the complexity and risk in managing systems, services and applications when there are significant differences (time delays) between when something is observed, when it is judged and when it is reacted upon. Operations are being tasked with managing behavior (cause) and resulting events (effects) that have a time resolution as low as few microseconds whilst it collects, processes, sorts, filters, and analyses measurement data in seconds even minutes and then reacts in minutes even hours. By the time an engineer acts the basis for such has probably already elapsed and being invalidated.
Similar to time there is a disconnect in the space dimension in what can be held within the brain’s short term memory (or displayed on a dashboard) and the number of elements that can now be provisioned (then monitored & managed) at a time, ignoring what happens beyond their sphere of control. Amazingly operations are still trying to use the same old techniques (metrics) and processes used to manage a single mainframe or a small cluster of homogenous servers. Not only is the management (problem) space increasing in size but its rate of change is accelerating along with increasing diversity and wider dispersion and distribution. Bigger and faster growth & change rates sounds like a disaster.
In tackling the time dimension, JXInsight/Simz offers near real-time (sub-millisecond) simulation and replay of application execution behavior. Its unique architecture allows it to compress, consolidate and converge space whilst eliminating delay in the observation and diagnosis of execution behavior spanning hundreds of application runtimes.
Big data is nothing new in the application performance monitoring space. Applications have been generating huge amounts of data using various logging and metric utilities. The data collected by such tools is then either pulled or pushed to some central management server wherein it is filtered, transformed, aggregated and stored/updated for offline viewing by operators connected to the server via management consoles and reporting dashboards. Behavior becomes data then deprecates and dies.
JXInsight/Simz is very different in its approach to the data collected pertaining to a call that is metered and its consumption of resources during execution. The data is pushed in near real-time to one or more event simulation services where it is used to drive the execution of playback threads with one for each metered application thread. Each playback thread makes the same underlying metering calls made by the instrumented methods in the application and with the exact same meter readings. Behavior becomes data and is then resurrected becoming behavior all over again but in a slightly different form.
Whilst the JXInsight/Simz service does allow one to determine the process of a simulated thread within its near real-time application replay runtime it is the threads and their metered activities that are given center stage as well as the metered resource usage recorded. This is incredibly important in the context of cloud computing elasticity with nodes being provisioned and decommissioned at fine granularities and JVM runtimes starting and stopping even more frequently as applications scale up and down in response to dynamic workload demands.
When it comes to software observation and diagnosis across hundreds or thousands of transient machines and processes why not have a single pane of glass on a single process that replays / simulates the work of thousands of threads irrespective of location. A kind of Matrix in which the streams of a software process are played out in another software process – all together and in near realtime.
JXInsight/Simz makes it incredibly easy to get the big performance picture on BIG DATA processing by feeding in near real-time the metering data collected in local application runtimes to remote simulation services in which the whole distributed and parallel execution is (re)played out by threads. Getting a stack dump across all active application runtimes has never been easier or faster.
Anyone that has spent time attempting to introduce business analytics, costing and billing into an application or service after it has been designed, tested and more than likely deployed into production is well of aware of the challenges both technical and organizational faced in doing so. Operations and developers are always weary of the potential impact each additional cross cutting concern introduced into application runtime that falls outside of its functional specification and design, especially when such late bindings are not fully understood, not tested and not self regulated to control and budget (overhead) impact. In some cases it is simply not possible to perform such integrations collocated within the application runtime without forcing a change to the configuration of the application due to runtime library dependency mismatches, especially when such integrations require the usage of client side libraries for communicating with backend service end points which have their own third party library dependencies (logging is a typical breaking one).
This is another area in which JXInsight/Simz has drastically simplified the problem space with its near realtime metering replay technology. With JXInsight/Simz, billing integrations via our
udr metering extension become so much easier, secure and scalable as the actual work is now completely divorced (in terms of location and even time) from the application except for the metering feed that drives the metering calls made by the simulated application threads, which in turn feeds into the integration pipeline with the external billing service. Operations need only concern themselves with setting up metering within the application runtime. They do not necessarily need to know how the metering feed piped to the Simz service is consumed by the various metering enabled extensions offering integration with business analytics, runtime governance, as well as chargeback and billing solutions.
Safe and Secure Observation
With JXInsight/Simz there is no requirement to have the application code base accessible to the simulated environment giving organizations the added data protection that no actual state within the application is available other than what is collected by the metering engine in the firing of probes and usage of it’s environment interface. Customers have complete control over how much of the actual application behavior is feed to backend simulation processes and can build a partial parallel universe of their application topology that offers many of the same runtime performance diagnostics capabilities available in normal application runtimes including integration with legacy system management tools with JMX, REST or Logging connectors and adaptors.