Datadog

What is Datadog?

Datadog is a commercial, cloud-based observability platform that unifies infrastructure metrics, application performance monitoring (APM/distributed tracing), log management, real-user monitoring, synthetics, security monitoring, and more into a single integrated product. Instead of assembling and operating the open-source stack (Prometheus + Grafana + Loki + Jaeger), you install Datadog’s agent, turn on integrations, and get correlated visibility across your whole stack. It’s one of the market-leading platforms in this space, competing directly with New Relic, Dynatrace, and the cloud providers’ native tools.

The buy-vs-build decision it represents

Datadog is the archetypal “buy” side of the observability buy-vs-build choice. Build with open source: no per-data licensing, full control, but you operate, scale, secure, and maintain the pipeline yourself — real, ongoing engineering effort. Buy Datadog: stand up comprehensive observability in days, get tight correlation across metrics/traces/logs, hundreds of turnkey integrations, and vendor support — but you pay, and the pricing model is the whole story. Datadog’s strength is genuine: the integration and correlation across signal types (jump from a metric spike to the traces to the logs in one UI) is exactly what fragmented open-source tooling struggles to deliver, and its breadth of integrations is enormous. The reason to think hard before adopting is equally genuine: cost.

Why Datadog is synonymous with bill shock

Datadog has become a byword for surprise observability bills, and understanding the mechanism is essential before adoption. Pricing is modular and volume-driven — you pay per host for infrastructure, per million spans/events for APM, per gigabyte ingested and per million log events for logs, plus separate charges for each additional product (synthetics, RUM, security, etc.). Costs scale with exactly the things engineers instinctively maximize: number of hosts/containers, volume of logs and traces, custom metrics (and here the cardinality trap bites hard — every unique combination of tag values is a separate billable custom metric, so a high-cardinality tag like user_id can generate a staggering custom-metric bill), and the number of products enabled. Teams that “instrument everything” at full fidelity — verbose debug logs, unsampled traces, high-cardinality custom metrics across a large fleet — regularly see bills balloon far past expectations, sometimes to eye-watering, publicly-discussed figures. The disciplines that keep it economical: sample traces, filter and tier logs (don’t ingest-and-index everything), bound custom-metric cardinality, and turn on only the products you’ll actually use. Used with cost discipline, Datadog is a powerful time-saver; used as “turn it all on,” it’s a runaway expense — the same lesson as every commercial observability platform, just felt most acutely here.

What people get wrong

• Instrumenting everything at full fidelity — unsampled traces, unfiltered logs, and high-cardinality custom metrics drive bills far past expectations; sampling and filtering are cost controls.
• The custom-metric cardinality trap: a single high-cardinality tag (user ID, request ID) can multiply into an enormous custom-metric bill — bound tag cardinality deliberately.
• Assuming buy always beats build — at very large telemetry volumes, self-hosted open source can be far cheaper despite the operational effort; the crossover is real.

Primary source: Datadog documentation