Discovering Java applications on a VM

Using Concert Workflows, you can run auto-discovery workflows to ingest Java® applications running on virtual machines (VMs).

Overview

Concert automatically identifies your runtime environments and maps your application topology by deploying targeted workflows. Rather than running as a standalone feature, the Java Application Discovery tool operates as a unified compatibility extension within Concert's existing architecture. This framework allows Concert to seamlessly discover workloads across a variety of runtime options, including Apache Tomcat, WebSphere Application Server, Spring Boot, and JBoss.

The workflow identifies:
  • applications along with its associated Java components running on Linux® servers, focusing on Spring Boot apps with embedded Apache Tomcat.
  • related Java components and their libraries, but does not directly detect common vulnerabilities and exposures (CVEs) or certificates.
  • applications running on a standalone Apache Tomcat through Java Management Extensions (JMX) and those using the Java Development Kit (JDK), as well as applications running on JBoss and WebSphere (both Traditional and Liberty).
After downloading, importing, and configuring this workflow in your Concert Workflows instance, you can use it to:
  • Automatically discover Spring Boot Java applications running on a target VM.
  • Generate and upload the application SBOMs to your Concert instance.
  • Collect operational metrics indicating the resilience and composition of the discovered applications.
  • Generate resilience posture assessments that align the collected metrics with critical non-functional requirements (NFRs) related to the application.

After running the workflow, you can view the ingested applications in your Concert Inventory and the resilience assessment results in the Resilience dimension.

Supported ingestion metrics matrix

The discovery framework extracts unique operational indicators depending on the exposed management layer of your runtime type. Use the following reference matrix to identify what metrics Concert tracks for your specific technology profile.

Table 1. Java metrics mapping by technology layer
Metrics Tomcat Actuator Endpoints JCMD commands WebSphere JBoss WebSphere traditional

num_400_errors

Yes

Yes

Optional

-

-

-

num_401_errors

Yes

Yes

Optional

-

-

-

num_403_errors

Yes

Yes

Optional

-

-

-

num_4xx_errors

Yes

Yes

Optional

-

-

-

num_http_only

Yes

Yes

-

Yes

Yes

Yes

num_old_pause_time

Yes

Yes

Yes

Yes

Yes

-

num_restarts

Yes

-

-

-

-

Yes

num_runtime_running_as_root

Yes

Optional

Yes

Yes

Yes

Yes

num_server_on_http

Yes

Yes

-

-

-

-

num_young_pause_time

Yes

Yes

Yes

Yes

Yes

-

pct_eden_mem_space_usage

Yes

Yes

Yes

Yes

Yes

-

pct_mem_old_gen_usage

Yes

Yes

Yes

Yes

Yes

-

pct_survivor_mem_space_usage

Yes

Yes

Yes

Yes

Yes

-

pct_error_rate

Yes

Yes

-

-

-

Yes

pct_thread_usage

Yes

Yes

Yes

Yes

Yes

Yes

pct_unencrypted_db_services

Yes

Optional

Optional

-

-

-

pct_unencrypted_externalized_services

Yes

Optional

Optional

-

-

-

pct_unencrypted_internalized_services

Yes

Optional

Optional

-

-

-

max_session_alive_time

Yes

Yes

-

-

-

Yes

max_session_timeout

Yes

Yes

-

Yes

Yes

Yes

num_current_active_sessions

Yes

Yes

-

Yes

Yes

Yes

num_max_active_sessions

Yes

Yes

-

-

Yes

Yes

num_persistent_authentication

Yes

Optional

Optional

-

Yes

-

num_rejected_sessions

Yes

Yes

-

-

-

Yes

Note: Empty cells indicate that support is planned or in the roadmap.

Before you begin

  • Create a resilience profile (optional) that specifies NFRs from the Java Runtime NFR library. These NFRs are assessed against metrics collected from the Java applications to which this profile is assigned.
    Note: If you create a custom resilience profile, you must modify the resilience_profile input variable in the Concert Workflows workflow editor (Step 3). If you do not create a custom profile, one is automatically generated when you run the auto-discovery workflow for the first time.
  • The application must have the Spring Boot Actuator, Apache Tomcat, JBoss or WebSphere MicroProfile metrics endpoint (/metrics), or the jcmd utility configured and enabled to collect and expose metrics.

Step 1: Download and import the prebuilt workflow

In Concert Workflows, in the Workflows page, click Create workflow > Select from library, choose the Discovering Java applications on a VM workflow, and import it. For more information about importing Concert-specific workflows into Concert Workflows, see Creating workflows.

Once the flow (.zip file) is downloaded and imported into Concert Workflows, you have the following folders:Screenshot showing the extracted Concert Workflows folders.

  • The Identification folder is used to customize the flow.
  • The Prerequisites folder tests and validates the prerequisites.
  • The Discovery folder uses SSH credentials to discover Java applications and to collect raw metrics.
  • The Selection folder is used to filter the relevant components.
  • The Processing folder is used to compute the metrics.
  • The Upload to concert folder generates SBOMs and uploads them to Concert.
  • The JAVA Application Discovery file runs the flow.
Note: Importing the .zip file will create multiple folders and sub-flows, but the main workflow is called Java Application Discovery . This is the workflow that you will edit and run.

Optional: Create the required authentications

You can create authentications from the Authentications page or from within the workflow editor by opening a workflow and clicking the Auth button. For more information, see Using authentications.

The workflow requires the following authentications to establish a valid connection with external systems referenced in the configuration.

  • Optional: For IBM Hub - Self (recommended) or IBM Concert API Key: If using the IBM Concert API Key option, you must provide additional details to create the authentication, including the protocol, host, instance ID, API key type (usually C_API_Key), and the API key secret. For more information, see: Authenticating from Concert Workflows to Concert.
    The screenshot of the UI shows how you can create authentication for the IBM Hub - Self service.
    Note: If you already created an IBM Hub - Self or IBM Concert API Key for use with another application, you need not create another. You can reuse this authentication across multiple workflows.
  • For an SSH service for a VM from which images are pulled. The authentication configuration requires you to specify the Host, Port (default is 22), and Username associated with the VM. Optionally, you can also specify a Password and RSA private key details.
    Attention: If the SSH authentication is being used for multiple servers, the host and port fields must be overridable. Select the checkbox next to these fields in the Overridable column.

    The screenshot of the UI shows how you can create an authentication for the SSH service.
Note: Each authentication requires you to enter a unique name. Record the name of both authentications configured, as you need to enter them in the workflow editor in Step 3.

Step 2: Edit the imported workflow

After importing the workflow, you must provide input values, including authentications generated in the previous step.

  1. In Concert Workflows, click Workflows in the side navigation.
  2. Click Discovering Java applications on a VM to launch the workflow editor.
  3. Next to concertAPIKeyAuth, enter the name of the IBM Hub - Self or IBM Concert API Key service authentication you created in Step 2.
  4. Next to VMauth, enter the name of the SSH service authentication (for example, my_vm_ssh_authentication) you created in Step 2.
  5. Open the 0 - id_target_list file from the 0 - identification folder.

    Table 2. User_input
    Variable name Description Example
    app_name Application Name Fullbank-Demo
    deployment_name Name identifying the system deployment framework JBoss-Prod-Cluster
    app_version Application Version 1.1.0
    environment Server Environment Pre-production
    deploy_number Deployment Number 1
    ignored_app_names App Names to ignore in Apache Tomcat [test_tomcat]
    opt_gen_appSBOM Optional Application SBOM Metrics true
    opt_gen_cycloneDX Optional Software Composition false
    concert_auth_key
    Note: The concert_auth_key field is optional when Workflows and Concert are on the same system. In that case, the input can be left empty ("").
    Concert Authentication Key ibmconcert/concert-API-KEY
    resilience_profile
    Note: The resilience_profiled is optional.
    Profile name for profile and posture creation (auto-generated if blank) Fullbank-Demo - Java Runtime Profile
    assessment_period Assessment Period "latest","hour","day","week","month","quarter"
    jvm_configuration List of JVM customizations jvm list
    vm_list List of User VMs vm list
  6. Click Save to save the workflow.
User input for vm_list:
  • target - host address (Optional if credential is linked to one host)
  • credential (SSH authentication set above)
  • isConcertVault - set to true, which takes information from Concert vault
  • SSH port
  • tmpPath (Optional) - provides a temporary folder that can be used
  • unzipPath (Optional) - where unzip is saved, if not in the user path
  • Apache Tomcat:
    • fileBased: true, means that the workflow pulls the Apache Tomcat authentication and configuration from the file where it is stored.
    • fileBased: false, disables flow access to the Apache Tomcat configuration and log files. You must provide a username, password, and port.
      Note: Web server restarts, unencrypted internal communication, 4xx errors, and num_server_on_http metrics for unencrypted web server NFRs are not collected.
      [{
          "target": "test1.ibm.com",
          "cred": "ibmconcert/ubuntu_service_account",
          "isConcertVault": true,
          "port": 22,
      
          "tomcat": {
              "fileBased": true
          }
      },{
          "target": "test2.ibm.com",
          "cred": "ibmconcert/rhel_service_account",
          "isConcertVault": true,
          "port": 22,
      
          "tomcat": {
              "fileBased": false
              "username": "manager"
              "password": "manager",
              "port": "8080"
          }
      }]
    • Non-Tomcat target structure
      When your target environment does not contain an Apache Tomcat process, the system bypasses the Tomcat JMX check pathway entirely. Instead, it uses the standard Java process execution path to evaluate available runtime information such as ports, context paths, and Actuator or metrics endpoints.
      "vm_list": [
        {
          "target": "target.example.ibm.com",
          "cred": "vm-connect-credentials",
          "isConcertVault": true,
          "port": 22
        }
      ]
User input for jvm_configuration

This can be an empty array with a default value [], and only used if the flow does not have the correct permission to detect the information itself or if you need to provide more information.

Table 3. jvm_configuration
Property Type Description Usage
component_name String used to customize the component name Optional
jvm_filename String used to identify the Java application for customization Required
log_path String where to read the log Optional
application_prop_path String where to find the application properties files Optional
context_path String application context path where to find the /actuator Optional
port Integer application port Optional
matchCriteria Object to use the jdk instead of jmx or actuator Optional
[
  {
    "component_name": "spring-framework-app",
    "jvm_filename": "springmicronexus.jar",
    "log_path": "/opt/javaapps/SpringMicro_Nexus/app.log",
    "application_prop_path": ["/opt/javaapps/SpringMicro_Nexus/app.prop"],
    "context_path": "/baseline",
    "port": 8083
  },
  {
    "matchCriteria": [
      { "key": "-Dcatalina.base", "value": "/opt/tomcat" },
      { "key": "--enable-native-access", "value": "ALL-UNNAMED" }
    ],
    "discovery": "jdk"
  }
]

Step 3: Run the workflow or schedule a Concert Workflows job

To run the workflow manually from Concert Workflows:
  1. Go to the Workflows page.
  2. Click the overflow menu (in the Actions column) next to the workflow.
  3. Click Run.
To schedule recurring workflow jobs:

To configure recurring data ingestion, create a Concert Workflows job to automatically initiate data ingestion and a resilience assessment at a defined interval. Refer to Creating jobs for instructions.

To trigger a workflow using automation rules:
You can create an automation rule to trigger a workflow based on a specific condition in your Concert instance. This requires you to establish a connection between Concert and your Concert Workflows instance. Refer to Automating Concert Workflows using automation rules.
Note: Before configuring an automation rule to trigger a workflow, you must expose the workflow in your Concert Workflows instance so it appears in your Concert instance.

Step 5: Review ingested application and resilience assessment details

After running the workflow, you can review the ingested application details and corresponding resilience metrics.

To view Java application details:
  1. In your Concert instance, go to Inventory > Application inventory from the main navigation.
  2. In the Applications tab, click the name of the ingested application to view details.
To view resilience assessment details:
  1. In your Concert instance, go to Dimensions > Resilience from the main navigation.
  2. In the Postures tab, scroll down and click the name of the posture assessment plan from the list to view details.
  3. In the Assessment summary tab, scroll down to view a list of Input metrics.

    The list contains all the resilience metrics collected related to this application, including those observed from the ingested images. Refer to the Source column in the table to verify the origin of each ingested metric.