…emetry#743)

Set the sampling rate in the Datadog exported span if span was sampled with the ProbabilitySampler.

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>

…y#748)

…pen-telemetry#652)

Adding an extension to provide users an easy mechanism to collect metrics for their system.

In PushController before exit, flush the meter by calling tick(), ensuring that all metrics are flushed.

Co-authored-by: alrex <aboten@lightstep.com>

This commit ports the OpenTracing testbed[1] to check that the ot-shim is
working as expected using different frameworks.

Gevent doesn't support context vars yet[2], so those tests are not compatible
with opentelemetry and were not ported.

[1] https://github.com/opentracing/opentracing-python/tree/master/testbed
[2] gevent/gevent#1407

Co-authored-by: Mauricio Vásquez <mauricio@kinvolk.io>
Co-authored-by: alrex <aboten@lightstep.com>

Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

Co-authored-by: Cheng-Lung Sung <clsung@gmail.com>

…n-telemetry#751)

Canonical codes for different types of exceptions

Span attributes extracted from exception

Correct span closing for requests with raised errors (A span wasn't closed due to a RequestException)

Co-authored-by: alrex <aboten@lightstep.com>

…n-telemetry#769)

* Add lzchen to maintainers

Closes open-telemetry#778.

Co-authored-by: alrex <aboten@lightstep.com>

…ame opentelemetry-auto-instrumentation (open-telemetry#741)

The span context is no longer coupled with the tracer itself.
As such, providing a get_current_span method bound to the
trace api module rather than a specific tracer is semantically
correct, and removes a hurdle where someone who wants to retrieve
the current trace would have to create a tracer to do so.

renaming and exporting get_span_in_context to get_current_span,
as the intention of the API is similar, and reduces unneeded
aliasing and duplication.

set_span_in_context is not renamed, as set_current_span would have
implied that the span would then be active in the default context,
which is only true after attaching the resulting context returned
by set_span_in_context. Keeping that name at least implies some
asymmetric behavior from get_current_span.

After discussion in the SIG, we decided to remove the
legacy get_current_span APIs from Tracer and TracerProvider
to reduce long-term confusion of how to idiomatically retrieve
the span.

Co-authored-by: alrex <aboten@lightstep.com>
Co-authored-by: Hector Hernandez <39923391+hectorhdzg@users.noreply.github.com>
Co-authored-by: Leighton Chen <lechen@microsoft.com>
Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>
Co-authored-by: Mauricio Vásquez <mauricio@kinvolk.io>
Co-authored-by: Andrew Xue <aaxue@google.com>
Co-authored-by: Cheng-Lung Sung <clsung@gmail.com>

Initial addition of opentelemetry-proto based protobufs.

Co-authored-by: alrex <alrex.boten@gmail.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

Adding an exporter that supports sending metrics data to cloud monitoring (formerly known as stackdriver).

Co-authored-by: Chris Kleinknecht <libc@google.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

Adding initial boto core implementation.

Co-authored-by: alrex <alrex.boten@gmail.com>

…ider (open-telemetry#791)

Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

eachdist.py did not support the installation of test packages,
(as defined by the extra_requires:test package group). As a
result, test packages were being added to dev-requirements.txt

By having eachdist.py develop install test packages, and moving
develop/test package definitions to the individual instrumentations,
it is easier to determine which packages require which dependencies
for testing purposes, and enables support for existing dependencies
that follow the extra_requires:test pattern.

Co-authored-by: Leighton Chen <lechen@microsoft.com>
Co-authored-by: alrex <aboten@lightstep.com>

opentelemetry-test was not listed as a test dependency in the asgi instrumentation.

Minor cleanup of setup.cfg files. Updated the example app to move configuration from setup.py into setup.cfg as well.

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

adding some troubleshooting tips for users with common failures

…y#804)

Previously cloud monitoring was missing coverage.

As per open-telemetry/opentelemetry-specification#427, we need an interface for users to record errors.

initial implementation

Adding missing documentation for Pyramid and SQLite3

Update the Datadog docs for installation and using propagation.

Enables broader usage of the aggregator, across multiple counter types.

adding an initial starlette instrumentation.

tox does exact match on fields delimited by a dash. Thus,
any instrumentation that includes "instrumentation" in the name
would collide with testing of the "opentelemetry-instrumentation"
package.

Renaming opentelemetry-instrumentation to opentelemetry-instrumentation-base to fix that.

Co-authored-by: Leighton Chen <lechen@microsoft.com>
Co-authored-by: alrex <aboten@lightstep.com>

The lint job raising an error at installation:

ERROR: Could not find a version that satisfies the requirement opentelemetry-ext-asgi==0.10.dev0 (from opentelemetry-instrumentation-starlette==0.10.dev0) (from versions: 0.8b0, 0.9b0)
ERROR: No matching distribution found for opentelemetry-ext-asgi==0.10.dev0 (from opentelemetry-instrumentation-starlette==0.10.dev0)

The opentelemetry-ext-asgi should be installed before depending modules.

…emetry#827)

Co-authored-by: Shawn Brunsting <brunsting@google.com>
Co-authored-by: Chris Kleinknecht <libc@google.com>

…#808)

This commit adds auto-instrumentation for elasticsearch. The
instrumentation has been mostly ported over from OpenTracing
elasticsearch instrumentation.

Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>
Co-authored-by: alrex <aboten@lightstep.com>

Ported from the DataDog instrumentation.

Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>
Co-authored-by: Mauricio Vásquez <mauricio@kinvolk.io>
Co-authored-by: alrex <alrex.boten@gmail.com>

Adding initial cloud trace propagator

Co-authored-by: Aaron Abbott <aaronabbott@google.com>
Co-authored-by: Diego Hurtado <ocelotl@users.noreply.github.com>

Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

…ry#837)

…etry#859)

entry point for the mysql instrumentation pointed to pymysql instrumentation which caused loading of the instrumentation to fail since it does not exist.

Co-authored-by: alrex <aboten@lightstep.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

…r are overridden (open-telemetry#856)

…han a string (open-telemetry#866)

…y#873)

In the last release, eachdist missed updating dependencies
on ext-datadog, which has a slightly different, but valid,
way of specifying the version (omitting some spaces).

Making the eachdist regex more lenient to catch other valid
version specifications.

Also modifying the ext-datadog dependency specification to
match the format of all the others.

Co-authored-by: Leighton Chen <lechen@microsoft.com>

…ango (open-telemetry#872)

Fixes open-telemetry#832. By having tracer creation occur on demand, late tracer provider configuration will be honored. 

This resolves issues with instrumentation occurring before tracer providers are set by the application developer, which would result in the no-op tracer used for the lifetime of the instrumentation.

Co-authored-by: alrex <aboten@lightstep.com>
Co-authored-by: Leighton Chen <lechen@microsoft.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

…ry#891)

Co-authored-by: Leighton Chen <lechen@microsoft.com>
Co-authored-by: Yusuke Tsutsumi <yusuke@tsutsumi.io>

…t into a string (open-telemetry#865)

Could not serialize attribute aws.region to tag when exporting via jaeger
Serialize tuple type values by coercing them into a string, since Jaeger does not
support tuple types.

As discussed in the SIG, toumorokoshi is stepping down
as a maintainer.

Co-authored-by: alrex <aboten@lightstep.com>

Co-authored-by: Leighton Chen <lechen@microsoft.com>

…etry#896)

Co-authored-by: Leighton Chen <lechen@microsoft.com>