Chapter 2. New features
Cryostat 2.4 introduces new features that enhance your use of the Cryostat product.
ARM64 architecture support
Cryostat 2.4 introduces support for using Cryostat on Red Hat OpenShift Container Platform 4.11 or a later version that runs on an ARM64 (aarch64) architecture.
Dynamic JFR recordings based on MBean custom triggers
In Cryostat 2.4, you can enable the Cryostat agent to start JFR recordings dynamically based on MBean custom triggers.
A custom trigger condition is based on MBean counters that can cover a range of runtime, memory, thread, and operating system metrics. You can include one or more MBean counter types as part of the custom trigger condition for a JFR recording. You can also specify a duration or time period as part of the trigger condition, which means the conditional values must persist for the specified duration before the condition is met. Each custom trigger definition must also include an event template that the Cryostat agent can use for the recording.
The Cryostat agent supports smart triggers that continually listen to the value of the specified MBean counters. Triggering occurs if the current values of the specified counters match the configured values in the custom trigger for the specified duration. If triggering occurs, the Cryostat agent dynamically starts the JFR recording at that point based on the given event template.
A JFR recording will not start dynamically if the custom trigger condition associated with this recording is not met.
Agent HTTP API support for JFR write operations
The Cryostat 2.4 agent provides an HTTP API that the Cryostat server can use as an alternative to an application’s JMX port. By attaching a properly configured Cryostat 2.4 agent to the workload applications that you deploy, you can use the full Cryostat feature set without any need for your target applications to expose a JMX port.
This enhancement enables the Cryostat agent to accept on-demand requests to start, stop, and delete JFR recordings for any target JVMs that have an agent HTTP connection. This supersedes the behavior in the previous release where the Cryostat agent provided a read-only HTTP API that supported a limited set of JFR operations only.
By default, the Cryostat agent is not enabled to start and stop JFR recordings based on on-demand requests from the server. If you want the Cryostat agent to service these types of requests, you must set the cryostat.agent.api.writes-enabled
property to true
in your target application’s configuration.
Dual HTTP and JMX discovery registration
If the Cryostat 2.4 agent detects that JMX is also configured on your target application, the agent publishes itself to the Cryostat server with both agent HTTP API definitions and JMX URL definitions. In this situation, you can use whichever configuration option you prefer.
Standard agent JAR file without any dependencies
In Cryostat 2.4, you can choose to deploy the Cryostat agent by using a standard JAR file that contains the agent code without any dependencies. For more information, see Choice of agent JAR file distributions.
Choice of agent JAR file distributions
Cryostat 2.4 distributes two different variations of the Cryostat agent’s JAR file. Depending on your setup requirements, you can use either of the following types of agent JAR file:
An all-in-one "shaded" JAR file that is self-contained and includes the agent code and all of its dependencies
This provides the most convenient form of Cryostat agent to include in your existing applications, because you need to include only one additional agent JAR file.
A standard JAR file that contains the agent code without any dependencies
This is useful if you know that dependency conflicts exist between the agent and your workload applications, and you intend to apply your own strategies to resolve any dependency conflicts.
This supersedes the behavior in the previous release, which provided only one distribution of the agent as an all-in-one "shaded" JAR file.
Default restriction on server host or IP address ranges that the agent can register with
Cryostat 2.4 introduces a new cryostat.agent.baseuri-range
system property that enables you to set limits around the resource location (URL) of the Cryostat server that the Cryostat agent advertises itself to. The Cryostat agent can use the cryostat.agent.baseuri-range
property to check if the URL that you specified in the cryostat.agent.baseuri
property is within an acceptable range of host names or IP addresses.
This feature helps to protect users from accidentally misconfiguring the server’s base URI, which might otherwise result in the agent advertising itself to an incorrect service or a service outside your control. Misconfiguration of the server’s URL could lead to a data leak from your Cryostat agent instance to a service outside of your cluster or data being routed over the open internet.
Depending on the level of security restrictions you want to apply, you can set the cryostat.agent.baseuri-range
property to any of the following values:
loopback
This provides the highest level of restrictions. The agent connects to the server only if the server URL has an address such as
localhost
or127.0.0.1
.link_local
This provides the second-highest level of restrictions. The agent connects to the server only if the server URL has an address in the link-local range or an address that is already within the highest level of restrictions.
site_local
This provides the third-highest level of restrictions. The agent connects to the server only if the server URL has an IPv6 "site-local" or IPv4 "private" address or an address that is already within a higher level of restrictions.
dns_local
This provides the fourth-highest level of restrictions. The agent connects to the server only if the server URL has an address with a
.local
or.localhost
suffix or an address that is already within a higher level of restrictions.NoteThis is the default setting. This level of restrictions suits Cryostat server and agent deployments in Red Hat OpenShift Container Platform, because the Cryostat server is typically referenced by an internal OpenShift Service address such as
https://cryostat.my-namespace.svc.cluster.local
.public
This removes any restrictions. This setting matches the behavior in the previous release where the agent could connect to any configured host or IP address.