Annie is Anyshift's CLI for turning graph context into reviewed actions. This case study shows how `annie do` can send deployment context into Dynatrace through the native Events API v2. It follows Annie meets pup, Annie meets gcx, and Annie meets acli.

Summary

When a deploy is followed by a Dynatrace Problem, a timestamp is not enough. The useful event says which service changed, who owns it, where it runs, which Dynatrace entity should carry the event, and why a short burst of noise is expected.

In this demo, graph-connector is preparing a production deploy. Anyshift resolves the change from its graph, annie do turns that context into a reviewed Dynatrace event, and Dynatrace receives a native CUSTOM_DEPLOYMENT event attached to the right monitored entity.

Schema showing Anyshift graph context becoming a reviewed Dynatrace deployment event.

Dynatrace stays where teams investigate. Anyshift adds the change context that is usually scattered across Git, Terraform, cloud state, Kubernetes, and ownership data.

Why This Matters

Dynatrace already has a strong runtime graph. Smartscape on Grail records monitored entities and relationships, supports DQL traversal with smartscapeNodes, smartscapeEdges, and traverse, and keeps topology data for 35 days. The point is to add context to that surface, not replace it.

The gap is upstream of runtime telemetry. A deploy script can tell Dynatrace that version anyshift-demo-20260528-1231 shipped. It usually cannot say:

  • which production service that deploy maps to today
  • which team owns that service
  • which namespace and runtime target are in scope
  • which Terraform, Git, or cloud-state context explains the change
  • which Dynatrace monitored entity should receive the event

That is the layer Anyshift supplies before Dynatrace receives the event.

The Context Anyshift Adds

The operator starts with one request:

annie do --print "send Dynatrace deploy context for graph-connector"

annie do asks Anyshift for the deployment context, writes a small review file, and stops before any write. In this run, Anyshift resolves:

  • service: graph-connector
  • owner: platform
  • runtime scope: prod
  • deployment version: anyshift-demo-20260528-1231
  • reason: expected deploy noise during a short production change
  • Dynatrace target: the graph-connector monitored entity

Dynatrace calls that target selection an `entitySelector`. The Events API v2 uses it to attach an ingested event to matching monitored entities. Without it, the event can land at the environment level. With Anyshift, it lands on the service the on-call engineer is already investigating.

It Lands In Dynatrace

For the demo, annie do creates or updates graph-connector as a Dynatrace custom monitored entity through the Monitored entities API, then sends one deployment event through Events API v2.

Before the run, the Dynatrace Notebook query has no event for this deploy version:

Dynatrace Notebook before the run, showing zero records for the deployment version.

After approval, the same query returns the native Dynatrace event:

Dynatrace Notebook after the run, showing one CUSTOM_DEPLOYMENT event attached to the graph-connector monitored entity.

The query is plain DQL:

fetch events
| filter contains(event.name, "anyshift-demo-20260528-1231")
| sort timestamp desc
| fields timestamp, event.type, event.name, dt.source_entity
| limit 5

The important part is not that Anyshift created another place to look. It did not. The event is visible in Dynatrace, with Dynatrace permissions, Dynatrace history, and a Dynatrace entity ID.

What Changes For The Team

A thin deployment event says: something shipped.

An Anyshift-backed deployment event says: graph-connector shipped, the platform team owns it, it runs in prod, this is the exact runtime entity, and this deploy is expected to create short-lived noise.

That saves work in two places. The deploy pipeline does not need to reimplement the production graph, and the on-call engineer does not need to reconstruct the change from tabs after the alert fires.

The same pattern can carry nearby workflows: attach Terraform or IAM change context to a Dynatrace Problem, send migration events only for services Anyshift knows are in scope, or enrich Dynatrace topology with the Git and IaC provenance behind a runtime entity.

If your team uses Dynatrace and wants deployment context from production reality, contact us.