Open Telemetry Bundle Laravel Package

Product Decisions This Supports

• Observability Roadmap: Accelerates adoption of OpenTelemetry (OTel) for distributed tracing, metrics, and logging in Symfony applications, aligning with industry trends toward standardized observability.
• Build vs. Buy: Buy—avoids reinventing instrumentation for HTTP, Doctrine, Redis, Messenger, etc., while allowing customization via interfaces.
• Feature Prioritization:
  • Phase 1: Enable OTel for core Symfony services (HTTP, Doctrine, Redis) to baseline observability.
  • Phase 2: Extend to async/messaging (Messenger, Async) for microservices.
  • Phase 3: Add custom metrics (e.g., business KPIs) via MeterProvider.
• Use Cases:
  • Debugging: Trace slow API endpoints or database queries.
  • Performance: Identify bottlenecks in async workflows (e.g., Messenger consumers).
  • Compliance: Audit requests/errors with structured logs (via LoggerProvider).
  • Cost Optimization: Right-size OTel collectors by filtering irrelevant spans (e.g., DefaultTraceIgnore).

When to Consider This Package

• Adopt if:

  • Your Symfony app (v8.0+) needs standardized observability (tracing/metrics/logs) with minimal boilerplate.
  • You’re using OTLP exporters (e.g., Jaeger, Tempo, Prometheus) and want seamless integration.
  • You need fine-grained control over instrumentation (e.g., disable tracing for /health endpoints).
  • Your team prefers Symfony’s DI system over raw PHP extensions for OTel.

• Look elsewhere if:

  • You’re not on Symfony 8.0+ (requires PHP 8.5+).
  • You need active maintenance (0 stars, last release in 2026—verify fork/upstream health).
  • Your stack relies on non-OTel tools (e.g., New Relic, Datadog agents with custom integrations).
  • You require advanced sampling (e.g., head-based sampling)—this bundle delegates to OTel SDK defaults.
  • You’re using non-standard Symfony setups (e.g., custom kernel, non-standard service containers).

How to Pitch It (Stakeholders)

For Executives:

"This bundle lets us instrument our Symfony app for observability without hiring a specialist—think of it as ‘auto-instrumentation for OpenTelemetry.’ We’ll get end-to-end traces (e.g., API → DB → cache), metrics for performance SLAs, and structured logs for debugging, all while reducing dev overhead. It’s like adding Google Analytics to your backend, but for engineers. Cost: ~1 dev-day to configure; ROI: Faster incident resolution and proactive performance tuning."

For Engineering:

*"This is a Symfony-native wrapper for OpenTelemetry that:

• Auto-instruments HTTP, Doctrine, Redis, Messenger, etc.—just enable in config.yaml.
• Lets us override defaults (e.g., skip tracing for /webhook endpoints) via interfaces.
• Integrates with our OTel collector (OTLP endpoint) out of the box.
• Supports custom metrics/logs if we need to track business-specific events. Tradeoff: Minimal maintenance risk (MIT license, but verify the 2026 release date). Let’s prototype it for our /api endpoints first."*

For DevOps/SRE:

*"This gives us consistent telemetry across all Symfony services, which we can ship to:

• Tempo for traces (e.g., ‘Why did Order #123 fail?’).
• Prometheus for metrics (e.g., ‘DB query latency by endpoint’).
• Loki for logs (structured, correlated with traces). No agent changes needed—just point the OTel collector to your existing backend."*