Migrate application detection rules

This guide shows how to migrate application detection rules.

Issue

While Dynatrace Configuration as Code uses the name of a configuration to identify it, an internal migration results in all existing application detection rules being renamed. This results in the first configuration deployment creating a new, duplicate configuration. To see if you have this issue, look at the application detection rules in the Dynatrace web UI or call the Dynatrace API directly.

For example, assume we have a single application detection rule defined via Dynatrace Configuration as Code as:

yamlcopydownload
config:
    - detection_rule: "det.json"

detection_rule:
    - name: "TEST RULE"
    - application_id: "some-project/application-web/my-app.id"

JSON Template:

jsoncopydownload
{
    "name": "{{ .name }}",
    "applicationIdentifier": "{{ .application_id }}",
    "filterConfig": {
        "applicationMatchTarget": "DOMAIN",
        "applicationMatchType": "MATCHES",
        "pattern": "google.com"
    }
}

In the Dynatrace web UI, go to Settings > Web and mobile monitoring > Application detection. Where you would expect a single rule, you will see a duplicate after a configuration deployment as in the following example.

A GET request to the API will result in something like this:

shcopydownload
curl -X GET "{YOUR ENVIRONMENT_URL}/api/config/v1/applicationDetectionRules" -H  "accept: application/json; charset=utf-8" -H  "Authorization: Api-Token {YOUR API TOKEN}"
[...]
{
  "values": [
    {
      "id": "e3348565-01b0-35a3-aae0-8957d5f6c1f2",
      "name": "TEST RULE"
    },
    {
      "id": "a8835418-c7b3-304d-a9f5-6cc08e8935f0",
      "name": "a8835418-c7b3-304d-a9f5-6cc08e8935f0"
    }
  ]
}

As you can see, one of these rules has the expected "TEST RULE" name, while the other has a name matching its ID. Subsequent configuration deployments will update the correctly named rule but leave a duplicate of the original rule.

Solutions

There are two ways to resolve the duplicated rules. Your choice depends on whether it is acceptable to have a timeframe without application detection rules in place.

Easy but with possible impact on observability

If you can accept a short timeframe in which there are no application detection rules in place.

1. Delete all duplicate rules from the Application detection Settings page (or via API).
2. Run monaco deploy to re-create the rules.

Safe but requires manual validation and use of the API

If it is unacceptable to have any timeframe without application detection rules in place.

1. Run monaco deploy
   • This will result in duplicate rules as described above, or it might already be the case.
   • After duplicate rules exist, you can delete the migrated rule (where id and name are the same) while the correctly named rule stays in place and active.
2. Query the API to get all rules:

   shcopydownload
   curl -X GET "{YOUR ENVIRONMENT_URL}/api/config/v1/applicationDetectionRules" -H  "accept: application/json; charset=utf-8" -H  "Authorization: Api-Token {YOUR API TOKEN}"

3. If not all of your rules are defined via Configuration as Code, check the content of each configuration to identify the duplicates:

   shcopydownload
   curl -X GET "{YOUR ENVIRONMENT_URL}/api/config/v1/applicationDetectionRules/{A RULE ID}" -H  "accept: application/json; charset=utf-8" -H  "Authorization: Api-Token {YOUR API TOKEN}"

   • If the content matches one of your rules defined using Monaco, you can delete it as described below or else leave it as is.
   • If all of your rules are defined using Monaco, you can delete all migrated rules (where id and name are the same).
4. Delete the migrated duplicates using the API:

   shcopydownload
   curl -X DELETE "{YOUR ENVIRONMENT_URL}/api/config/v1/applicationDetectionRules/{A RULE ID}" -H  "accept: application/json; charset=utf-8" -H  "Authorization: Api-Token {YOUR API TOKEN}"