Migrate from Cloud Automation to Site Reliability Guardian

Dynatrace Cloud Automation release validation evolves into the Site Reliability Guardian and becomes a native solution on top of the Dynatrace platform.

Comparison

The following table compares Cloud Automation (powered by Keptn) with the Site Reliablity Guardian:

Migrate to Site Reliability Guardian

Create a guardian

Transfer your SLO and SLI configurations into objectives

Create a workflow for the guardian

Integrate into your CI/CD pipeline

Create a guardian

In Cloud Automation, you need to create a project with stages to be able to add a service, that contains the configuration of the release validation. An example of configuration might include the following items:

• Project: shockshop
• Stage: quality-gate
• Service: payment
• Configuration for release validation stored in slo.yaml and sli.yaml files.

With Site Reliability Guardian you need to create a guardian that contains the configuration for a release validation. Use tags to filter and group guadians. For example, to represent the same configuration as described above, you can use a guardin with the payment name and stage:quality-gate and project:sockshop tags. Configuration for release validation is defined by objectives of the guadian.

1. Install the Site Reliability Guardian app.
2. Create a new guardian.

Transfer SLO and SLI configurations into objectives

In Cloud Automation, the release validation configuration is maintained in the slo.yaml and sli.yaml files. The slo.yaml file contains validation objectives, defined by pass and warning thresholds. The sli.yaml file contains a metric expression that extracts the required data from Dynatrace.

In Site Reliability Guardian, this configuration is stored as an objective of a guardian. An objective can fetch the data from Grail using DQL or references an exisiting SLO. It also contains pass and warning thresholds.

To transfer these configuration, translate your metric expressions into DQL queries or create an SLO. See the example of the translation below.

Metric expression

plaintextcopydownload
metricSelector=builtin:tech.jvm.threads.count:merge(\"dt.entity.process_group_instance\"):avg&entitySelector=type(process_group_instance)

DQL query

plaintextcopydownload
timeseries count = avg(dt.process.jvm.threads.count), filter: in(dt.entity.process_group_instance, "PROCESS_GROUP_INSTANCE_UUID")
| fields avg = arrayAvg(count)

Create a workflow for the guardian

Once you have a guardian with configured objectives, create a workflow to automate the release validation.

To create a workflow, use the Create workflow option of the context menu.

Integrate into CI/CD pipeline

Once you have a workflow, you can integrate the guardian into a CI/CD pipeline to validate releases on each pipeline run. For integration to work, the pipeline need to send an event to Dynatrace, triggering the workflow. This is the same procedure as in Cloud Automation.

1. Create an OAuth 2.0 client.

   1. Open the User menu in the bottom left and go to Identity & access management > OAuth clients.
   2. Select Create client.
   3. Enter the email address of the user who owns the client.
   4. Enter a description of the new client.
   5. Select the following scopes:
      • Create and edit events (storage:events:write)
      • View bizevents (storage:bizevents:read)
   6. Select Create client.
   7. Copy the generated client ID to the clipboard. Store them in a password manager for future use.

      You can only access your client secret once upon creation. You can't reveal it afterward.

2. Change the CI/CD pipeline to send an event to Dynatrace instead of Cloud Automation.

   Show sample Jenkins file

   In this example, Jenkins retrieves an access token from the OAuth client and sends a BizEvent to Dynatrace.

   plaintextcopydownload
   script {
       final String tkn = sh(script: """
           set +x
           curl --location --request POST 'https://sso-sprint.dynatracelabs.com/sso/oauth2/token' \\
               --header 'Content-Type: application/x-www-form-urlencoded' \\
               --data-urlencode 'grant_type=client_credentials' \\
               --data-urlencode 'client_id=<YOUR_OAUTH_CLIENT_ID>' \\
               --data-urlencode 'client_secret=<YOUR_OAUTH_CLIENT_SECRET>' \\
               --data-urlencode 'scope=storage:events:write'
           set -x
       """, returnStdout: true).trim()
   
       final String access_tkn = readJSON(text: tkn).access_token
   
       sh(script: """
           set +x
           curl --location --request POST 'https://<YOUR_ENVIRONMENT>/platform/classic/environment-api/v2/bizevents/ingest' \\
               --header 'Content-Type: application/json' \\
               --header 'Authorization: Bearer ${access_tkn}' \\
               --data-raw '{
                   "timeframe.to": "now-2",
                   "timeframe.from": "now-12m",
                   "execution_context": {
                       "buildId": "${currentBuild.number}",
                       "version": "${params.DockerImageTag}"
                   },
                   "tags.service": "<SERVICE_NAME>",
                   "tags.stage": "<STAGE_NAME>",
                   "event.provider": "Jenkins",
                   "event.type": "guardian.validation.triggered"
                 }'
           set -x
       """)
   }