2.10.0

What's Changed

🚀 New Features

Network zones support

Monaco now supports Dynatrace network zones.
You can configure them using api: network-zone in your configs.
For example:

configs:
- id: my-monaco-network-zone
  config:
    name: My zone
    template: zone.json
  type:
    api: network-zone

Generate json/yaml schemas

Monaco now allows to generate json/yaml schemas for the current version that you have.
By invoking monaco generate schemas (see available options using the -h flag), Monaco generates the json/schema definition you can use in your IDE.
You can find more information in our documentation.

🐛 Fixes

• We're no longer failing when three curly braces are used in the template files

🔧 Improvements

• Added deprecation notices for deprecated settings schemas.
  The settings schemas builtin:span-attribute, builtin:span-event-attribute, and builtin:resource-attribute are now deprecated.
• Improved logging during download

Other improvements

• chore(deps): bump github.com/dynatrace/dynatrace-configuration-as-code-core from 0.4.1-0.20231114144451-a2144bd75dcc to 0.5.0
• chore(deps): bump github.com/google/uuid from 1.4.0 to 1.5.0
• chore(deps): bump actions/upload-artifact from 3.1.3 to 4.0.0
• chore(deps): bump go.uber.org/mock from 0.3.0 to 0.4.0
• chore(deps): bump github.com/go-logr/logr from 1.3.0 to 1.4.1
• chore(deps): bump EnricoMi/publish-unit-test-result-action from 2.11.0 to 2.12.0
• chore(deps): bump reviewdog/action-golangci-lint from 2.5.0 to 2.5.1
• chore(deps): bump actions/upload-artifact from 4.0.0 to 4.1.0
• chore(deps): bump golang from 1.21.5-alpine to 1.21.6-alpine
• chore(deps): bump golang.org/x/oauth2 from 0.15.0 to 0.16.0
• chore(deps): bump github.com/invopop/jsonschema from 0.7.0 to 0.12.0

Full Changelog: v2.9.3...v2.10.0

Get Monaco

Installation instructions for Windows, Linux, and MacOs as well as Docker are available in our documentation.

2.9.3

What's Changed

🐛 Fixes

• Fixed error when deploying some pre-configured Settings objects, wrongly reporting … ExternalID … already exists errors.
• We're no longer skipping the download of Settings objects that are partially modifiable.
• We're now correctly supporting compound parameters for a config's name.
• Extraction of IDs when downloading is improved - no longer wrongly extracting partial IDs.
• Buckets are no longer downloaded if download is limited to other types via flags.

🔧 Improvements

• Native Monaco Docker image for linux/arm64 is now available.
• Increased timeout for Grail bucket operations to 5 minutes.
• Reduced docker permissions.

Other improvements

• Update to Go 1.21
• bump golang from 1.21.4-alpine to 1.21.5-alpine
• bump actions/setup-go from 4.1.0 to 5.0.0
• bump golang.org/x/oauth2 from 0.13.0 to 0.14.0
• bump github.com/spf13/afero from 1.10.0 to 1.11.0
• bump golang.org/x/oauth2 from 0.14.0 to 0.15.0
• Docker: bump alpine from 3.18 to 3.19

Full Changelog: v2.9.2...v2.9.3

Get Monaco

Installation instructions for Windows, Linux, and MacOs as well as Docker are available in our documentation.

2.9.2

What's Changed

🐛 Fixes

Fix failing to deploy multiple non-unique name configs having the same name.

Previous versions of Monaco would fail to deploy multiple non-unique name configurations with the same name.

If such overlapping configurations were defined, the end result would be a single configuration on the environment.
This was due to a feature ensuring non-unique name configs are updated instead of duplicated if only a single one is found in the environment.

The fix retains that handling which increases usability in cases that users keep names unique, but deactivates it, if a deployment defines several configurations with the same name.

Fix sometimes failing Grail Bucket updates

Previous versions relied on retries to handle state changes of Grail Buckets, however it was found that in some cases, especially if create and update actions happen in quick success this does not resolve all errors and can lead to failed deployments.

The Grail Bucket API client is reworked to await the desired bucket state for each operation. This makes deployments and deletions slightly slower, but ensures that Buckets are always ready to use/modify or fully removed before monaco continues to deploy/delete possibly dependent configurations.

🔧 Improvements

Notify when new versions are available

From this version on, the monaco CLI performs a background version check and will print a message at the end of each command execution if a new version is available for download.

This is implemented by connecting to GitHub. If no connection can be established, the check will silently fail in the background, without impacting the command you're executing.

This behavior is turned ON by default and can be disabled by setting MONACO_SKIP_VERSION_CHECK if needed.

Other improvements

• Bump dependency github.com/go-logr/zapr from 1.2.4 to 1.3.0
• Bump dependency github.com/spf13/cobra from 1.7.0 to 1.8.0

---

Container image

Images are available on DockerHub.
The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.9.2

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.9.2

---

Full Changelog: v2.9.1...v2.9.2

2.9.1

What's Changed

🐛 Fixes

Allow deactivating updates of single non-unique-name configs by name

This feature can break the deployment of projects containing several configurations with the same name

You may be affected by this if you're configuration projects contain e.g. several dashboards of the same name, but you only find a single one in the environment after running `monaco deploy.

To deactivate the update logic, set the following environment variable:

MONACO_FEAT_UPDATE_SINGLE_NON_UNIQUE_BY_NAME=false

Deactivating this feature is recommended when using monaco to migrate configurations from one environment to an empty new environment.

This is a temporary workaround! We're working on a fix addressing both edge-cases of having a single configuration you want to update and many configurations that should be created individually.

Other fixes

• Consider environment overrides when generating delete files.
• Do not download Grail buckets that are currently being deleted.
• Remove unnecessary curl and jq dependencies from the Docker container.

🔧 Improvements

Defer loading of JSON templates to the point they are needed

This change, combined with previously released changes, vastly improves Monaco's runtime memory consumption.

For details, refer to the documentation: Monaco hardware requirements

Other improvements

• Allow generating delete files for a specific environment
• Improve some log messages

---

Container image

⚠️ As of this version the container image only includes the monaco CLI! ⚠️
The previously contained curl and jq utilities are removed to ensure the image does not contain unnecessary, potentially vulnerable components.
If you require a container with utility programs, please build your own based on this container image.

Images are available on DockerHub.
The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.9.1

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.9.1

---

Full Changelog: v2.9.0...v2.9.1

2.9.0

What's Changed

🚀 Features

Support for custom Grail buckets

Custom Grail buckets can now also be managed as configuration as code.
The best way to get started is to download configurations from a Platform environment where you have configured a custom Grail bucket.
You can find the documentation here.

You can also look at this sample project.

---

Container image

Images are available on DockerHub.
The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.9.0

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.9.0

---

Full Changelog: v2.8.3...v2.9.0

2.8.3

🔧Improvements

• Added deploymentStatus field to structured logs #1201
• In addition to the existing log file, we're now writing log files only containing errors. This error file will be stored as .logs/[timestamp]-errors.log #1183
• When printing what configs are skipped, the structured logging now includes the child-field.

🐛Fixes

• Vulnerability: Mitigated the possibility of having credentials logged during the execution of a specific Monaco command.
• We're now matching Settings 2.0 key properties correctly. #1178
• We improved our memory footprint by not printing all errors at the end of the Monaco-execution. Errors are printed whenever they happen, and only a summary is printed how many errors happened for each environment at the end. #1185
• We're not reporting correctly whenever the property inside a reference is missing #1194
• We've also fixed several occurrences of unstructured logs inside the structured logging-mode. #1193

---

Container image

Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code

The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.8.3

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.8.3

---

Full Changelog:

2.8.0

🚀 Performance improvements

We've implemented several improvements for the Monaco deployment - all focused on making deployments faster and more resilient.

Early internal tests have achieved an up to 45% reduction in deployment time if all features are activated.

Independently deployed components

We're now sorting the to-be-deployed configurations into independent components. This allows for smarter deployment behaviors, for example, if a referenced dependency fails to deploy or is skipped.

Consider the following example:

A project consisting of

• a synthetic-location,
• referenced by a synthetic-monitor,
• referenced by an slo.

For a given environment, the synthetic-location is being skipped.

Previously, Monaco would produce an error when trying to deploy the synthetic monitor (or continue to also fail on the slo if you're using the --continue-on-error flag).

With this feature, Monaco recognizes that neither the synthetic monitor nor the slo can be deployed, prints a warning, and continues without error.

If you're encountering issues with this new method of deployment, you can set the following feature flag to disable the behavior: MONACO_FEAT_GRAPH_DEPLOY=false. This not only disables the independent deployment but also the parallel deployment described next.

Parallel deployments

Using the new internal representation, configurations that are not dependent on each other can be deployed in parallel.
If you're encountering issues with this new method of deployment, you can set the following feature flag to disable the behavior: MONACO_FEAT_GRAPH_DEPLOY_PARALLEL=false

🔧 Improvements

• monaco generate deletefile now ignores configs where no config name is set.
• Monaco now uses a default memory limit of 2 GiB, which can lower the memory limit significantly for larger projects. You can overwrite this default using the Go environment variable GOMEMLIMIT.

🐛 Fixes

• Conversion: Manually escaped characters are now handled correctly #1153

---

Container image

Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code

The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.8.0

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.8.0

---

Full Changelog: v2.7.1...v2.8.0

2.7.1

What's Changed

🐛 Fixes

• Always create support archives when requested with the --support-archive flag.
  Previous versions failed to create support archives if an execution error occurred.
• Settings 2.0 deletion errors are fully logged.
  Previous versions omitted the actual error that caused a deletion to fail, making troubleshooting difficult.

🔧 Improvements

• HTTP connection interrupted errors are presented with a user-friendly message.
• Deletion log messages are presented in a more uniform way.
• The wording of several warning messages is clarified.
• The help text of the --dry-run flag is clarified.

---

Container image

Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code

The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.7.1

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.7.1

---

Full Changelog: v2.7.0...v2.7.1

2.7.0

What's Changed

🚀 Features

• The name parameter is no longer required for types identified by generated IDs.
  This means that only config API types which are identified by name require a name to be defined in the YAML configuration.
  See the documentation for details.

🐛 Fixes

• Conversion no longer fails if the same environment variable is used in a v1 YAML and JSON.
• Correctly log the reason for retrying HTTP Get requests, instead of wrongly logging "HTTP 0" statuscode.
• Always include debug/verbose logs in log files created with --support-archive.

🔧 Improvements

• Several improvements to log messages.
• Bump dependency golang.org/x/net from 0.12.0 to 0.13.0
• Bump dependency go.uber.org/zap from 1.24.0 to 1.25.0
• Bump dependency golang.org/x/oauth2 from 0.10.0 to 0.11.0
• Bump dependency golang.org/x/net from 0.13.0 to 0.14.0
• Bump dependency gonum.org/v1/gonum from 0.13.0 to 0.14.0
• Bump dependency github.com/google/uuid from 1.3.0 to 1.3.1

---

Container image

Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code

The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.7.0

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.7.0

---

Full Changelog: v2.6.0...v2.7.0

Release 2.6.0

What's Changed

🚀 Features

Support for Workflows/Automations

The Dynatrace Platform introduced Dynatrace Automations and Workflows.

Workflows, business-calendars and scheduling-rules can now also be managed as configuration as code.

The best way to get started is to download configurations from a Platform environment where you have configured a workflow.

You can also take a look at this sample project.

For more on configuration as code for automation see the documentation.

Improved deployment

We've implemented several improvements for the Monaco deployment - all focused on making deployments faster and more resilient.

Graph-based sorting

We improved the internal representation of configurations and dependencies to a graph data structure.

This is used when sorting configurations for deployment, which is notably faster and more memory efficient that the previous sorting.

This feature is active by default but can be disabled via the environment variable feature flag MONACO_FEAT_GRAPH_SORT=false.

Further improvements to deployment using the new graph representation will be part of upcoming releases.

Updating Settings with unique key properties

Some Settings 2.0 schemas define unique key constraints, which ensure that Settings objects are unique.

Monaco is now aware of these constraints and can identify and update existing objects based on their unique keys, instead of just by externalID or originObjectID.

Previously if an object with an overlapping unique key already existed, monaco would attempt to create a duplicate, resulting in an API error.

This new behavior is conceptually similar to classic Config API objects being identified based on their name.

Improved caching

Monaco made several repetitive queries during deployments to identify and update existing configurations.
These are heavily reduced by introducing caching.

Generate a dependency graph for your Monaco configurations

The command monaco generate graph <manifest.yaml> can create dependency graphs of your configurations. They're exported using the DOT format.
You can use a tool of your choice to visualize the graph as an image - for example graphviz online.

For more on this command see the documentation.

Generate delete-files for your Monaco configurations

The command monaco generate deletefile <manifest.yaml> can create delete files for your Monaco projects.

For more on this command see the documentation.

---

Container image

Images are available at https://hub.docker.com/r/dynatrace/dynatrace-configuration-as-code

The image can be used directly, passing command arguments to the CLI directly or in CI with a monaco executable available in the container.

docker pull dynatrace/dynatrace-configuration-as-code:2.6.0

Verifying Signature

The Image is signed, and its signature can be verified using cosign and the cosign.pub key that can be downloaded from this release.

 cosign verify --key cosign.pub dynatrace/dynatrace-configuration-as-code:2.6.0

---

Full Changelog: v2.5.0...v2.6.0