JXInsight/Simz – Many Parallel Worlds

In Where Big Data meets Big Activity in the JVM it was shown how JXInsight/Simz allows the monitoring of metered thread execution of many Java application runtimes from within a single Java runtime via the near real-time replay of metering feeds by simulating threads. Effectively creating a consolidated parallel world but without the overhead of state (object) and code (class) management for each and every Java application runtime.

Since the JXInsight/Simz service is a metered application runtime itself the simz metering extension can be enabled to forward the metering feed onto another service instance creating multiple parallel worlds. One reason for doing so would be to provide a filtered partial view to monitoring client consoles connected to the second service instance.

The actual application runtime would have a jxinsight.override.config file with the simz client metering extension enabled.

j.s.p.simz.enabled=true
j.s.p.simz.client.connector.host=localhost
j.s.p.simz.client.connector.port=5151

Then the directly connected simz service would have the simz client metering extension enabled in its jxinsight.override.config file along with filtering.

j.s.p.simz.service.reactor.port=5151
j.s.p.simz.enabled=true
j.s.p.simz.client.connector.host=localhost
j.s.p.simz.client.connector.port=5252
j.s.p.simz.filter.enabled=true
j.s.p.simz.filter.include.name.groups=com.acme
j.s.p.simz.filter.exclude.name.groups=com.acme.db,com.acme.io

Running both simz service instances on the same node requires the default port of 5151 to be changed for the indirect simz service instance.

j.s.p.simz.service.reactor.port=5252

Here is a screen recording showing such filtering of metering feed from one simz service to another.

Another use case for this capability is to augment the metering feed within the direct simz service with additional meters typically derived (calculated) from execution behavior (probes) and meter readings within the original source metering feed which are then forwarded along to the next chained indirect simz service. An example of such a derived meter would be a unit.cost meter used for showback, chargeback or billing purposes. The derived metering would be passed on without the actual activity used as the basis for the meter being included in the feed.

Here is example of a meter config applied to the direct simz service instance configuration above.

j.s.p.meter.probes=db
j.s.p.meter.probe.db.group=com.acme.db
j.s.p.meter.probe.db.meter=clock.time
j.s.p.meter.probe.db.name=db.time

The last change adds the following to the indirect simz service config.

j.s.p.simz.service.meters=clock.time,db.time

Here is a screen recording showing this in action.

Finally another reason for creating many parallel worlds of an applications metered execution behavior would be to isolate each IT management domain (performance, capacity planning, auditing, service level) from each other.