JINSPIRED Releases New Version of Lightweight Java Monitoring Tool: OpenCore
OpenCore is a performance monitoring library that focuses on low-latency applications. This means it attempts to have as little overhead as possible. The library also specifies an integration model that emphasizes separating "probes" from "measures" from "meters". A probe is an arbitrary begin and end in a program's execution (say, the beginning and end of a method). A meter is point-in-time sample of something like cpu utilization or clock time. A measure is some summary of a bunch of samplings from meters across a set of probes. So, for example, one might say "probe all method entrances and exits. When each probe fires, then meter the elapsed cpu time. Now tell me what the measure of average cpu time per method is."
According to OpenCore, the advantage of separating the three is that overhead can be minimized for activities that will never be measured because "Unlike all other solutions there is no explicit reference to how an activity is measured or whether its firing is indeed measured – this is controlled via configuration of the actual metering runtime by an administrator".
As the project's HowTo describes, using OpenCore on a project involves the following basic steps:
- Add the OpenCore native agent from the command line with -agentpath and -javaagent arguments (note: some of the agent uses AspectJ)
- Add some OpenCore jars to the classpath
- Enable JMX
- Create a configuration file that specifies what to be monitored and how
From that point forward, how deeply the application becomes intertwined with OpenCore depends on how it is configured. At its most basic level, OpenCore simply captures method call counts and reports them to JMX. However, the agent was designed to be pluggable so developers can enable more sophisticated built-in metrics and statistics or can inject their own custom-built metrics that capture just about anything and report it anywhere.
The library claims to have a lower overhead, especially for instrumented methods that have been "turned off." For example, in one OpenCore-authored benchmark, VisualVM profiling (which ships with the Sun JDK) was 2-3 times slower than OpenCore probes.
In addition to being used for simple performance diagnosis, OpenCore also purports to "unify multiple application, system, and business related management domains under one model," meaning that it could be used for automatically monitoring and adjusting capacity, metering usage for chargeback, and tracking SLA conformance. This unified vision, however, depends on vendors in those domains adopting the OpenCore technology.
Future releases promise performance monitoring for non-JVM languages like .NET and native Ruby, Python, and PHP, though no specific timeline has been released.
As a final note, developers should note that OpenCore is not open as in "open source" but rather open as in "publicly documented APIs with defined integration and extension points." As William Louth's comments on a recent discussion thread clarify, OpenCore is a commercial product.
I hope you don't mind if I elaborate on a few items you have called out.
- Probes in OpenCore metering are represented by composite name parts which in the metering get transformed into metering (cost) assignment hierarchies. Names are not tied in anyway to the actual execution that is being metered so it can very easily represent code constructs but also business activities or contextual request identifiers (urls, sql,...). This makes it possible for OpenCore to be able to meter in terms of Python, Ruby and Java namespaces within the same runtime (assuming you are using Jython and JRuby).
2. Whilst out-of-box OpenCore supports standard performance measurements (meters) the metering model can very easily manage measures related to cost, value, or some high level performance measure such as db.time. Performance is just a particular metering profile (set of meters).
This makes it an incredibly scalable solution for any type of performance management whether it is application management or cost management even billing.
3. With regard to overhead OpenCore Probes for Java is actually hundreds to thousands of times more efficient than other solutions due to our dynamic strategy based metering. With our hotspot strategy installed the overhead of a particular metered method invocation can drop from 180 ns to 0.8 ns once we have deemed the method a non-hotspot. We think we can go even lower with a new BCI agent we are developing.
And if you don't like our many built-in strategies you can implement your very own.
OpenCore not only supports development of cost aware runtimes and services it is cost aware itself.
The only dependency that an application has is when it wants to become more cost aware. Out of the box our instrumentation is dynamically applied though we support mixing of manual instrumentation or other custom BCI forms in the same runtime.
4. We are pursuing standardization for each runtime and platform. But at the same time we realize this path is fraught with many roads blocks (especially when dealing with the likes of IBM and Oracle) so we are currently preparing an open source licensed distribution of OpenCore which includes just the interfaces and the bootstrap classes to enable competition on implementation of the API which is generally not something pushed by many open source projects. We will also ship a basic reference implementation of the Open API but without the many optional probes providers that are available with OpenCore & JXInsight current distributions.
My grand vision is for all future software (especially those targeting cloud platforms & runtimes) will be metered enabled straight out of the box. Make it easy for one to create cost (in the abstract sense) aware applications, services, and libraries. One need only request a SavePoint in code and then at a later point in the execution generate a ChangeSet (metering profile) by comparing it with the current thread (or execution context) metering.
Re: Much appreciated
With OpenCore’s new optional recorder probes provider you can now efficiently log to a binary file a complete recording of metered probes and meter readings. The recording can then be replayed offline without any runtime dependencies on the original target environment and classpath other than OpenCore’s opencore.jar library and native agent.
What is truly unique about our approach is that for all intents and purposes there is no distinction between the metering of the original production environment and that of the play back. In playback threads are recreated, probes are fired and meters read as per the values recorded. The metering engine does not even know whether its a simulation or not so optional probes providers performing dynamic filtering or collecting data collection can be enabled including reporting plugins and management integrations.