Otel Bundle Laravel Package

Product Decisions This Supports

• Observability Roadmap: Accelerates adoption of distributed tracing and log correlation for Symfony applications, aligning with modern SRE/DevOps practices. Enables end-to-end request tracking (HTTP → DB → Messaging → External APIs) without custom instrumentation.
• Build vs. Buy: Buy—avoids reinventing OpenTelemetry integration for Symfony, reducing dev effort by 60–80% for core use cases (HTTP, Doctrine, Messenger). Custom extensions (e.g., RabbitMQ consumers) require minimal code.
• Key Use Cases:
  • Debugging latency: Identify slow HTTP calls, DB queries, or async jobs (e.g., Messenger) in production.
  • Log-trace correlation: Link logs to traces via trace_id/span_id for context-rich debugging (e.g., "Why did this user’s checkout fail?").
  • Microservices observability: Standardize tracing across services using OTLP (OpenTelemetry Protocol) for compatibility with Jaeger, Zipkin, or Honeycomb.
  • Compliance/auditing: Track tenant/user IDs in spans for security/regulatory needs (e.g., GDPR, PCI).
• Tech Debt Reduction: Replaces ad-hoc logging (e.g., monolog + stackdriver) with structured telemetry, improving signal-to-noise ratio.
• Future-Proofing: Supports Symfony 8.x and OpenTelemetry’s evolving standards, reducing migration risk.

When to Consider This Package

• Adopt if:

  • Your Symfony app (7.x/8.x) needs distributed tracing with minimal setup (HTTP, DB, Messenger, logs).
  • You’re using Doctrine, Symfony Messenger, or HTTP clients (e.g., API calls to third parties).
  • Your observability stack already supports OTLP (e.g., OpenTelemetry Collector, Jaeger, Datadog, New Relic).
  • You want log-trace correlation without manual trace_id injection.
  • Your team lacks OpenTelemetry expertise but needs production-grade instrumentation.

• Look elsewhere if:

  • You’re on Symfony 6.4 (use 0.0.6 or upgrade).
  • You need custom metrics (e.g., business KPIs) beyond tracing—consider Prometheus or OpenTelemetry Metrics.
  • Your backend isn’t PHP/Symfony (e.g., Node.js, Go).
  • You’re already using a Symfony-specific APM (e.g., Blackfire, Sentry) with deep integration.
  • You require advanced sampling (e.g., head-based) or resource detection—configure via OpenTelemetry Collector instead.
  • Your team prefers manual instrumentation for granular control (e.g., per-service tracing).

How to Pitch It (Stakeholders)

For Executives/Business Leaders:

*"This package lets us see inside our Symfony app in real time—like X-ray vision for debugging. Imagine knowing exactly why a user’s checkout failed: was it a slow database query? A third-party API timeout? Or a stuck background job? With zero code changes for 80% of use cases, we can:

• Reduce MTTR (mean time to resolve issues) by 50% with correlated logs and traces.
• Cut observability costs by standardizing on OpenTelemetry (free/cheap tools like Jaeger or Datadog).
• Future-proof our stack for microservices and compliance needs (e.g., tracking tenant IDs in all spans). It’s a low-risk, high-reward investment—like adding seatbelts to a car you already own."*

For Engineering Teams:

*"This Symfony OpenTelemetry bundle gives us automatic instrumentation for:

• HTTP requests (incoming/outgoing), Doctrine queries, Messenger jobs, and console commands.
• Log-trace correlation: Every log line gets a trace_id to stitch together the full request lifecycle.
• Custom attributes: Add business context (e.g., tenant.id, user.id) to spans with minimal effort.

Why use it? ✅ No reinventing the wheel: Handles edge cases (e.g., nested spans, error propagation) we’d miss. ✅ Symfony-native: Works with HttpClient, Doctrine, Messenger out of the box. ✅ OTLP-compatible: Send data to Jaeger, Datadog, or New Relic without vendor lock-in. ✅ Extensible: Need to trace RabbitMQ consumers? It’s a 5-line interface to implement.

Trade-offs:

• Requires OTLP endpoint (e.g., OpenTelemetry Collector) to export data.
• Optional instrumentation (e.g., HTTP clients) needs YAML config.

Next steps:

1. Pilot: Instrument a non-critical service (e.g., /health endpoint).
2. Validate: Check if traces/logs are useful for debugging real issues.
3. Expand: Roll out to core services, then add custom attributes (e.g., user.id)."*

For DevOps/SRE:

*"This bundle standardizes telemetry across Symfony apps, reducing tooling sprawl. Key wins:

• Single pane of glass: Correlate logs, traces, and metrics in Jaeger/Datadog.
• Cost efficiency: OTLP is cheaper than proprietary APMs for high-cardinality data.
• Simplified onboarding: No need to teach teams custom tracing libraries—just drop this bundle and configure the exporter.

Ask:

• Do we have an OpenTelemetry Collector to receive OTLP data? (If not, we’ll need to deploy one.)
• Should we sample traces (e.g., 10% of requests) to reduce volume?"*