Importing resilience data from Datadog

Edit online

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

Draft comment: erin.pelkey@ibm.com
MISSING INFO - Please provide a list and descriptions of resilience metrics ingested from Datadog. For example, we should be able to say, "Once configured, you can ingest the following resilience metrics from Datadog:"

Before you begin

You must upload the SBOM files related to the application being monitored by Datadog into your Concert instance. Alternatively, you can configure ingestion jobs to import various components and define the application from those components.
You must create a resilience profile and a resilience posture assessment plan for the application being monitored by Datadog.
Draft comment: erin.pelkey@ibm.com
How is this resilience posture assessment plan mapped to the data ingested from Datadog?
If your Concert instance is external (not in the same hub as Concert Workflows), you must generate a Concert API key. Refer to Generating an API key for instructions.
Note: Authenticating a connection for use with Concert Workflows is different than doing so for general Concert operations. In this case, refer to Authenticating from Concert Workflows to Concert.
- For Datadog, you must provide the API key from your Datadog account.
- For Concert, you must provide the API key generated in 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 Datadog 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 Datadog workflow requires following authentications to establish a valid connection with the external systems referenced in the workflow:

Create an authentication for the Datadog service using the API key and Application key from your Datadog account.
Create an authentication for the Config data service to which 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": "12443",
  "concert_instance_id": "0000-0000-0000-0000"
}
```

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 Datadog 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:
- origin - Set this value to APM to indicate that the collected data corresponds to application performance monitoring (APM) metrics.
- origin_name - Set this value to Datadog as it is the source of the ingested metrics.
- origin_url - Enter the URL of your Datadog account. This is typically in the following format: https://<region>.datadoghq.com. For example, if your account is based in the us5 region the origin URL will be https://us5.datadoghq.com
- 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?
- application_name - Name of the application as it appears in Concert or Datadog.
  Draft comment: erin.pelkey@ibm.com
  Don't these need to match?
- profile_name - Name of the resilience profile used in the corresponding posture assessment plan for this application.
- 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.
- service_name - The service for which you want to collect metrics.
  Draft comment: erin.pelkey@ibm.com
  What does this mean? Which service? Is this value found in Datadog or Concert? Please advise.
- env_name - Name of the environment in which the service is running, such as prod or test.
  Draft comment: erin.pelkey@ibm.com
  Does this need to match something specific in Concert? Datadog? Please advise.
- syn_test_id - Unique ID of the synthetic test for which you want to collect metrics. The test ID is generated once the synthetic test is created and is usually a string separated by a hyphen (-), such as tcw-hji-piy.
  Draft comment: erin.pelkey@ibm.com
  Is this synthetic test generated in Datadog? Please advise.
- concertConfigAuth - Unique name of the Config data service authentication created in the previous step.
- datadog_auth - Unique name of the Datadog authentication created in the previous step.
Click Save.

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

To run the workflow manually:

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

After running the workflow, you can see the assessment ID generated in the response logs.

The screenshot of Concert Workflows window after running the workflow, showing the assessment ID generated in the results.

Draft comment: erin.pelkey@ibm.com
What is the relevance of this assessment ID? Why do they need this if they already created the resilience posture assessment plan for the given application? Wouldn't they just look there?

To schedule recurring workflow jobs:

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

Draft comment: erin.pelkey@ibm.com
Does running the workflow automatically initiate the resilience posture assessment, or does the user need to perform an additional step to run the posture assessment?

Step 5: Review resilience assessment details

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

In Concert, 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 Datadog. Refer to the Source column in the table to verify the origin of each ingested metric.