Upgrade 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 Reliability Guardian:

	Release Validation	Site Reliability Guardian
Platform	Cloud Automation instance	Dynatrace AppEngine
Dynatrace integration	API-based	Native
Structural concept	Project, Stage, Service	Guardian
SLO support	Conceptual difference between Keptn and Dynatrace SLO	Dynatrace SLOs built-in
Configuration as code	Keptn specification for slo.yaml and sli.yaml	Settings 2.0 objects
Automation as code	Keptn specification for shipyard.yaml	Automation config
Configuration store	Git repository	Dynatrace configuration

Upgrade 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.

Install the Site Reliability Guardian app.
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

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

DQL query

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.

Disclaimer

The following steps use business events to integrate into a CI/CD pipeline. This approach is valid for now, but we plan a new event kind for events occurring during the software development lifecycle of a software component. This new event kind will replace business events in the future.

Create an OAuth 2.0 client.
1. Go to Account Management. If you have more than one account, select the account you want to manage.
2. Go to Identity & access management > OAuth clients.
3. Select Create client.
4. Enter the email address of the user who owns the client.
5. Enter a description of the new client.
6. Select the following scopes:
  - Create and edit events (storage:events:write)
  - View bizevents (storage:bizevents:read)
7. Select Create client.
8. 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.

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

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

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
    """)
}