Search before asking

• I had searched in the issues and found no similar issues.

Apache SkyWalking Component

OAP server (apache/skywalking)

What happened

1. Set SW_PLUGIN_HTTP_INCLUDE_HTTP_HEADERS=x-request-id,x-correlation-id in environment.
2. OAP-Server Set `SW_SEARCHABLE_TAG_KEYS=http.method,http.he

Requirement - what kind of business use case are you trying to solve?

Actual the windows executables (jaeger-agent.exe, jaeger-collector.exe, ...) don't have a version set. It is hard to identify the current used version and check if the actual used version is outdated.

Probl

PHP looks like a less mature OpenTelemetry implementation, but it exists: https://github.com/open-telemetry/opentelemetry-php#installation

If possible, additional instrumentation tutorial for these popular frameworks would be helpful:

1. Zend Framework 3
2. WordPress
3. Silverstripe
4. [Symfony]

Describe the bug

The query-frontend logs some details about the query when it completes, for example:

level=info ts=2021-11-25T11:32:38.59660534Z caller=handler.go:96 tenant=1 method=GET traceID=57060d6b589d1903 url="/tempo/api/search?x-dbg-exhaustive=true&limit=20" duration=7.079269575s response_size=96 status=200

If you cancel the request before it completes, this log does

Bug Report

The current OTLP exporter below flattens nested array in Span.Atttributes (Activity.Tags in .NET) into a list of key value pairs with the same key for all these kv pairs. For example, activity.SetTag('arraykey', new int [] {1, 2, 3} is converted to JSON like list {{'arraykey': 1}, {'arraykey': 2}, {'arraykey': 3}} in OTLP. This could cause problem if the OTLP listener would lik

There was an issue in opentracing to add a scope manager, but it doesn't look like it was ever implemented opentracing/opentracing-javascript#112

What is our action item here? Should we just document on the shim that there is no scope manager so we have no shim for it?

_Originally posted by @dyladan in https://github.com/open-telemetry/opentelemetry-specification/is

It seems to me that UTC is selected for on the wire representation of time as well as in the database (jaegertracing/jaeger#712), which sort of makes sense, at least with a somewhat naive handling of timezones. However, I think that the Jaeger UI should support displaying times in the timezone local to the user, i.e. of the browser as to reduce the mental load when viewing

please look at images

like this

@thegryfon noticed that in community axios implementations, some leak contexts and you wouldn't necessarily know until a second root trace is attempted.

here's an example scenario I think tests could cover:

there is no parent trace in scope
create a client request
create a second client request
verify that both client requests are root spans

Is your feature request related to a problem? Please describe.

The .. module has a conditional dependency on the parseurl library. This library is not an agent dependency. However, if parseurl is present then the agent will use it instead of it's own home grown URL parsing.

We've had users report that this conditional `re