open-telemetry/opentelemetry-php

The environment variables OTEL_ATTRIBUTE_COUNT_LIMIT and OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT are declared in SDK\Common\Configuration (Variables, ValueTypes, Defaults) but never read anywhere: the environment-driven tracer provider does not build SpanLimits from them, so cross-signal attribute count/value-length limits are never applied. Steps to reproduce OTEL_PHP_AUTOLOAD_ENABLED=true OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT=5 $span = Globals::tracerProvider() ->getTracer('test') ->spanBuilder('environment.attribute.value.length') ->startSpan(); $span->setAttribute( 'test.attribute', '1234567890', ); $span->end(); What is the expected behavior? test.attribute = 12345 What is the actual behavior? test.attribute = 1234567890 Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

MeterProviderFactory::createExemplarFilter() matches all, with_sampled_trace, none instead of the specification's always_on, trace_based, always_off. A spec-compliant value hits the default branch, logs "Unknown exemplar filter", and silently results in no exemplars being captured. Steps to reproduce OTEL_PHP_AUTOLOAD_ENABLED=true OTEL_METRICS_EXEMPLAR_FILTER=always_on Globals::meterProvider() ->getMeter('test') ->createCounter('no-span.counter') ->add(1); What is the expected behavior? Metric contains exemplar. What is the actual behavior? Metric does not contain exemplar. Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Package open-telemetry/opentelemetry-auto-symfony 1.4.0 (latest release) Environment Symfony 5.4.45, PHP 8.2, php-fpm open-telemetry/sdk 1.15.0, open-telemetry/api 1.10.0, ext-opentelemetry Exporter: OTLP http/protobuf → Grafana Alloy → Tempo What happens When a request fails with a 500 raised from a kernel.view listener, one HTTP request is exported as two error spans in two different traces, and neither is complete: span kind name http.route http.response.status_code events A SERVER DELETE absent absent exception B INTERNAL DELETE api_customer_records_delete_item present 500 none The two spans carry different trace_ids. Counts match failures 1:1 — over 24h on two clusters: 2 failing requests produced 2 A-spans and 2 B-spans; 1 failing request produced 1 and 1. Successful requests are unaffected: a single SERVER span, correctly named {method} {route}. Why it matters Span-derived RED metrics (traces_spanmetrics_calls_total) bucket every 5xx under the bare HTTP meth

The collector now has a mysqlreceiver that adds trace parents to query logs. The trace parent is propagated to MySQL through a user variable @traceparent. Similar to SqlCommenter, but instead of a comment, the library would need to run a SET @traceparent={trace}; before the intercepted query. The opentelemetry-auto-pdo instrumentation could handle the propagation, or a new package could be introduced that'd handle it, similar to how it was done for the SqlCommenter. It might also need some configuration/ENV variables to toggle the propagation. What do you guys think? What would be the preferred approach?

Otlp-Profiling is now in alpha, and we'd like to see SDKs implement support for it, especially for things that the opentelemetry-ebpf-profiler cannot profile or only with very high overhead, such as heap profiling data. Bonus for supporting process context and thread context when they're ready. The profiling working group would welcome questions or input, and feel free to join the fortnightly call. All information about the call is at the top of our running meeting notes.