Partner: Tintri Industry: Enterprise Data Storage Engagement: OpenTelemetry Collector Integration for Tintri VMstore Partner Website: tintri.com Integration Plumbers Website: integrationplumbers.io
Storage has always been the blind spot in observability.
If you run Kubernetes at scale, you probably have deep visibility into your applications, your containers, your network layer. You can trace a request from ingress to database query, correlate logs across microservices, and set SLOs on latency down to the millisecond. But ask most platform teams what their storage is doing underneath all of that — whether a slowdown is coming from the app or the array — and you'll often get silence, or at best, a separate dashboard from a completely different toolchain.
That's the gap Tintri came to us to fix.
The Call That Started It All
When Tintri reached out to Integration Plumbers, they had a clear vision: bring their VMstore storage telemetry into the same open, vendor-neutral observability fabric that Kubernetes teams already use. They didn't want another proprietary agent. They didn't want a one-off integration that would lock their customers into a single monitoring vendor. They wanted OpenTelemetry — the de facto open standard for telemetry — and they wanted it done right.
They came to us because that's exactly what we do.
Enterprise organizations running Tintri VMstore alongside Kubernetes and virtualized workloads were facing real operational pain points that made this partnership urgent:
Siloed visibility. When an incident occurred, SREs had no efficient way to determine whether the root cause was in the application layer, the container orchestration layer, or the storage layer. Investigating a performance issue meant switching between disconnected dashboards, manually correlating timestamps, and coordinating across teams with different tools.
Vendor lock-in on observability. Without an open-standard integration, customers who wanted storage metrics in their observability platform had to rely on proprietary agents or point-to-point integrations that tied them to a single monitoring vendor. Switching backends or adding a new analytics tool meant rebuilding the storage integration from scratch.
Operational overhead. Managing a separate monitoring stack just for storage added cost, complexity, and cognitive load. Operations teams were maintaining multiple agents, multiple credential sets, and multiple alerting configurations for what should be a single unified view of infrastructure health.
No correlation with application data. The most valuable insights come from correlating storage behavior with application and Kubernetes metrics. Without a shared telemetry pipeline, those correlations required manual effort and tribal knowledge rather than automated dashboards and alerts.
Tintri's platform was uniquely positioned to solve this problem. VMstore operates at the virtual machine and container level rather than at the traditional LUN or volume level, meaning it produces workload-aware metrics — per-VM performance profiles, QoS data, and capacity analytics — that are directly relevant to the application teams consuming them. What was missing was the bridge: a way to expose that rich telemetry through the same open standard their customers had already adopted for everything else.
Why This Matters for the Industry
Let me step back and talk about why this partnership matters beyond just Tintri and Integration Plumbers.
The enterprise storage market is at an inflection point. Organizations are consolidating their observability strategies around OpenTelemetry. Cloud-native teams have already adopted it for application instrumentation, and now infrastructure teams are asking the obvious question: why can't my storage, my networking gear, my hypervisor all feed into the same pipeline?
The answer, historically, has been that each vendor ships its own monitoring agent, its own protocol, its own dashboard. You end up with five tools to monitor five layers of your stack, and when something goes wrong, your SREs are jumping between consoles trying to correlate timestamps manually. It's slow, it's expensive, and it creates organizational friction between storage teams and platform teams who are literally looking at different screens.
OpenTelemetry changes this equation entirely. When storage metrics flow through the same Collector pipelines as your application metrics, you get a unified telemetry stream. Your SREs can see whether an incident is storage-driven or application-driven without leaving their Grafana dashboard or Datadog console. You reduce mean time to resolution. You eliminate the finger-pointing between teams. And critically, you future-proof your observability strategy — because the OTEL Collector is the integration point, not the backend. If you switch from Prometheus to Datadog, or add ClickHouse for long-term analytics, your storage telemetry comes along for the ride without any reinstrumentation.
Tintri gets this. Their VMstore platform is already workload-aware — it manages resources at the virtual machine and container level, not just at the LUN or volume level. That granularity is exactly what makes their telemetry so valuable when it's exposed through OpenTelemetry. You're not just getting aggregate throughput numbers; you're getting per-VM performance profiles, QoS metrics, and capacity data that can be correlated directly with the Kubernetes workloads running on top.
What We're Building Together
Integration Plumbers is designing and building a Tintri OpenTelemetry Collector integration that collects metrics from Tintri's REST APIs and exposes them as first-class OTEL signals. The solution architecture follows standard OpenTelemetry Collector patterns, ensuring compatibility with any OTEL-compatible observability backend.
Metrics collection via Tintri APIs. The Collector integration pulls telemetry from both VMstore appliances (for detailed, per-object metrics) and Tintri Global Center (for fleet-wide discovery and aggregated views). This dual-source approach gives customers granularity where they need it and efficiency where they don't.
OTEL semantic convention mapping. Tintri-specific metrics — latency, throughput, capacity, QoS profiles — are mapped to OpenTelemetry-compatible structures with standardized naming and labeling. This means Tintri storage metrics can be correlated with Kubernetes metrics, application traces, and infrastructure data without custom transformation logic on the customer side.
Multi-backend routing. Because the integration uses standard Collector exporters, customers can route Tintri metrics to any combination of backends: Grafana with Prometheus or ClickHouse, Datadog, Dynatrace, or any OTLP-compatible platform. Switching or adding backends requires only a Collector configuration change — no changes to the Tintri integration itself.
Open-source, no proprietary dependencies. The entire integration is being built using standard OpenTelemetry Collector patterns with no proprietary dependencies. It will be contributed to the OpenTelemetry ecosystem under an appropriate open-source license, designed for long-term community maintenance and evolution.
Why Integration Plumbers Exists for Exactly This Kind of Work
We founded Integration Plumbers because we saw a gap in the market. Observability vendors are great at building platforms. Storage vendors are great at building storage. But the plumbing in between — the connectors, the pipelines, the semantic mapping, the production hardening — that work requires a team that lives in both worlds.
Tintri needed a partner with deep, specialized expertise in both OpenTelemetry and enterprise storage integration. Here's why they chose us:
Decades of OTEL experience. Integration Plumbers is a team of observability specialists whose core focus is OpenTelemetry pipelines, custom collector development, and enterprise integrations. We've built 20+ custom plugins and connectors for platforms including Oracle Enterprise Manager, OCI, and other enterprise infrastructure.
Proven track record with storage and infrastructure vendors. We've delivered integrations for Oracle, VMware, Dell, and NetApp — companies with similar enterprise-scale requirements and API complexity. We understand the nuances of collecting metrics from storage systems: handling API authentication and session management, managing metric cardinality across large fleets of VMs and volumes, and mapping vendor-specific data models into OpenTelemetry semantic conventions.
Open-source contribution expertise. Tintri's vision was not just to build an internal integration but to contribute it to the OpenTelemetry community as an open-source project. We have experience navigating the contribution process, designing for community maintainability, and ensuring compliance with OTEL project standards.
End-to-end delivery model. Rather than just writing code, Integration Plumbers provides architecture design, testing against real systems, full documentation, open-source contribution management, and post-release customer support — the complete lifecycle that a production-quality integration requires.
That's why Tintri didn't just build this themselves or hand it to a general-purpose consulting firm. They wanted a partner who could deliver a production-ready Collector integration, contribute it properly to the open-source ecosystem, produce documentation that operations teams can actually follow, and provide ongoing support to their customers as they adopt it.
Development Approach
The project follows a structured three-phase delivery model.
Phase 1 — Discovery and Design. Integration Plumbers worked with Tintri's engineering team to establish environment access, review available APIs and metric surfaces, and finalize the architecture and data model for the Collector integration.
Phase 2 — Build and Test. The Collector implementation is developed and validated against live Tintri systems, with performance and reliability testing to ensure production readiness. Tintri's subject-matter experts collaborate on metric validation to ensure accuracy and completeness.
Phase 3 — Contribution and Enablement. Documentation is finalized, the code is submitted to the OpenTelemetry ecosystem, and iteration is performed based on community feedback. Joint go-to-market activities — including a co-hosted webinar — educate customers on the integration and accelerate adoption.
We're deep into development now, and the collaboration with Tintri's engineering team has been excellent. They've provided system access, API documentation, and subject-matter experts to validate the metrics we're collecting.
Key Benefits
For Tintri customers:
Faster root-cause analysis — SREs can see whether an incident is storage-driven or application-driven from a single dashboard, reducing mean time to resolution and eliminating cross-team finger-pointing.
Cost and tool flexibility — customers reuse their existing observability contracts and platforms instead of purchasing a separate storage monitoring product. OTEL-level filtering and aggregation help control telemetry volume and observability spend.
Reduced vendor lock-in — the open-standard integration decouples Tintri from any single observability vendor, giving customers freedom to switch backends, multi-home data, or add new analytics tools without reinstrumenting.
Future-proof observability — by aligning with OpenTelemetry, customers' storage monitoring strategy evolves with the broader cloud-native ecosystem rather than depending on a single vendor's roadmap.
For Tintri:
Expanded ecosystem presence — native OpenTelemetry support positions Tintri as a forward-thinking, community-aligned storage vendor at a time when platform teams are standardizing on OTEL.
Thought leadership — the integration, joint webinar, and open-source contribution demonstrate Tintri's commitment to open standards and modern operations practices.
Customer engagement — the initiative drives direct engagement with existing customers through early-adopter support and with prospective customers through community visibility and co-marketing.
What Comes Next
Once the Collector is publicly available, we'll be co-hosting a webinar with Tintri to walk through the integration architecture, show a live demonstration, and discuss customer use cases. The initiative is also being positioned for announcement at KubeCon 2026, targeting the cloud-native and SRE community where OpenTelemetry adoption is most advanced.
To accelerate adoption, Integration Plumbers is providing one year of free support for up to three Tintri customers. Support includes deployment and configuration guidance, troubleshooting and defect remediation, and best-practice recommendations for integrating Tintri telemetry into existing OTEL pipelines.
If you're running Tintri storage and you've been looking for a way to bring those metrics into your OpenTelemetry pipelines — or if you're evaluating storage platforms and vendor-neutral observability is on your requirements list — this integration is built for you.
And if you're running any enterprise infrastructure that needs to speak OpenTelemetry, that's what Integration Plumbers does. We make observability accessible, scalable, and meaningful. We're the plumbers, and we're proud of it.
About the Partners
Tintri provides data management solutions for virtualized and containerized workloads. The Tintri VMstore platform delivers workload-aware storage with per-VM automation, QoS, and analytics. Tintri won the Overall Data Storage Company of the Year Award at the 2025 Data Breakthrough Awards. Learn more at tintri.com.
Integration Plumbers is a team of observability specialists focused on OpenTelemetry and enterprise integrations. With decades of experience building custom collectors, exporters, and instrumentation for Fortune 500 companies, Integration Plumbers makes observability accessible, scalable, and meaningful. Learn more at integrationplumbers.io.
For more information about the Tintri OpenTelemetry Collector integration or Integration Plumbers' services, contact us at integrationplumbers.io/contact.
