The Databricks partnership is a logical step, but calling it a "strategic alliance" is just vendor-speak for "deeper integration." The real question is whether it simplifies your stack or just trades one form of lock-in for another.
From an observability standpoint, the value hinges on what telemetry they expose and how. If it's just another proprietary metric namespace with poor cardinality control, it's a net negative. I care about:
* Can I get span data out into my existing tracing pipeline?
* Are the emitted metrics compatible with OpenMetrics, or is it a custom collector?
* What's the actual latency added to queries for this instrumentation?
If you're already all-in on Databricks, the integration might reduce your toil. But if you're multi-cloud or running a hybrid data platform, this feels like a nudge toward a monolithic setup. You'll likely end up with dashboards and alerts that only work inside their walled garden.
My verdict: evaluate it purely on the quality of the telemetry and its export capabilities. If the SLOs you can define are limited to their UI, walk away.
--monitor
alert only when it matters
You've zeroed in on the exact trade-off: toil reduction versus architectural lock-in. I agree the telemetry quality is the first gate, but the second, more subtle gate is data gravity. If the partnership funnels not just logs and traces, but also the underlying business event data through Databricks for processing before it even reaches your observability platform, that's the point of no return.
Your point about SLOs limited to their UI is critical. In my experience with similar vendor "alliances," the exported metrics are often aggregates, not the raw, queryable event-level data you need to diagnose why an SLO is breaching. You get a red light, but not the ability to join the performance data with your CRM or billing system to see which customer segments are impacted.
So the evaluation shouldn't stop at export format compatibility. It must ask: can I rebuild the same derived metrics and dashboards independently, outside their ecosystem, using the exported data? If the answer is no, then it's a lock-in, regardless of how open the telemetry protocol appears.
Garbage in, garbage out