MyObservability

Dynatrace Observability as Code

This folder is a reference implementation for onboarding applications into Dynatrace using Git, Azure DevOps, Ansible, and Dynatrace Monaco.

The Payment application is the reference workload: a Java service running on AWS EC2, monitored by Dynatrace OneAgent, using an AWS Environment ActiveGate to reach Dynatrace SaaS.

Target architecture

Application team
      |
      | pull request
      v
payment-onboarding/<app>-<env>.yaml
      |
      v
Azure DevOps pipeline
      |
      +--> Validate onboarding contract
      |
      +--> Ansible --> EC2 --> OneAgent
      |                     host group / network zone / host tags
      |
      +--> Monaco --dry-run
      |
      +--> Protected production environment approval
      |
      +--> Monaco deploy --> Dynatrace SaaS configuration

EC2 OneAgent --> Environment ActiveGate --> Dynatrace SaaS

Repository layout

Dynatrace/
├── README.md
├── monaco.md                         # consumer onboarding guide
├── azure-pipeline.yaml               # Azure DevOps pipeline
├── payment-onboarding/
│   └── payment-prod.yaml             # reference onboarding contract
├── ansible/
│   ├── ansible.cfg
│   ├── inventory/
│   │   └── prod.ini.example
│   ├── install-oneagent.yaml
│   └── roles/
│       └── oneagent/
│           ├── defaults/main.yaml
│           └── tasks/main.yaml
├── monaco/
│   ├── manifest.yaml
│   └── payment/
│       ├── config.yaml
│       ├── management-zone.json
│       ├── maintenance-window.json
│       └── slo.json
└── scripts/
    └── validate-onboarding.py

Responsibility boundaries

Layer Tool Purpose
AWS infrastructure Terraform / cloud platform tooling EC2, security groups, ActiveGate infrastructure
Host monitoring Ansible + OneAgent install OneAgent and apply host-level metadata
Dynatrace configuration Monaco management zones, maintenance windows, SLOs and other tenant configuration
CI/CD governance Azure DevOps validation, approvals, secret handling and deployment
Access Dynatrace IAM / corporate IdP user/group permissions and least privilege

Security model

Do not commit Dynatrace tokens, OAuth client secrets, SSH private keys, or cloud credentials. Store secrets in Azure DevOps secret variables or Azure Key Vault.

The examples expect these secret/runtime values to be supplied by the pipeline:

Production workflow

  1. Application team copies the onboarding contract and fills in application metadata.
  2. Pull request validation runs scripts/validate-onboarding.py.
  3. The platform team reviews naming, criticality, network zone and SLO requirements.
  4. If host onboarding is requested, Ansible installs/configures OneAgent.
  5. Monaco runs monaco deploy --dry-run monaco/manifest.yaml.
  6. Production deployment uses an Azure DevOps deployment job bound to a protected Environment.
  7. Configure approvals/checks on that Azure DevOps Environment; approvals are governance settings, not embedded secrets in YAML.
  8. The deployment job runs monaco deploy monaco/manifest.yaml.
  9. Verify OneAgent connectivity, Java process/service discovery, management-zone membership and SLO state in Dynatrace.

Important implementation notes

monaco deploy --dry-run validates the Monaco manifest, projects and resolved configuration. It does not make changes to Dynatrace. The actual monaco deploy stage performs the deployment.

The Payment example intentionally uses application metadata and tags as the stable contract. Do not build reusable configuration around transient Dynatrace entity IDs.

See monaco for the step-by-step procedure that another application team should follow. visit my repo: Github


My Page: Observability

Dynatrace : Main Page