Christian Neumüller

How about filtering for requests that exceed a certain size? Or requests without body (length=0)?

@lmolkova Probably true, but the same could be said for http.status_code: "If you have a problem with status 500 requests, you'd see an examplar of it on metrics for status...

> HTTP clients don't necessarily decompress and instrumentation doesn't really know when decompression happens (e.g. when stream is read which can happen after the span ends) > So one thing...

> It's not clear to me whether scheduledDelayMillis is supposed to be time in between exports of chunks of size maxExportBatchSize, or if it's the delay between processing the queue...

See the Python solution, which I think is rather elegant: https://github.com/open-telemetry/opentelemetry-python/pull/181 (updated in https://github.com/open-telemetry/opentelemetry-python/pull/395 for OTEP 66). You introduce a conventional context variable "suppres_instrumentation" that all instrumentations check and the...

That would also work, but personally I prefer the more explicit no-magic approach here. Also, the instrumentation overhead can be further reduced if the instrumentation checks manually and shortcuts, instead...

@toumorokoshi @codeboten FYI

@pauldraper The tracer will stop "managing" context but it will still need to access the context when creating a new span, see #527

> I haven't seen examples of these expensive computations yet You have to look at everything the instrumentation does for each span. E.g. the sum of all the things that...

@toumorokoshi Your link is actually perfect to illustrate why we additionally could use the "surpress_instrumentation" context variable: In https://github.com/open-telemetry/opentelemetry-python/blob/v0.6.0/ext/opentelemetry-ext-wsgi/src/opentelemetry/ext/wsgi/__init__.py#L121, attributes are collected to be passed to start_span (so the sampler...