Visit Support

CRS Configuration Options

The Connected Runtime Service (CRS) is the component inside the JVM that runs your applications or in the Intelligence Cloud Agent that runs next to your applications. CRS collects the dependency information of your application, and sends it via the Forwarder to Azul Intelligence Cloud. On this page, you find all the configuration options for normal usage. Next to these options, there are also Diagnostics Configuration Options.

CRS Mode

This configuration option is only applicable when you use an Azul JDK or JRE. It’s not available for the Azul Intelligence Cloud Agent.

The CRS Mode can be configured with the -XX:AzCRSMode startup argument and has the following options:

  • auto: This is the default value. CRS decides whether it needs to start in the main method, and excludes tools like javap, javac having a specific main method in

  • on: Forces CRS to start, if all required configurations are available (e.g. endpoint), even for tools like javap, javac.

  • off: Forces CRS to be disabled.

Usage Example

java -XX:AzCRSMode=on -jar MyApp.jar

CRS Runtime Instance Tags

A runtime tag is a user-defined key-value pair that is associated with an instance. Tags are used to search, categorize, and organize instances logically in the Azul Intelligence Cloud Web UI. Unlike instance IDs, tags are not unique. You can add the same tag to multiple instances as well as add multiple tags to one instance.

Applying Tags

Tag keys must begin with a letter. Both key and value may contain lower and upper case letters, and numbers. These additional characters are also allowed:

ALLOWED_KEY_EXTRA_CHARS = "-_." ALLOWED_VALUE_EXTRA_CHARS = "-_. :/@" <-- Includes space
Tags can be provided both as environment variable and in command line options. When using both, the result will be combined. It’s recommended to use environment variables as it allows AZ_CRS_ARGUMENTS to be mostly the same for each JVM.

Special Tags

This tag is handled in a specific way with the system:

Tag Description Example


To use the "Code Inventory Summarization" feature, you need to configure an AppEnv value on the machine where you run the JVM. The value is, for example, the application name. This information is sent through the Forwarder to the Azul Intelligence Cloud system, together with information about the components, classes, and methods that are used.


How to Use Tags

Tags can be specified with a command line argument or environment variable:

# With command line option"system-prop.tag_1=system prop/value@1; system_prop_tag.2=system prop:value/2" # With environment variable export CRS_TAGS="env.tag-1=value:1; env_Tag_2=value 2"

For example, using the command line option:

java -XX:AzCRSMode=on \ -XX:AzCRSArguments=api.url={forwarder_endpoint} \"AppEnv=MyApplicationTag" \ -jar MyApp.jar

It is important that you properly tag your instances. As a general rule, tagging should reflect the way you categorize your Java applications. For example, you can use "west-coast", "east-coast", and so on to distinguish between different availability zones/locations.

Some instance properties are detected automatically. For example, you don’t have to tag Java versions, because it’s detected by CRS.

CRS Arguments

CRS can be controlled with the following arguments. They need to be specified in a comma-separated value format. Each expression is either <propertyName>=<value>, or just <propertyName> for Boolean properties. These are the available properties:

Argument Default Description



Location of a properties file to configure CRS.



This is the base URL of your Forwarder instance. If null, your runtime will perform a DNS-based lookup to locate its Forwarder. If no Forwarder is specified anywhere, CRS will be effectively disabled.

The Forwarder endpoint must be in URL format, e.g. https://FORWARDER_IP:443.



Use this argument when you can’t adjust the command line, to enable or disable the CRS agent. Enabling the CRS agent with enable=true has the same effect as -XX:AzCRSMode=auto.

When you specify the -XX:AzCRSMode runtime flag, this enable environment variable flag, gets ignored.



Number of milliseconds to hold a JVM alive at its end, providing time to send the collected data to the Forwarder. Raise the value to provide time to short-lived microservices. The provided value will be used as a maximum, if CRS takes less time (down to 0), the delay will not use the fully defined duration.



Number of milliseconds to delay the CRS start. The default enables integration with major Java frameworks. Lower to 0 for short-lived microservices.



Suffix of the DNS record to query for an endpoint.



Flag to define if the content of files must be sent to Intelligence Cloud.



The level of logging for CRS. Options are (case insensitive): trace, debug, info, warning, error, off.

The use of the trace level is discouraged, since the size of the output will be enormous.



If set, this keystore will be used to authenticate the JVM with the Forwarder. Set this to a Java Keystore file if you are using self-signed certificates.

Usage Examples

# Environment variable for Azul Intelligence Cloud Agent export JDK_JAVA_OPTIONS="-javaagent:${AGENTDIR}/ic-agent.jar=accessor=${AGENTDIR}/ic-agent-accessor.jar,expression1,expression2,expression3 \ -DaagentDir=${AGENTDIR} \${AGENTDIR}/agent.all.policy" # Command line option for Azul JDK or JRE java -XX:AzCRSArguments=expression1,expression2,expression3 -jar MyApp.jar # Environment variable for Azul JDK or JRE export AZ_CRS_ARGUMENTS=expression1,expression2,expression3

Where to Specify Configurations

Depending on how you run your Java applications to send data through the Forwarder to Azul Intelligence Cloud, several options are available to configure your runtimes.

Azul Intelligence Cloud Agent

For the Azul Intelligence Cloud Agent, both Tags and Arguments are is configured with environment variables. Tags are defined with CRS_TAGS, while arguments are added in the agent configuration with JDK_JAVA_OPTIONS.

export CRS_TAGS=YOUR_CRS_TAGS export JDK_JAVA_OPTIONS="-javaagent:${AGENTDIR}/ic-agent.jar=accessor=${AGENTDIR}/ic-agent-accessor.jar,YOUR_CRS_ARGUMENTS \ -DaagentDir=${AGENTDIR} \${AGENTDIR}/agent.all.policy"

For example:

export CRS_TAGS="env.tag-1=value:1; env_Tag_2=value 2" export JDK_JAVA_OPTIONS="-javaagent:${AGENTDIR}/ic-agent.jar=accessor=${AGENTDIR}/ic-agent-accessor.jar,sendPOMData=false,log=info -DaagentDir=${AGENTDIR}${AGENTDIR}/agent.all.policy"

Azul JDK or JRE Runtime

To enable and configure your instances running with an Azul runtime and CRS, you can choose to use one of these three options:

  1. JVM command line arguments

  2. The AZ_CRS_ARGUMENTS and CRS_TAGS environment variables

  3. A .properties file

The connected runtime looks for the configuration parameters in the order described above. You can use a combination of these options. If you set a parameter in several ways, for example via both the environment variable and configuration file, the JVM uses the value that comes first in the order given above.

In addition, the Forwarder address can be configured via DNS records. See Service discovery via DNS.

JVM Command Line Arguments

Pass configuration parameters to the CRS (Connected Runtime Service) in the Azul JVM by using the -XX:AzCRSArguments command line argument:

Minimal command that sets the api.url parameter via JVM arguments.:
java -XX:AzCRSMode=on \ -XX:AzCRSArguments=api.url={forwarder_endpoint} \ MyApp
A more extended example via JVM arguments:
java -XX:AzCRSMode=on \ -XX:AzCRSArguments=api.url={forwarder_endpoint},log=debug,delayTermination=120000,delayInitiation=0 \{tags} \ MyApp

Environment Variables

You can use dedicated environment variables to enable and control all JVM processes for Azul Zulu and Zing distributions. When the environment variables are present, they will automatically apply to any newly started JVM, enabling CRS.

Substitute your forwarder_endpoint in the following example.

Starting with environment variables and optional arguments:
export CRS_TAGS={tags} export AZ_CRS_ARGUMENTS=enable,api.url={forwarder_endpoint},log=debug,delayTermination=120000,delayInitiation=0 java MyApp

Properties File

A third way to set the CRS parameters is to use a local .properties file. There are two default locations where CRS looks for the properties file, and you can specify a custom properties file as a command line argument. CRS looks for the properties file in the following order:

  1. the file provided via the -XX:AzCRSArguments=props=/path/to/ argument

  2. ~/.az_crs/ in the user’s home directory

  3. $JRE/lib/, where $JRE is the directory where the JRE is located