Dynatrace Closes Arize Deal to Join Evals and Observability

Dynatrace has finished buying Arize, and the interesting part is a single idea: testing an AI app before launch and watching it in production are meant to become one workflow. On October 1, 2026, Dynatrace announced it had completed the acquisition. If you keep LLM apps alive for a customer, the Dynatrace Arize pairing is a good excuse to check how portable your own tracing and eval setup is.

What the Dynatrace Arize announcement says

The release is short on specifics, so here is everything it commits to:

• Dynatrace completed its acquisition of Arize, an AI observability and evaluation platform.
• The stated goal is to combine evaluation and observability, so teams can test AI applications before launch and keep them reliable in production.
• Arize will keep supporting Phoenix, its open-source platform, and AX, its enterprise platform.
• "Over time, Arize capabilities will be integrated into Dynatrace, giving customers a unified AI observability experience."

What it does not include: integration features, dates, or milestones. It also does not disclose the terms of the deal. Anything beyond the four points above is speculation, including from me.

Why joining evals and AI observability matters in production

Evals and observability usually live in different places. Evals run in CI or a notebook against a curated set of prompts. Observability lives on an ops dashboard and tells you latency, errors and token counts, but not whether the answer was any good.

Both gaps hurt. An eval suite that passed on 200 hand-picked prompts says nothing about the afternoon your retrieval index went stale. A trace showing a healthy 800 ms response says nothing about whether the model made up a refund policy.

Join them and a production trace can become a test case, and a failing eval score can point at the exact trace behind it. That loop is what the release describes, and it is what teams doing LLM evals in production build by hand today with scripts and spreadsheets.

The caution: "continue supporting" is not a roadmap. Nothing in the release says Phoenix or AX will change, and nothing promises they won't. That uncertainty is normal after any acquisition, and it is a reason to plan, not to panic.

What to do on Monday morning

You do not need to migrate anything. You need to be able to migrate, and to know how long it would take. This applies to every tracing or eval vendor you use, not only this one.

1. List what is trapped in each tool

Write down where these live: traces, eval datasets, LLM-judge prompts, scoring code, and experiment results. Anything that exists only inside a vendor's UI is the part that would hurt to lose.

2. Emit traces over OpenTelemetry and send a second copy elsewhere

Phoenix accepts traces over OTLP and uses OpenInference instrumentation, so you can wire the standard OpenTelemetry SDK yourself and fan out to two backends:

pip install opentelemetry-sdk opentelemetry-exporter-otlp-proto-http openinference-instrumentation-openai

from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from openinference.instrumentation.openai import OpenAIInstrumentor

provider = TracerProvider()

# Backend 1: a Phoenix instance (local default shown)
provider.add_span_processor(BatchSpanProcessor(
    OTLPSpanExporter(endpoint="http://localhost:6006/v1/traces")
))

# Backend 2: any OTLP-compatible backend you want a spare copy in
provider.add_span_processor(BatchSpanProcessor(
    OTLPSpanExporter(
        endpoint="<your-other-backend>/v1/traces",
        headers={"Authorization": "<your-auth-header-value>"},
    )
))

OpenAIInstrumentor().instrument(tracer_provider=provider)

This instruments the OpenAI client and ships every span to both places. Swap the instrumentor for the one matching your framework. Check what your second backend expects for the auth header and path before relying on it.

3. Keep eval datasets as files you own

Export each dataset on a schedule and commit it next to the code. The Phoenix CLI can pull a dataset to a file:

npx @arizeai/phoenix-cli dataset get my-dataset --file dataset.json

Or use the Python client from the Phoenix client docs:

from phoenix.client import Client

client = Client()
dataset = client.datasets.get_dataset(dataset="my-dataset")
df = dataset.to_dataframe()  # columns: input, output, metadata
df.to_json("evals/my-dataset.jsonl", orient="records", lines=True)

The sample uses the no-argument client from the docs, which talks to a default local instance. Look up the client settings for a remote or self-hosted one. Keep your judge prompts and scoring functions in the same folder, in plain text.

4. Run an exit drill once

Take one dataset from git and run it through a different harness, even a plain pytest file that calls your model and your judge. If it takes an afternoon, you are in good shape. If it takes two weeks, you have found your real lock-in.

Gotchas

• Check the license of what you self-host. Phoenix has been distributed under the Elastic License 2.0, so read the terms for the exact version you run.
• Exported data may carry customer content. Prompts and responses in traces can contain personal data, so the second copy needs the same retention and access rules as the first.
• Don't rip anything out today. With no dates and no feature list, there is nothing to migrate away from yet.

If your evals and traces can leave the tool they were born in, a vendor's acquisition becomes a news item instead of an incident for the system you are keeping alive in production.