• Home
  • Manage
  • Configuration as Code
  • Manage configurations
  • Special configuration types

Special configuration types

The following configuration types have non-standard behavior and constraints in order to deal with special Dynatrace APIs.

Single configuration endpoint

These configurations are global to a Dynatrace environment and only exist once. Unlike other configurations, there is usually some default configuration that the API—or Dynatrace Configuration as Code—allows you to update.

Be aware that only one such configuration should be present in your configuration. Having multiple configurations (for example, in several projects deployed in one run) will result in the last applied configuration being active on the Dynatrace environment.

Non-unique name

Dynatrace Configuration as Code assumes that the name of a configuration is unique, and it uses it as the identifier when deciding to create or update a configuration. This is also the case for most configurations when created in the Dynatrace UI or via API calls.

However, some configurations can have overlapping names, which causes issues for Configuration as Code. For example, there can be several dashboards named My Dashboard. If more than one configuration of a name is present, the Configuration as Code CLI can't ensure that the correct one is updated when searching by name. Similar problems are present when downloading.

To work around this, special handling is present for these configuration APIs to ensure the following:

  • They receive a known identifier when originating from Configuration as Code.
  • They are stored with their Dynatrace identifier rather than their name when downloading.

Because this switch from names to IDs results in recreating configurations if they were previously created by name, already existing configuration types, such as dashboard, are retained with the previous flawed handling, while new -v2 configuration types were added with the non-unique-name constraint/handling.

To ensure configurations are correctly updated, see the manual steps in Migrate deprecated configuration types for how to handle this.

Note: As the -v2 naming implies, the previous handling is deprecated and will be dropped in version 2.0.

Settings 2.0 Objects

The handling of Settings 2.0 objects differs from regular configurations. Unlike the latter, which are typically identified by name, Settings 2.0 objects may not have a unique name or any name at all. Instead, they are assigned an external identifier called externalId that enables them to be uniquely identified.

The externalId consists of the prefix "monaco:" followed by an identifier generated by Dynatrace Configuration as Code on deployment.

Moreover, to ensure the reliable updating of existing Settings 2.0 objects, Dynatrace Configuration as Code maintains a record of the original Dynatrace object ids when downloading and includes them in the YAML configuration field originObjectId. Note that updating existing Settings 2.0 objects on the same environment is only available in Dynatrace version 1.262 and later.