Ellipse Gradient for Header

Dynatrace Integration Guide

Connect Dynatrace observability data, problem notifications, telemetry ingestion, and DQL queries with enterprise systems through REST APIs and Martini workflows.

Dynatrace integration options at a glance

Dynatrace’s primary integration surface is its REST API, which supports environment resources, Problems, Entities, metrics, logs, events, dashboards, configuration, telemetry ingestion, and DQL-based queries. Selected alerting and problem-notification scenarios can send webhook-style requests to a Martini API endpoint. Dynatrace also supports batch-oriented metric and log ingestion, while query APIs provide analytics access to Grail rather than direct database connectivity. Martini can securely call these APIs, receive selected notifications, batch and transform telemetry, schedule incremental synchronization, expose normalized REST APIs, and route results to ITSM, collaboration, databases, or reporting systems.

Integration pointSupported by Dynatrace?Common use casesHow Martini supports it
REST APIsYesManage and query Problems, Entities, metrics, logs, events, dashboards, configuration, synthetic monitoring, and other environment resources. REST APIs also support telemetry ingestion and DQL query access.Martini can consume Dynatrace REST APIs from workflows, map JSON responses, apply business rules, and expose normalized REST APIs for downstream consumers.
Webhooks / outbound callbacksLimitedSend selected problem-alerting and notification payloads to an external HTTP endpoint. Coverage depends on the Dynatrace notification or workflow feature in use.Martini can expose a REST endpoint, validate and normalize incoming requests, route notifications, and invoke downstream workflows.
Bulk / async / batch APIsYesIngest multiple metric data points or batches of log records while reducing request overhead for high-volume telemetry flows.Martini can batch, transform, filter, and submit telemetry payloads, then preserve rejected records for retry or investigation.
Database / analytics accessLimitedUse DQL and related query APIs to analyze Grail data over HTTP. This is query access rather than direct SQL database connectivity.Martini can submit parameterized DQL queries, process result sets, and route them to reports, databases, files, or other applications.
AuthenticationYesAuthenticate with API tokens using the Api-Token authorization scheme, or use OAuth 2.0 for supported Dynatrace account and platform API scenarios.Martini can keep tokens and OAuth client credentials in environment-specific secrets and apply them at runtime with least-privilege permissions.
SDKs and client librariesLimitedDynatrace provides documentation and client tooling for selected APIs and languages, but direct HTTP integration is generally more portable for workflow orchestration.Martini can call the documented HTTP APIs directly, retaining explicit control over authentication, pagination, retries, and transformations.
Scheduled synchronizationYesPoll Problems, Entities, metrics, logs, or query results where webhook coverage is unavailable or where reconciliation and historical synchronization are required.Martini scheduler-triggered workflows can use time windows, continuation state, overlap periods, and downstream deduplication.

How Dynatrace exposes data and business events

Dynatrace REST APIs

REST is Dynatrace’s primary integration mechanism for environment configuration, Problems, Entities, metrics, logs, events, dashboards, telemetry ingestion, and other supported resources. DQL query access is also provided through HTTP APIs.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to the appropriate Dynatrace environment, calls the required REST resource, follows pagination or continuation information, maps the JSON response, applies business rules, and writes the result to downstream systems or exposes it through a Martini API.

Implementation sequence

Authenticate with an environment-specific API token or supported OAuth 2.0 credentials
Call the required Dynatrace REST resource
Follow pagination or continuation information until the result is complete
Validate and map the JSON response
Apply routing, filtering, and business rules
Write the result to the target system and record processing state

Dynatrace Webhook Notifications

Dynatrace supports webhook-style outbound notifications for selected problem-alerting and notification scenarios. These notifications do not represent a universal event stream for every telemetry object or Dynatrace resource.

Martini implementation pattern

Martini implementation pattern: expose a secured REST endpoint, receive the Dynatrace notification, validate its authorization and required fields, normalize the Problem payload, and route it to ITSM, escalation, ticketing, or collaboration systems. Scheduled polling can supplement notification coverage.

Implementation sequence

Receive the selected Dynatrace notification at a Martini API endpoint
Validate the request, authorization, and required Problem fields
Derive an idempotency key from the Dynatrace problem identifier
Normalize severity, status, affected Entities, and evidence
Route the notification according to environment and business rules
Create or update the downstream incident and record the outcome

Dynatrace Batch Ingestion APIs

Dynatrace provides ingestion APIs for batches of telemetry such as metrics and logs. Payload limits, formats, compression options, and endpoint behavior vary by telemetry type.

Martini implementation pattern

Martini implementation pattern: receive or retrieve source telemetry, validate required fields, transform it into the applicable Dynatrace ingestion format, group records into bounded batches, submit the batches, and preserve rejected records for investigation or retry.

Implementation sequence

Receive or retrieve source metrics or log records
Validate timestamps, dimensions, content, and required fields
Transform records into the applicable Dynatrace ingestion format
Group records into bounded batches
Submit each batch to the Dynatrace ingestion API
Store rejected records and retry only transient failures

Dynatrace DQL Query APIs

Dynatrace provides DQL and related query APIs for analytics access to Grail data over HTTP. Query results can support operational reporting, reconciliation, and on-demand data services.

Martini implementation pattern

Martini implementation pattern: accept or construct a constrained query with approved parameters, call the Dynatrace query API, handle result and empty-set variations, transform the response into JSON or CSV, and deliver it to a downstream consumer or Martini API client.

Implementation sequence

Accept approved query parameters and establish a bounded time range
Submit the DQL query through the Dynatrace query API
Validate the response and handle an empty result set
Map result columns into the reporting model
Generate the requested JSON, CSV, or downstream payload
Return or deliver the result and record query execution details

Common Dynatrace integration patterns

Pattern 1: Route Dynatrace problems to ITSM

When to use this pattern

Use this pattern when selected Dynatrace problem notifications should create or update operational incidents in an ITSM platform. It supports real-time alert handling while retaining a scheduled reconciliation path for missed or changed notifications.

Integration direction
Dynatrace
Martini
ServiceNow
Example Mapping
Dynatrace FieldCanonical FieldTarget Field
problemIdincidentCorrelationKeycorrelation_id
severityLevelprioritypriority
titlesummaryshort_description
affectedEntitiesaffectedResourcesconfiguration_items
Martini implementation pattern

A Martini API receives the selected notification, validates the request, normalizes the Problem payload, and applies environment, severity, and ownership rules. The workflow looks up an existing incident by problemId, creates or updates the ServiceNow incident, and retries transient failures without creating duplicates. A scheduled workflow can reconcile open Problems against downstream incident state.

Martini capabilities used
  • APIs
  • workflows
  • data mapping
  • business rules
  • error handling
  • reusable integration logic

Pattern 2: Synchronize Problems and Entities for reporting

When to use this pattern

Use this pattern when operational teams need a governed reporting store or dashboard containing Dynatrace Problems and their affected Entities. It is appropriate when webhook coverage is incomplete or historical and incremental synchronization is required.

Integration direction
Dynatrace
Martini
Database
Example Mapping
Dynatrace FieldCanonical FieldTarget Field
problemIdexternalProblemIddynatrace_problem_id
statuslifecycleStatusproblem_status
entityIdresourceIdentity_id
startTimeopenedAtopened_at
Martini implementation pattern

A scheduler starts a Martini workflow that queries Problems and affected Entities using a bounded time window and continuation handling. Martini maps the results into relational or reporting structures, applies an overlap window for late-arriving changes, and upserts using stable Dynatrace identifiers. Failed pages are logged and retried while the last successful checkpoint is preserved.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination handling
  • data mapping
  • database integration
  • checkpointing
  • retry handling

Pattern 3: Batch external telemetry into Dynatrace

When to use this pattern

Use this pattern when another application or infrastructure source must send metrics or logs to Dynatrace efficiently. Batching is preferable for high-volume telemetry because it reduces request overhead and allows validation before ingestion.

Integration direction
Source application
Martini
Dynatrace
Example Mapping
Dynatrace FieldCanonical FieldTarget Field
sourceTimestampobservedAttimestamp
serviceNameservicemetric or log dimension
measurementValuevaluemetric value
logMessagemessagelog content
Martini implementation pattern

Martini receives or retrieves source telemetry, validates timestamps and required dimensions, filters unsupported records, and converts the payload to the appropriate Dynatrace metric or log ingestion format. The workflow submits bounded batches, records accepted and rejected results, and uses controlled retries for transient failures while avoiding replay of successfully accepted records.

Martini capabilities used
  • workflows
  • API consumption
  • data transformation
  • validation
  • batch processing
  • error handling

Pattern 4: Publish DQL-based operational reports

When to use this pattern

Use this pattern when teams need scheduled or on-demand reports based on Dynatrace Grail data. It can expose a controlled reporting API or generate JSON, CSV, email, or downstream application payloads.

Integration direction
Dynatrace
Martini
Reporting application
Example Mapping
Dynatrace FieldCanonical FieldTarget Field
queryTimeRangereportWindowreport_period
serviceNameserviceservice_name
problemCountincidentCountproblem_count
resultTimestampobservedAtobserved_at
Martini implementation pattern

A Martini workflow accepts approved parameters, submits a bounded DQL query, validates the returned structure, and maps the result into the required report format. It handles empty results, query failures, and schema variation, then returns the report through a Martini API or delivers it to a file, database, or reporting consumer.

Martini capabilities used
  • REST APIs
  • scheduled workflows
  • query orchestration
  • data mapping
  • JSON and file transformation
  • validation
  • error handling

Applications commonly integrated with Dynatrace

Dynatrace is commonly connected to incident management, collaboration, escalation, and cloud-monitoring products. Martini can orchestrate these integrations through Dynatrace REST APIs, selected webhook notifications, scheduled workflows, and reusable transformation logic.

Application Scenario Direction Martini Pattern
ServiceNow Create, update, and resolve incidents from Dynatrace Problems while synchronizing ownership, priority, and lifecycle information. Dynatrace → Martini → ServiceNow Receive selected Dynatrace problem notifications or poll Problems on a schedule, normalize the payload, apply routing and priority rules, and upsert ServiceNow incidents using the Dynatrace problem identifier for idempotency.
Jira Service Management Convert selected Dynatrace Problems into Jira incidents or requests and maintain operational status links. Dynatrace → Martini → Jira Service Management Consume Dynatrace notifications or REST responses, map severity and affected Entities to Jira fields, create or update issues, and retry transient API failures without duplicating incidents.
PagerDuty Route high-severity Dynatrace Problems to on-call schedules and escalation policies. Dynatrace → Martini → PagerDuty Filter Dynatrace problem notifications by severity and environment, transform them into PagerDuty event requests, and correlate subsequent state changes with the original problem identifier.
Slack Publish operational alerts, problem summaries, and remediation notifications to selected channels. Dynatrace → Martini → Slack Receive selected Dynatrace notifications, enrich them with affected Entity and DQL-derived context when required, format a concise message, and route it to the appropriate Slack channel.
Microsoft Teams Share Dynatrace problem notifications and operational summaries with incident-response teams. Dynatrace → Martini → Microsoft Teams Use a Martini webhook-triggered workflow to validate Dynatrace requests, apply channel-routing rules, transform the payload, and publish the resulting operational summary to Teams.
Opsgenie Forward alerts to on-call teams and synchronize alert lifecycle information where the selected Dynatrace integration supports it. Dynatrace → Martini → Opsgenie Map selected Dynatrace Problem states to Opsgenie alert actions, preserve the Dynatrace identifier as the correlation key, and handle transient delivery failures with bounded retries.
AWS CloudWatch Correlate or transfer cloud monitoring information between AWS monitoring and Dynatrace according to the selected integration design. AWS CloudWatch → Martini → Dynatrace Retrieve or receive supported CloudWatch data, normalize dimensions and timestamps, apply filtering or aggregation, and submit batches to the appropriate Dynatrace ingestion API.
Kubernetes Enrich Dynatrace Entities, Problems, and metrics with cluster, workload, and deployment context. Kubernetes → Martini → Dynatrace Orchestrate Kubernetes or Dynatrace API calls as required, map workload identifiers to Dynatrace Entity information, and persist or forward the normalized operational context.

How to build a Dynatrace integration in Martini

Objective

Configure access to the required Dynatrace environment without embedding credentials in workflow definitions.

Instructions in Martini

  • Set the Dynatrace base URL and environment-specific configuration
  • Use an API token with the minimum required permissions or supported OAuth 2.0 credentials
  • Store tokens and client credentials in Martini secrets
  • Separate development, staging, and production configuration

Objective

Select a trigger that matches the required latency and Dynatrace coverage.

Instructions in Martini

  • Use a Martini API endpoint for selected Dynatrace webhook notifications
  • Use a scheduler for reconciliation, reporting, and incremental synchronization
  • Use an inbound API or workflow trigger for source telemetry ingestion
  • Do not assume webhook coverage for every Dynatrace object or telemetry record

Objective

Obtain Dynatrace Problems, Entities, telemetry, or DQL results through the appropriate integration mechanism.

Instructions in Martini

  • Receive and validate selected Dynatrace notifications
  • Call the applicable Dynatrace REST or query API
  • Follow pagination or continuation information
  • Use bounded time windows and checkpoints for scheduled retrieval

Objective

Coordinate calls, enrichment, routing, and persistence in a maintainable Martini workflow.

Instructions in Martini

  • Separate vendor-specific API calls from canonical transformation logic
  • Enrich Problems with affected Entity information when required
  • Apply environment, severity, ownership, and destination routing rules
  • Use reusable workflow components for repeated Dynatrace operations

Objective

Convert Dynatrace payloads into target-specific models or Dynatrace ingestion formats.

Instructions in Martini

  • Map required fields from Problems, Entities, Metrics, Logs, Events, or DQL results
  • Normalize timestamps, identifiers, severity, and status values
  • Batch metrics and logs when the ingestion API supports it
  • Preserve source identifiers for traceability and idempotency

Objective

Deliver transformed data to ITSM, collaboration, reporting, database, or Dynatrace endpoints.

Instructions in Martini

  • Create or update target incidents using a stable Dynatrace correlation key
  • Submit validated metric or log batches to Dynatrace ingestion APIs
  • Write reporting results to a database, file, API, or operational dashboard
  • Record accepted, rejected, and skipped items separately

Common Dynatrace data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ProblemsRepresent detected or correlated incidents with status, severity, affected Entities, evidence, and root-cause information.ServiceNow, Jira Service Management, PagerDuty, Opsgenie, Slack, Microsoft TeamsMartini receives selected notifications or queries Problems, applies severity and routing rules, and uses the problem identifier for correlation and idempotency.
EntitiesDescribe monitored hosts, services, applications, process groups, Kubernetes resources, and cloud resources.ServiceNow, reporting databases, data warehouses, operational dashboardsMartini retrieves Entity details, maps identifiers and relationships into a canonical model, and enriches Problem or reporting payloads.
MetricsRepresent time-series measurements for querying, monitoring, correlation, or ingestion.Dynatrace, reporting databases, cloud-monitoring platformsMartini queries or transforms metrics, filters dimensions, batches ingestion payloads, and handles rejected data separately.
LogsProvide log records for ingestion into or querying from Dynatrace Grail.Dynatrace, reporting stores, operational analysis workflowsMartini validates and transforms log batches, submits them through the applicable ingestion API, and retries transient failures without replaying accepted records.
EventsRepresent discrete observability events associated with monitored Entities or operational conditions.ServiceNow, PagerDuty, collaboration platforms, DynatraceMartini maps event type, timestamp, Entity, and state information, then routes or ingests the event according to business rules.
DQL resultsReturn analytical results from queries against Dynatrace Grail data.CSV reports, JSON APIs, databases, email and operational dashboardsMartini submits constrained queries, handles empty or changing result structures, maps rows into target formats, and exposes scheduled or on-demand reporting APIs.

Authentication and security considerations

Authentication and least privilege

Dynatrace commonly uses API tokens in the Authorization header with the Api-Token scheme. OAuth 2.0 is available for supported account and platform API scenarios. Required permissions vary by operation, so separate read-only, ingestion, and configuration credentials where appropriate.

Secrets and endpoint protection

Store Dynatrace tokens, OAuth client credentials, base URLs, and shared webhook secrets in environment-specific Martini secrets and configuration. Secure Martini endpoints that receive Dynatrace notifications and validate authorization, sender details, and required payload fields.

Tenant isolation

Keep development, staging, and production Dynatrace environments isolated through separate configuration and credentials. Do not embed secrets in workflow definitions or expose unrestricted operational data through façade APIs.

Operational considerations for Dynatrace integrations

Rate limits and volume

Use bounded concurrency, exponential backoff, filtering, aggregation, and batching where supported. High-volume metrics and logs should not be processed through a synchronous per-record design when Dynatrace ingestion APIs support batches.

Pagination and incremental windows

Follow pagination or continuation information until completion. Scheduled workflows should use timestamps, cursors, or last-successful-run markers, with a small overlap window to account for clock differences and late-arriving data.

Idempotency and retries

Use stable Problem, event, Entity, or composite identifiers to prevent duplicate incidents and replayed data. Retry transient failures and rate limits, but preserve validation failures and rejected telemetry for review.

Schema and query changes

Dynatrace API versions, notification payloads, and DQL result structures can change. Map required fields, tolerate additional properties, handle empty results, constrain query time ranges, and isolate vendor-specific transformations.

Testing and monitoring

Test representative Problems, Entity relationships, telemetry batches, empty query results, authorization failures, and duplicate notifications across environments. Monitor workflow logs, rejected records, retry counts, and downstream correlation outcomes.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Dynatrace API calls, webhook reception, DQL queries, telemetry batching, downstream writes, and reconciliation in governed workflows rather than scattering logic across scripts.

Reusable transformations

Mappings and vendor-specific rules can be reused across ServiceNow, collaboration, reporting, and ingestion flows. Martini can expose normalized APIs so downstream consumers do not need to understand every Dynatrace payload variation.

Operational reliability

Workflows can implement validation, pagination, checkpoints, idempotency, bounded retries, error routing, and environment-specific configuration. This makes high-volume and multi-environment integrations easier to operate than isolated point-to-point scripts.

Controlled extensibility

Martini provides standards-based API and workflow integration while allowing custom transformation or business logic where required. The result is an integration asset that can evolve as Dynatrace resources, notification payloads, and enterprise routing requirements change.

Frequently asked questions

How can Dynatrace be integrated with enterprise systems?

Dynatrace can be integrated through its REST APIs for Problems, Entities, metrics, logs, events, dashboards, configuration, telemetry ingestion, and DQL queries. Selected problem-alerting scenarios can send webhook-style notifications to external HTTP endpoints, while scheduled workflows can support reconciliation and synchronization where notifications are incomplete.

Can Martini integrate with Dynatrace?

Yes. Martini can consume Dynatrace REST and query APIs, receive supported Dynatrace webhook notifications through a Martini API, transform JSON payloads, batch telemetry, and route data to enterprise applications, databases, files, or reporting services.

Do I need a connector to integrate Dynatrace with Martini?

No. A dedicated Dynatrace connector is not required. Martini can use Dynatrace’s confirmed native REST APIs, selected webhook-style notifications, batch ingestion APIs, DQL query APIs, and API-token or OAuth authentication mechanisms.

Is there any extra Lonti cost to integrate Dynatrace with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Dynatrace. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Dynatrace, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.

Which Dynatrace integration methods should architects use?

REST APIs are the primary choice for resource access, configuration, telemetry ingestion, and queries. Use selected webhook-style notifications for supported problem-alerting scenarios, batch ingestion APIs for metrics and logs, and DQL query APIs for analytics. A general-purpose Dynatrace GraphQL or SOAP API was not confirmed.

Are Dynatrace events and webhooks available for all telemetry?

No. Dynatrace supports webhook-style notifications for selected problem-alerting and notification scenarios, but this is not a universal event stream for every object or telemetry record. Metrics, logs, traces, and events are generally handled through ingestion APIs, and scheduled polling may be needed for reconciliation.

How does Martini synchronize Dynatrace data?

Martini can run scheduled workflows that query Problems, Entities, metrics, logs, or DQL results using bounded time windows, pagination, continuation state, and overlap periods. Stable Dynatrace identifiers and downstream upserts help account for late-arriving data and prevent duplicate results.

How are Dynatrace errors, retries, and duplicate notifications handled?

Martini can distinguish authentication, validation, rate-limit, transient server, and permanent resource failures. Workflows should retry only transient failures with bounded backoff, preserve rejected payloads for investigation, and use a Problem or event identifier as an idempotency key so repeated notifications update existing downstream records.

Can Martini expose an API façade for Dynatrace?

Yes. Martini can expose a controlled REST API that normalizes Dynatrace Problems, Entities, metrics, logs, events, or DQL results for internal consumers. The façade can centralize authentication, filtering, transformation, authorization, rate control, and vendor-specific API behavior.

Related Martini documentation

APIs

Triggers

Workflows

Security

Operations

Connect Dynatrace to your enterprise systems

Use Martini to build governed Dynatrace integrations for problem notifications, telemetry ingestion, DQL reporting, and scheduled synchronization across your operational landscape.

EXPLORE MARTINI
BOOK A DEMO