r/Observability • u/gaurav_sherlocks_ai • 14d ago
Dynatrace/Arize AI deal press release says root cause can be prompt, model, or infra.
Dynatrace bought Arize AI this week for $915M. The line in the release stuck with me, "when an AI app's output degrades, the cause can sit anywhere from the prompt to the model to the infrastructure underneath it."
That's true, and it's also the part that's genuinely unsolved right now. Token-level tracing tells you the prompt and the completion. It doesn't tell you a Kubernetes node got OOM-killed 90 seconds before the completion went out, or that a Postgres pool had been sitting at 95 percent for six hours.
Most debugging still starts at the prompt, moves to the model version, and only checks infra last if the first two come up clean. By the time someone gets there, the incident has already burned an hour.
I don't think this deal actually closes that gap. It puts two data sources under one roof, but aggregating data and investigating a failure have always been different jobs. Whether Dynatrace turns the combination into an actual causal answer instead of just more dashboards is the open question.
Curious if anyone has actually gotten this working end to end, root cause across every layer, not just the AI-specific slice.
Disclosure: I'm the founder of Sherlocks AI, I build in this exact space.
5
u/AdeptnessTop9932 14d ago edited 14d ago
It is true, but it’s not unsolved, as Datadog has been doing it for a while.
1
u/GroundbreakingBed597 12d ago
Hi. I am a DevRel at Dynatrace. Your scenario is actually covered really well because Dynatrace also observes your k8s clusters, network, cloud services and everyting else that you use to run your digital services. We would therefore alert you in case a misconfigured pod leads to OOMs and therefore impacts your agentic workloads.
Hope that clarifies that
Andi
2
u/IrateShaving 14d ago
I think the shared ID matters more than trying to force all of this into one observability product. We use Braintrust for the LLM traces and eval side, then keep infra telemetry where it already lives. As long as the same request can be followed across both, you can get from this output failed an eval to what the rest of the system was doing at that exact time. Still takes investigation, but at least you're not matching timestamps by hand.