Logging Bundle Laravel Package

Product Decisions This Supports

• Observability investment: log↔trace correlation vs. doing nothing. The bundle's entire value is writing extra.dd.trace_id / extra.dd.span_id into log records so Datadog can link a log line to the trace that produced it. That is a concrete, measurable support capability — “customer says request X failed” becomes a single click instead of a log grep. This is the decision it most directly informs: do we care enough about MTTR to wire logs to traces?
• Build vs. buy (vs. copy). The scope is three classes, one DI extension, one Monolog processor. In-house cost is roughly a day plus forever-maintenance. The honest framing is not “buy vs. build,” it’s “adopt vs. paste the processor into our own shared bundle.” Decide based on whether you want an external dependency with a single-vendor maintainer for something this small — and note that 2.0.0 makes that dependency now track Monolog majors for you.
• Zero-config rollout across a service fleet. The design deliberately registers the processor only when function_exists('DDTrace\current_context') is true. That means it is safe to install unconditionally in a base service template — no config keys, no env flags, no broken builds where ddtrace isn’t present. This supports the roadmap decision to standardize observability in a shared skeleton rather than per-team opt-in, which is the real cost saving.
• Monolog major-version cutover (new in 2.0.0). 2.0.0 is a breaking change: Monolog 3.x only, with Symfony 7.x support added. This converts a previously single-track “add it to the skeleton” decision into a two-track fleet decision: services on Monolog 2 must stay pinned to 1.2.0, services on Monolog 3 use 2.x. If your shared base template spans both, you now carry two versions of the same three classes — which is precisely the argument for copying the processor into your own bundle and controlling the constraint yourself.
• Platform/framework fit — and a correction to the brief. This is a Symfony bundle, not a Laravel package. For a Laravel estate you cannot composer require it and get behavior; you would lift the processor class and register it in Laravel’s Monolog channel config. The 2.0.0 Monolog 3 cutover actually aligns with modern Laravel (which is on Monolog 3), but it does not change the conclusion: the decision remains “dependency vs. 30-line internal class,” and the answer often flips to internal.
• Upgrade risk on the Symfony/PHP matrix — materially worse after 2.0.0. The package still declares no php constraint, but Monolog 3 silently imposes a PHP 8.1+ floor through its transitive requirement. So the effective minimum PHP moved without the package’s own metadata saying so, and the 1.x→2.x boundary is a hard Monolog-major cliff rather than a semver-compatible bump. Adopting an unpinned package that also gates on Monolog majors shifts validation burden onto you at every fleet upgrade.
• Advisory-gate policy — re-check now. The earlier assessment flagged config.policy.advisories.block=false as a deliberate setting made to make Symfony 7.2 CI resolution satisfiable. A Monolog 3 / Symfony 7 dependency refresh is exactly the kind of change that may let that setting be dropped. Confirm the current state before adoption rather than assuming it persists.
• Contribution model is a product constraint. keboola/logging-bundle is a read-only mirror; all changes must land in keboola/platform-libraries. A decision to adopt implies a decision about whether your team is willing to file upstream PRs into another org’s monorepo. With a breaking major now in play, the odds you need a local fix (e.g. supporting Monolog 2 and 3 simultaneously) go up, and that friction is a real cost.

When to Consider This Package

Consider it when all of these hold:

• You run Symfony with Monolog 3 (for 2.x; Monolog 2 users are limited to 1.2.0), and you use Datadog APM with the ddtrace extension in at least some environments.
• You want trace correlation without per-service configuration and need it to be a no-op in environments lacking the extension.
• You are comfortable depending on a single-vendor, read-only mirror package and can contribute fixes upstream to keboola/platform-libraries.
• You accept the CI-supported range (Symfony 6.4/7.x, Monolog 3, PHP 8.1/8.3) and will re-validate on your own matrix, since no php constraint is declared and the Monolog 3 requirement now imposes an implicit PHP 8.1 floor.
• You can align your Monolog major upgrade and your observability wiring in the same change window, rather than treating them as independent workstreams.

Look elsewhere when:

• You are on Laravel. It is a Symfony bundle; port the processor instead of adopting the dependency.
• You are on Monolog 2 and not ready to move. 2.0.0 offers you nothing; you would be pinning 1.2.0 indefinitely.
• You are not on Datadog. The output shape is Datadog-specific; a generic or OpenTelemetry-based approach serves you better.
• You need more than correlation — sampling, redaction/PII scrubbing, multi-backend fan-out, structured log schemas, retention policy hooks. Those belong in your own Monolog processor/handler stack.
• You need vendor support, SLA, or a healthy ecosystem signal. 1 star, 0 dependents, and a mirror-only repo mean you are the maintainer of last resort — and a breaking major with no migration guide reinforces that.
• Your security/compliance process blocks packages with config.policy.advisories.block=false. That setting was deliberate (it made the Symfony 7.2 CI resolution satisfiable), but it means Composer’s advisory gate is off for this package’s resolution — a policy question worth answering before adoption, not after, and worth re-checking after the dependency refresh in 2.0.0.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small observability utility that attaches trace and span identifiers to every log line, which lets Datadog link a log entry directly to the request trace that produced it. Practically, it shortens the path from “a customer reports a failure” to “here is the exact execution path” — a direct MTTR reduction with effectively zero integration cost and no configuration to manage. It is safe to install fleet-wide because it silently does nothing where Datadog tracing isn’t present, so it cannot break a build or an environment. The new 2.0.0 release adds Symfony 7 support but requires Monolog 3, so it is a natural companion to the Monolog upgrade we are already planning rather than a separate initiative — and services that aren’t ready for Monolog 3 stay on the previous version with no loss of functionality.

To engineering (one paragraph): Three classes. KeboolaLoggingExtension::load() checks function_exists('DDTrace\current_context') and, only then, registers Monolog\DataDogContextProcessor with the monolog.processor tag. The processor writes extra.dd.trace_id and extra.dd.span_id — the exact key names Datadog’s correlation expects, so renaming them silently breaks correlation without failing any test or build. The runtime guard is the whole reason the bundle needs no configuration, and both branches (extension present / absent) are covered by tests via a stubbed DDTrace\current_context(). 2.0.0 is a breaking release: Monolog 3.x only, plus Symfony 7.x support. The release notes describe no change to the processor or key names — the break is dependency-level — so verify your Monolog major before bumping, and expect 1.2.0 to remain the pin anywhere you’re still on Monolog 2. Note also that the package still declares no php constraint: Monolog 3 quietly raises the effective floor to PHP 8.1, which is the kind of implicit requirement that surfaces as a broken build a week later. Two operational notes before you adopt: this is a Symfony bundle, not Laravel — Laravel teams should port the processor into their logging channel config rather than adding the dependency; and the GitHub repo is a read-only mirror, so any fix must go to keboola/platform-libraries under libs/logging-bundle/ with fix(logging-bundle): … commits, or it will be force-pushed away. Validate on your own Symfony/PHP/Monolog matrix.