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