From Crashing to Crushing It: How DSV (DB Schenker) Handles 3.5 Trillion Datapoints with VictoriaMetrics

  • transport and logistics
  • Kubernetes environments

If you've ever managed a growing Prometheus stack, you know the feeling. First, the dashboards get a little sluggish. Then, you hit memory or CPU limits on an instance. Before you know it, you're dealing with occasional crashes, "partial unavailability," and—worst of all—unreliable alerts. This isn't just a technical headache; it's a business-critical failure. This is the exact position transport and logistics giant DSV (DB Schenker) found themselves in. Their federated Prometheus architecture, once a reliable solution, was buckling under the sheer scale of their Kubernetes environments. They faced a monitoring crisis. We're excited to share the story of how they solved it.

The "Big Wins" with VictoriaMetrics

  • Big Win #1: Stability & Reliability

  • Big Win #2: Operational Simplicity

  • Big Win #3: Massive, Proven Scale

  • DSV (DB Schenker) deployed a VictoriaMetrics cluster and, over four years, has turned it into a rock-solid, foundational component of their entire observability platform.
  • The impact wasn't just a small improvement; it was a fundamental transformation.
  • The "crashes" and "partial unavailability" that plagued the old system were eliminated. By moving to a highly available (HA) VictoriaMetrics cluster, DSV (DB Schenker) restored reliability to their critical alerting and notification pipelines. They could trust their monitoring again.
  • The complex, brittle federated architecture is gone. It was replaced by a streamlined, multi-tenant cluster. VMAgent, using its efficient streaming mode, securely forwards data from all clusters to a central, scalable, and easy-to-manage system.
  • Instead of fighting crashes, the Schenker team now manages one of the largest monitoring footprints in the logistics industry without issue. The new system handles this scale as its day-to-day baseline.

The Challenge: A System at its Breaking Point

Schenker's monitoring team was spending more time managing their monitoring *tools* than monitoring their *applications*.

They needed a new foundation—one built for hyperscale, simplicity, and stability.

Their federated setup was a complex beast, leading to:

  • Frequent Crashes: Instances would hit resource constraints and simply fall over.
  • Service Unavailability: Gaps in graphs and monitoring data became common.
  • Unreliable Alerting: The team lost trust in their notification pipeline. When an alert didn't fire, was the system healthy, or was the monitoring just broken?
  • Operational Nightmare: Managing federation, data synchronization, and retention policies across multiple clusters was a heavy, full-time burden.

Solution

DSV (DB Schenker) deployed a VictoriaMetrics cluster and, over four years, has turned it into a rock-solid, foundational component of their entire observability platform.

The impact wasn't just a small improvement; it was a fundamental transformation.

They needed a new foundation—one built for hyperscale, simplicity, and stability.

  • hyperscale

  • simplicity

  • stability

  • They faced a monitoring crisis. We're excited to share the story of how they solved it.
  • They needed a new foundation—one built for hyperscale, simplicity, and stability.

The Proof is in the Numbers

  • Here is what DSV (DB Schenker)'s VictoriaMetrics cluster handles right now:

  • Ingestion Rate

    ~800,000 datapoints/second

  • Total Datapoints Stored

    ~3.5 Trillion

  • Daily New Time Series

    ~85 Million

  • Active Time Series (Peak)

    ~72 Million

  • Data on Disk

    (A testament to VictoriaMetrics' best-in-class compression)

    ~1.83 TB

  • The most impressive part?

    This massive system is not a fragile monolith. It's a stable, horizontally-scalable cluster that just *works*, allowing the team to focus on what's next—like integrating OpenTelemetry and trace data.

  • DSV (DB Schenker) didn't just scale their monitoring; they built a future-proof foundation for observability.