Datadog Symfony Laravel Package

Product Decisions This Supports

• Observability strategy: build vs. buy. This package is the integration glue between the application and Datadog (metrics, events, logs via DogStatsD/agent). Adopting it means your engineering investment goes into instrumentation conventions (what to measure, naming, tag taxonomy) rather than transport plumbing — a strong argument for buying Datadog and building only the domain-specific metrics layer on top.
• Feature-level telemetry for roadmap bets. Once wired in, product teams can emit business metrics (signup funnel steps, checkout latency, feature-flag cohorts) alongside infra metrics. That turns release instrumentation into a product-discovery input, not just an ops afterthought.
• Multi-tenant / multi-environment routing (new in 1.0.0). Named clients with independent DSNs let one codebase send telemetry to different Datadog accounts or namespaces — e.g. per-region, per-brand, per-tenant, or staging vs. production isolation. This unlocks enterprise/B2B SKUs that require customer-segregated telemetry, and makes "no-op"/mock clients a first-class supported configuration for local dev and CI.
• Compliance and data-residency decisions. Because the DSN is now configurable per client, you can route EU-resident traffic to an EU endpoint and keep other traffic elsewhere — a roadmap-unblocking capability for expansion into regulated markets.
• Cost governance. A null:// client and per-client namespaces give you a lever to silence non-critical environments, which directly controls Datadog ingest spend as you scale environments and services.
• Platform upgrade timing. Symfony 7.0 support means this package no longer pins your framework upgrade path — relevant to any roadmap item blocked on "we can't upgrade the stack yet."

When to Consider This Package

Consider adoption when:

• Datadog is already (or is about to become) your observability vendor, and you are on a Symfony 7 / modern PHP stack — 1.0.0 explicitly covers this, so no version-skew excuse remains.
• You need more than one telemetry destination from a single application: multi-tenant SaaS, multi-brand, regional isolation, or separate prod/staging accounts. This is the headline reason to take 1.0.0 over older releases.
• You want environment parity without code branching — mock://, null://, and real DSNs as swappable configuration keeps instrumentation code identical from local dev through production.
• You want configuration-driven instrumentation (YAML/env) rather than scattering client construction and tagging logic through application code.
• Your team is small enough that a maintained glue layer beats a bespoke DogStatsD wrapper you'd have to own, test, and keep current with framework upgrades.

Look elsewhere when:

• You are not on Datadog (or are standardizing on OpenTelemetry / vendor-neutral instrumentation). Prefer an OTel-native path; this package is Datadog-shaped and would create lock-in at the transport layer.
• You need tracing/APM spans rather than metrics, events, and logs — verify coverage explicitly before committing; DogStatsD-style integrations typically don't replace a real tracing SDK.
• You require a vendor SLA, paid support, or a named maintainer on retainer. A community bundle with a 1.0.0 milestone and a small changelog is a dependency-health risk you must price in.
• You only need a single destination and a handful of counters — a 30-line wrapper may be cheaper to own than a dependency, especially if you'd be the one filing the issues.
• Your platform is Laravel-first with no Symfony bundle usage; confirm the service-provider/config integration actually matches how you bootstrap, rather than assuming from the "Laravel/PHP" framing.

Adoption gate before committing: the changelog is terse and there is no migration note. Treat 1.0.0 as a major-version boundary: named-client configuration is a new config shape, and the default client's behavior under the new DSN model must be verified. Require a spike that (a) proves the existing single-client config still works or documents the migration, (b) exercises two clients plus null:// and mock:// simultaneously, and (c) confirms tag/namespace precedence when clients overlap.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can adopt this package as our standard, low-effort bridge between the application and Datadog, and the new 1.0.0 release is the version that makes it viable for us — it supports Symfony 7, so it doesn't block our platform upgrade, and it adds multi-client, multi-endpoint configuration. That last part is a business capability, not a technical nicety: it lets us route telemetry per tenant, per region, or per brand from one codebase, which is a prerequisite for enterprise deals demanding segregated data and for EU data-residency commitments. It also gives us a supported "off switch" for non-production environments, which is a direct lever on observability spend. Cost is a community dependency we must health-check, not a licence fee. Recommendation: fund a short timeboxed spike to validate the 1.0.0 configuration model, then standardize on it for new services.

For engineering leads: 1.0.0 is a framework-compatibility and configuration-model release, not an API redesign. Two things to plan for: (1) Symfony 7.0 support removes the upgrade blocker for teams currently pinned — this unblocks the platform roadmap item. (2) Multiple clients with per-client DSNs moves destination, namespace, and tags into configuration, with null://null and mock://mock as first-class clients. That means local dev and CI can run with instrumentation intact but inert, and we stop writing environment conditionals around telemetry. The risk is documentation debt: the changelog is two lines, so treat this as a semver-major review. Assign an owner to write and commit our internal migration/usage note — default client DSN semantics, tag precedence across clients, and failure behavior when a DSN is unreachable. Validate that a misconfigured or unreachable client degrades gracefully and never blocks a request path; that non-functional requirement matters more than any feature listed here. Once that note exists, this becomes a low-risk default for new services and a cheap retrofit for existing ones.