Importing resilience data from Instana

Edit online

Using Concert Workflows, you can import a prebuilt workflow from the library designed to facilitate resilience data collection in Instana and sending it to your Concert instance to assess against the defined requirements for a given application.

Once configured, you can ingest the following resilience metrics from Instana:

days_rca_sla_sev1
This metric represents the requirement for the application to complete an incident retrospective (RCA) for severity disruptions (for example, within 7 days).
days_rca_sla_sev2
This metric represents the requirement for the application to complete an incident retrospective (RCA) for severity disruptions (for example, within 14 days).
mins_mttr
This metric represents the goal in minutes for the application to recover from incidents (mean time to recover).
mins_mttr_sev1
This metric represents the goal in minutes for the application to recover from severity incidents.
mins_mttr_sev1_by_change
This metric represents the goal for severity incidents specifically caused by changes.
mins_mttr_sev2
This metric represents the goal in minutes for the application to recover from severity incidents.
mins_mttr_sev2_by_change
This metric represents the goal for severity incidents specifically caused by changes.
num_throughput_transactions
This metric represents the number of incoming requests to the application in one day. It is calculated by comparing multiple daily request counts and using the highest value.
pct_availability_by_error_rate
This metric represents the aggregated application available based on the number of HTTP errors observed in one day. If there are none, the number of "available days" is increased by one.
pct_sev1_incidents_by_change
This metric represents the canary release goal for the application, calculated as the percentage of severity incidents caused by changes.
pct_sev1_incidents_detected_by_monitoring
This metric represents the percentage of severity incidents detected by monitoring tools. This goal drives the implementation of observability to detect disruptions proactively.
pct_sev2_incidents_by_change
This metric represents the canary release goal for the application, calculated as the percentage of severity incidents caused by changes.
pct_sev2_incidents_detected_by_monitoring
This metric represents the percentage of severity incidents detected by monitoring tools. This goal drives the implementation of observability to detect disruptions proactively.
pct_slo_latency_errorbudget
This metric represents the aggregated application latency measurement for a single day. This value is compared to the latency_slo threshold to determine if the daily value meets the defined objective.
pct_slo_error_rate_errorbudget
This metric represents the average rate of error responses for a given application.

Before you begin

You must establish a connection between your Concert and Instana instances, and then create an ingestion job to ingest Instana application data. Refer to Integrating with IBM Instana Observability for instructions.
You must create a resilience profile and a resilience posture assessment plan for the application being monitored by Instana.
Draft comment: erin.pelkey@ibm.com
How is this resilience posture assessment plan mapped to the data ingested from Instana?
Ensure that resilience settings are enabled in both the main and application settings of your Concert instance.
Create a folder called Resilience in your list of Concert Workflows to organize workflows based on the use case.

Step 1: Download and import the prebuilt workflow

In Concert Workflows, in the Workflows page, click Create workflow > Select from library. choose the Instana workflow, and import it. For more information about importing Concert-specific workflows into Concert Workflows, see creating workflows.

Step 2: Create the required authentications

The Instana workflow requires the following authentications to establish a valid connection with the external systems referenced in the workflow. The authentication steps vary depending on the workflow version (v1, v2, or v2.2).

Create an authentication for the IBM Hub - Self (Recommended) or IBM Concert API Key service to establish a connection with your Concert instance.
- For v1 workflow:
  - Go to Workflows > Authentications.
  - Select Service type: API Key.
  - Set the following property:
    - Set Header Name: Authorization.
    - Set API Key Value: C_API_KEY <your_c_api_key>
  - Click Create.
  - Now, create an authentication for the Config data service that is used by the common/HTTP workflow blocks to make Concert API calls. This authentication requires you to provide the hostname, port, and unique ID of your Concert instance. Insert a code snippet containing this information in the Data property field. For example:
```
{
  "concert_host": “example.concert-host.ibm.com",
  "concert_port": "", For SaaS instances using version1.0 configuration, this value is resolved by the system and does not need to be specified.
  "concert_instance_id": "0000-0000-0000-0000"
}
```
- For v2 workflow:
  - Go to Workflows > Authentications.
  - Select Service type: IBM Concert API KEY/IBM Hub - Self.
  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. The IBM Hub - Self service requires no additional credentials.
- For v2.2 workflow: The system defaults to Concert Authentication (IBM Hub - Self or IBM Concert API Key).
- Create an authentication for the Instana service. When doing so, you must provide the instana_instance_domain and a valid api_key from your Instana account.

You can create the authentications from the Authentications page or from within the workflow editor by opening a workflow and clicking the Auth button. Refer to Using authentications for instructions.

Note: Each authentication requires you to enter a unique name. Record the name of both authentications configured as you will need to enter them in the workflow editor in the next step.

Step 3: Edit the imported workflow

After importing the workflow, you must provide the parameter values and authentications required to execute it.

Click the overflow menu (in the Actions column) next to the Instana workflow you just imported, and select Open to open the workflow editor.
The User variables section displays the parameters referenced throughout the workflow.
Enter the following parameter values listed in the User variables section of the workflow editor:
- application_name - Name of the application as it appears in Concert or Instana.
  Draft comment: erin.pelkey@ibm.com
  Don't these need to match?
- applicationVersion - The version of the application as indicated in the corresponding SBOM uploaded to your Concert instance.
  Draft comment: erin.pelkey@ibm.com
  Is it the application SBOM, build SBOM, and/or deploy SBOM associated with the application?
- concertAPIKey - The path where the Concert API key input variable is provided and used for v2.1 or earlier versions.
- IBMAPIKey : The path where the IBM - Hub Self service API key input variable is provided and used for v2.2 or later versions.
- concertConfigAuth (optional) - Unique name of the Concert authentication (IBM Hub - Self or Concert API Key). Refer to Authenticating from Concert Workflows to Concert.
- defaultWindowSize - Indicates the amount of time for which metrics should be fetched.
  Draft comment: erin.pelkey@ibm.com
  What is the unit of measurement? Seconds? Miliseconds? Also, please clarify if this is the amount of time covered in the assessment, the time between assessments, or something else.
- instanaAuth - Unique name of the Instana authentication configured in the previous step.
- originUrl - The URL of your Instana instance.
- profile_name - Name of the resilience profile used in the corresponding resilience posture assessment plan for this application.
- webApplicationName - The name of the web application as monitored in Instana.
Note: Synthetic test setup is not mandatory for workflow execution.
Click Save.

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

To run the workflow from Concert Workflows:

Navigate to the Workflows page.
Click the overflow menu (in the Actions column) next to the Instana workflow you just imported.
Click Run.

To schedule recurring workflow jobs:

To configure recurring data ingestion, create a Concert Workflows job to automatically initiate resilience data ingestion from Instana 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 resilience assessment details

After running the workflow, you can review the data ingested from Instana in the resilience posture assessment details for the corresponding application.

In your Concert instance, go to Dimensions > Resilience.
In the Postures tab, scroll down and click the name of the posture assessment plan from the list to view details.
In the Assessment summary tab, scroll down to view a list of metrics.
The list contains all the metrics collected related to this posture assessment, including those ingested from Instana. Refer to the Source column in the table to verify the origin of each ingested metric.