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

Preview Release 2.6.0-rc.1

⚠️ Preview Release ⚠️

This is a pre-release of monaco 2.6.0

• This does not yet reflect the full content or quality of the final release.
• No official support is provided for the pre-release version.
• If you try this release we'd love to hear your feedback in the release discussion!

What's Changed

🚀 Features

Improved deployment

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.
(Your mileage may vary - we'd love to hear your results in the release discussion!)

Graph-based deployment

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

This allows for several improvements and features.

Graph-based sorting

Build a dependency tree and use it for sorting, 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.

Sorting into independent connected components

Use the dependency tree to sort configurations into independent connected components (configurations that depend on each other are grouped into a component).

This allows for smarter behavior in case a referenced dependency failed to deploy or was 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.

To enable this feature, set the environment variable feature-flag MONACO_FEAT_GRAPH_DEPLOY=true.

Parallel deployments

Using the new internal representation, configurations that are not dependent on each other can be deployed in parallel.
To enable this feature, set the following environment variable feature-flags:

• MONACO_FEAT_GRAPH_DEPLOY=true.
• MONACO_FEAT_GRAPH_DEPLOY_PARALLEL=true

⚠️ Known Issue Logging happens out of order and some logs might be hard to correlate to the correct configuration.
We recommend turning on structured JSON logging, which will include extra fields like the coordinate for each log line.
The full release will include information on the coordinate, as well as component for each log line, regardless of format.

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.

Generate delete-files for your Monaco configurations

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

⚠️ Known Issue Help text of this command is partially incorrect, e.g. it mentions a -f flag, which should be --file.
Generated delete files include some unnecessary empty string values, this is not a functional problem but looks strange.
These issues will be resolved in the final release.

---

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-rc.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.6.0-rc.1

---

Full Changelog: v2.5.0...v2.6.0-rc.1

2.5.0

What's Changed

🚀 Features

Logs can now be saved as a .zip archive. When flag --support-archive is specified, monaco will produce a .zip archive containing the following files: request logs, response logs, and regular logs.

🐛 Fixes

• ensure errors are not lost/overwritten, and HTTP requests can be made concurrently.

🔧 Improvements

• cache settings objects during upsert operations

---

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.5.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.5.0

---

📚 Usage as Go library

• package pkg/client/automation/client.go is extended with func (a Client) Get(ctx context.Context, resourceType ResourceType, id string) (*Response, error) method to get a single automation resource by ID

Full Changelog: v2.4.0...v2.5.0

2.4.0

What's Changed

🚀 Features

Monaco now supports structured logging in JSON format.

If activated via environment variable MONACO_LOG_FORMAT=json logs are written in JSON format with added metadata, including:

• The coordinate of the configuration the log relates to.
• The environment the (deployment) log relates to.
• If the log is an error, details about the error including its type and details (which differ per type).

Note: unlike regular logs, JSON logs can be piped to other commands, as they are written to stdout rather than the Go default stderr.

Sample log line:

{
  "level": "info",
  "ts": "2023-07-03T11:46:53+02:00",
  "msg": "Deploying config project_platform:auto-tag:b001a59e-c017-44fa-9db1-e3fe91e51f48",
  "coordinate": {
    "reference": "project_platform:auto-tag:b001a59e-c017-44fa-9db1-e3fe91e51f48",
    "project": "project_platform",
    "type": "workflow",
    "configID": "b001a59e-c017-44fa-9db1-e3fe91e51f48"
  },
  "environment": {
    "group": "default",
    "name": "project_platform"
  }
}

🐛 Fixes

• Deactivating download filtering now includes Config APIs that are filtered out completely. Previous versions always filtered out these configurations, regardless of the filter environment variables MONACO_FEAT_DOWNLOAD_FILTER or MONACO_FEAT_DOWNLOAD_FILTER_CLASSIC_CONFIGS.

🔧 Improvements

• Clarified logging for which Config APIs are being downloaded or, if deprecated, not being downloaded in favor of Settings 2.0.
• Clarified logging if no configurations were downloaded.

Full Changelog: v2.3.0...v2.4.0

---

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.4.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.4.0

---

📚 Usage as Go library

What's Changed

• Packages can be imported into other Go projects as github.com/dynatrace/dynatrace-configuration-as-code/v2 starting with version 2.4.0. Previous 2.x versions could not be imported correctly.
• When instantiating a client, a custom User-Agent string can be set to be sent with HTTP requests.

Samples

Using a Settings 2.0 client with custom User-Agent for a Dyntrace Platform environment:

package main

import (
	"context"
	"encoding/json"
	"github.com/dynatrace/dynatrace-configuration-as-code/v2/pkg/client/auth"
	"github.com/dynatrace/dynatrace-configuration-as-code/v2/pkg/client/dtclient"
	"log"
)

func main() {
	// SETUP CLIENT
	url, _ := os.LookupEnv("URL")
	apiToken, _ := os.LookupEnv("API_ACCESS_TOKEN")
	oAuthClientID, _ := os.LookupEnv("CLIENT_ID")
	oAuthClientSecret, _ := os.LookupEnv("CLIENT_SECRET")
	oauthCredentials := auth.OauthCredentials{
		ClientID:     oAuthClientID,
		ClientSecret: oAuthClientSecret,
	}

	c, err := dtclient.NewPlatformClient(url, apiToken, oauthCredentials,
		dtclient.WithAutoServerVersion(), dtclient.WithCustomUserAgentString("test-monaco-v2-import"))
	if err != nil {
		log.Fatalf("failed to initialize Dynatrace API client: %v", err)
	}

	// QUERY SETTINGS OBJECTS OF GIVEN SCHEMA
	schemaID := "builtin:alerting.profile"
	res, err := c.ListSettings(context.TODO(), schemaID, dtclient.ListSettingsOptions{})
	if err != nil {
		log.Fatalf("failed to query %s settings: %v", schemaID, err)
	}

	// WORK WITH QUERIED DATA
	log.Printf("Got %d %s Settings", len(res), schemaID)
	for _, r := range res {
		var data map[string]interface{}
		err := json.Unmarshal(r.Value, &data)
		if err != nil {
			log.Fatalf("failed to unmarshal Setting with ID %q: %v", r.ObjectId, err)
		}
		log.Printf("got Setting with ID %q: %s\n", r.ObjectId, data["name"])
	}
}