Log Bundle Laravel Package

Product Decisions This Supports

• Observability roadmap: standardize or fragment. This bundle encodes one opinionated answer to "how do we log and trace across services" — normalized log context (app name + tokens), automatic logger injection, and token propagation on both inbound HTTP and outbound calls (Guzzle middleware and Symfony HttpClient decorator). Deciding to adopt it is effectively a decision to standardize rather than let each team hand-roll correlation IDs.
• Build vs. buy vs. vendor. For a Symfony shop, this is a "reuse an internal pattern library" decision more than an OSS dependency decision. It saves the cost of building token propagation, exception-level remapping, and a filtered Slack handler yourself — worth quantifying in engineering days against the cost of owning a fork.
• MTTR / incident response as a product metric. Cross-service request tracing from app to app is the enabling capability for reducing mean-time-to-resolution and for answering "which request failed where." If MTTR or on-call pain is on the roadmap, this is a concrete lever.
• Log cost and noise management. The exception log-level processor (e.g., downgrading NotFoundHttpException) and the custom Slack handler with filters are cost/noise decisions: fewer pages, less log volume, less alert fatigue.
• Long-running process observability. Explicit support for process-level tracing in long-running workers is a meaningful decision input if the roadmap includes queue workers, consumers, or daemons — a common blind spot in logging stacks.
• Vendor/exit risk register. 0 stars, 0 dependents, single-org provenance. Adopting means accepting a maintenance-risk line item, or planning an internal fork from day one.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony (4+, with a documented legacy path for <4) — this is a Symfony bundle, not a Laravel package; there is no service provider or Laravel-native integration here. For Laravel, treat this as a reference design, not an installable dependency.
• You operate a multi-service or app-to-app call graph where a shared correlation/tracing token standard has real value — the core payoff is TokenCollection plus automatic global/process token wiring, which does nothing for a single monolith.
• You are already on Monolog and can accept its handlers/processors model, including the opinionated Slack message format.
• You have an owner willing to vendor or fork the code, because upstream is a single organization with no visible community or dependents.
• You want a fast path to a working tracing convention rather than a spec.

Look elsewhere when:

• Framework mismatch. Laravel or framework-agnostic stacks: use Laravel's logging channels plus a correlation-ID middleware, or a dedicated tracing package.
• You need vendor-backed standards. If OpenTelemetry, W3C Trace Context, or trace propagation across polyglot services (Go, Node, Python) is the goal, this bundle's bespoke token model will become a translation layer. Prefer OTel-native instrumentation.
• You need an SLA or security review with upstream responsiveness. Zero dependents and zero community mean you are the maintainer.
• Single-service or small surface area. The overhead of bundle config, handlers, and middleware outweighs the benefit.
• You need mature ecosystem signals (adoption, issue throughput, third-party integrations). The dependency score and opportunity signal here are weak; treat it as a code sample to evaluate, not a community package to trust.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small infrastructure component that standardizes how our Symfony services log and how a request can be traced from one service to the next. The business value is faster incident diagnosis and less alert noise — measurable in MTTR and on-call load — at near-zero licensing cost. The trade-off is support risk: it comes from a single organization with no visible external adoption, so we should treat adoption as an internal fork we own, budget a small maintenance allowance, and avoid it if our direction is OpenTelemetry or a polyglot service fleet.

For engineering leadership: It bundles four things we would otherwise build separately — automatic logger injection, a TokenCollection for request tracing, a processor to re-level noisy exceptions like NotFoundHttpException, and a filtered Slack handler — plus outbound propagation via Guzzle middleware and a Symfony HttpClient decorator. That is roughly a sprint of glue code we don't write. The catch: it is Symfony-only (irrelevant to our Laravel services), its tracing token model is proprietary rather than W3C/OTel, and the repo has no community footprint, so we must pin the version, fork it into our own namespace, and own upgrades.

For the engineering team (adoption checklist): Verify it installs and boots against our Symfony version; confirm the token propagation actually survives our HTTP clients and queue workers; audit the Slack handler's filters and message contents against our alerting policy; and confirm the exception level mappings don't silently bury errors we page on. If any of those fail, take the pattern and reimplement the ~200 lines that matter.