Product Decisions This Supports

Observability as a Core Feature: Enables automated distributed tracing for Symfony services, reducing manual instrumentation effort by 90%+ for method-level spans. Aligns with modern SRE practices where observability is treated as a first-class citizen in the product lifecycle.
Developer Productivity: Eliminates boilerplate for tracing critical paths (e.g., payment processing, order fulfillment) while maintaining flexibility for edge cases. Developers can focus on business logic without context-switching to observability concerns.
Microservices & API Observability: Critical for Symfony-based APIs or microservices where cross-service latency is a pain point. Provides end-to-end visibility into service interactions without requiring changes to downstream systems.
Compliance & Auditing: Supports regulatory requirements (e.g., GDPR, PCI-DSS) by enabling traceable audit logs for sensitive operations (e.g., AuthService::login). The #[Arguments(exclude: [...])] feature helps mask PII while preserving traceability.
Tech Stack Modernization: Justifies adoption of PHP 8.2+ and Symfony 6+ by tying it to observability gains. Can be pitched as part of a broader "platform upgrade" initiative.
Cost Optimization: Avoids licensing fees for proprietary APM tools (e.g., New Relic, Datadog) while delivering comparable functionality for Symfony services. OpenTelemetry’s vendor-neutral format enables future tooling flexibility.
Performance Debugging: Directly addresses latency spikes in high-throughput systems (e.g., e-commerce checkouts, real-time analytics) by surfacing slow methods in real time. Integrates with OpenTelemetry’s flame graphs for root-cause analysis.

When to Consider This Package

Adopt if:
- Your team is instrumenting <20% of Symfony services manually and wants to scale observability without hiring dedicated SREs.
- You’re migrating to microservices and need to debug cross-service latency (e.g., Symfony → Kafka → Node.js).
- Your CI/CD pipeline includes OpenTelemetry (e.g., testing with OTEL_TRACES_EXPORTER=jaeger), and you want to mirror production tracing in staging.
- You’re using Symfony Messenger or HTTP clients and need to correlate messages/requests with service methods.
- Your error rate is high in production, and you lack visibility into which service methods fail silently (e.g., timeouts, retries).
- You’re evaluating OpenTelemetry as a standard and want to start with zero-code instrumentation before adding custom spans.
Look elsewhere if:
- You need HTTP request/response tracing (use opentelemetry/php-instrumentation or symfony/var-dumper integrations).
- Your app relies on legacy Symfony (5.x) or PHP <8.2, making the extension dependency prohibitive.
- You require database query tracing (combine with opentelemetry/instrumentation-pdo or doctrine/doctrine-bundle integrations).
- Your observability needs extend to frontend frameworks (e.g., React, Vue) or mobile apps (use OpenTelemetry’s native SDKs).
- You’re already using a proprietary APM tool with built-in Symfony support (e.g., Datadog APM, AppDynamics) and lack the resources to maintain OpenTelemetry.
- Your services are highly dynamic (e.g., generated via reflection or DI containers), making attribute-based instrumentation impractical.

How to Pitch It (Stakeholders)

For Executives (CTO, VP Engineering)

"This package lets us automatically trace every critical Symfony service method with a single line of code—no manual instrumentation, no vendor lock-in. By adopting OpenTelemetry’s standard, we can integrate with any observability tool (Jaeger, Datadog, AWS X-Ray) without switching costs. For our [microservices/APIs], this will cut debugging time for performance issues by 50%+, directly impacting MTTR and customer experience. It’s a low-risk, high-reward move to future-proof our observability stack while reducing reliance on proprietary tools."

Key Metrics to Track:

Reduction in mean time to resolve (MTTR) for backend issues.
Increase in service-level objective (SLO) compliance (e.g., p99 latency).
Cost savings from avoiding APM tool licenses.

For Engineering Leaders (Tech Leads, Architects)

"This solves the ‘tracing tax’ in Symfony apps. Instead of manually wrapping every service method in beginSpan()/endSpan(), we add #[Traceable] to classes, and OpenTelemetry’s PHP extension handles the rest. It’s lightweight, integrates with our existing OTel setup, and works seamlessly with tools like Jaeger. Perfect for teams that want observability without the overhead of custom code—especially for debugging slow endpoints or understanding how services interact across our microservices."

Engineering Benefits:

Reduces cognitive load: No need to remember to instrument critical methods.
Consistent formatting: Spans follow a standard naming convention (ClassName::methodName).
Selective instrumentation: Exclude methods/arguments (e.g., healthCheck, password) via attributes.
Future-proof: Aligns with OpenTelemetry’s roadmap (e.g., W3C Trace Context).

Risks Mitigated:

Dependency on ext-opentelemetry is offset by its zero-code value prop.
Low adoption risk: Start with 1–2 critical services (e.g., OrderService, AuthService).

For Developers (Backend Engineers)

"No more boilerplate for tracing! Just add #[Traceable] to your service classes, and OpenTelemetry auto-instruments method calls. Works out-of-the-box with Symfony’s DI container—no configuration headaches. Great for debugging slow endpoints or understanding how your services talk to each other. Example:

#[Traceable(exclude: ['healthCheck'])]
class PaymentService {
    public function process(string $token, float $amount): void {
        // Span "PaymentService::process" is created automatically!
        // Attributes: {token: "redacted", amount: 99.99}
    }
}

Why It’s Better Than Manual Tracing:

No context management: No need to pass Span objects between methods.
Consistent naming: Spans are named Class::method by default.
Exclude sensitive data: Hide arguments like password or apiKey with #[Arguments(exclude: [...])].
Works with existing tools: Integrates with Jaeger, Zipkin, or your OTel collector."

Getting Started:

Install the package:

composer require eerzho/opentelemetry-auto-class-symfony

Add to config/bundles.php:

OpenTelemetry\Contrib\Instrumentation\Class\Symfony\TraceableBundle::class => true,

Annotate a service:
```
#[Traceable]
class MyService {}
```
Verify in Jaeger: Traces should appear for all public methods!

For DevOps/SRE

*"This package automates OpenTelemetry instrumentation for Symfony services, reducing the noise in our traces while surfacing actionable insights. By leveraging #[Traceable], we can:

Correlate service methods with HTTP requests, database queries, or messages (via OTel context propagation).
Exclude boilerplate (e.g., healthCheck, getVersion) to keep traces clean.
Standardize span naming across teams, making it easier to query traces in tools like Jaeger.

Integration Notes:

Requires ext-opentelemetry (PECL or Docker). Test compatibility with your PHP version.
Works alongside existing OTel instrumentation (e.g., HTTP, Doctrine).
Disable globally with OTEL_PHP_DISABLED_INSTRUMENTATIONS=class if needed.

Monitoring Impact:

Expect a small increase in trace volume (one span per public method call).
Use OTel’s sampler to control overhead (e.g., AlwaysOnSampler for staging, ParentBased for production)."

Opentelemetry Auto Class Symfony Laravel Package