Manage a Dynatrace Monaco CLI project

A project is a folder containing specially named sub-folders representing APIs. The API folders contain another layer of folders defining configurations. The configuration folders contain YAML files specifying what gets deployed.

APIs

To list all supported APIs and folder names, see Configuration types and access permissions.

Configurations

A configuration consists of two parts:

  • YAML file defining parameters, dependencies, name, and template
  • JSON template file

Configuration YAML file

The configuration YAML file contains basic information about the configuration to deploy. This includes the name of the configuration, the location of the template file, and the parameters usable in the template file. Parameters can be overwritten based on what group or environment is currently deployed.

For details on configuration syntax, see Configuration.

JSON template file

The JSON template contains the payload that will be uploaded to the Dynatrace API endpoints. It allows you to reference all defined parameters of the configuration via {{ .PARAMETER_NAME }} syntax. For example:

template.json:

{
    "name": "{{ .name }}",
    "type": "{{ .type }}",
    "value": {{ .numericValue }}
}

config.yaml:

configs:
- id: sample
  config:
    name: "Sample"
    parameters:
      type: "simple"
      numericValue: 42
  [...]

As you can see, it's also possible to reference the name of a configuration.

The Dynatrace Monaco CLI uses Go templates, which, in theory, allow you to define more complex templates, but we highly recommend that you keep templates as simple as possible. Referencing variables via {{ .PARAMETER_NAME }} should be sufficient.

For more on advanced templating use cases, see Advanced use cases with Go templating.

Important additional information

The json files that can be uploaded with this tool are the JSON objects that the respective Dynatrace APIs accept/return. Adding a new configuration is generally done via the Dynatrace web UI unless you know the configuration JSON structures well enough to prefer writing them. Configurations can then be downloaded via the respective GET endpoint defined in the Dynatrace Configuration API, and should be cleaned up for auto-deployment.

A checked-in configuration should not include:

  • The entity's id but only its name. The entity can be created or updated if one of the same name exists. The name must be defined as a variable.
  • Hardcoded values for environment information such as references to other auto-deployed entities, tags, and management zones. These should all be referenced as variables
  • Empty/null values that are optional for the creation of an object. Most API GET endpoints return more data than is needed to create an object. Many of those fields are empty or null and can be omitted (for example, tileFilters on dashboards).

Special requirements for JSON templates

Some configuration types have special requirements for their JSON payloads and might need manual modification to be used with Configuration as Code.

For details, see Special configuration types.