This will remove the main crate's dependency on Jaeger.

See the cargo workspace docs for more info on how we can accomplish this.

This is a tracking issue for the requirements outlined in the beta release document: https://docs.google.com/document/d/1eviggoIguOS89dgKL-8ntUOCfPP6FLWAoQkGoBDsld0/edit#

Traces

• Stable API of every spec'd feature
• SDK Implementation of every spec'd feature
• Basic tracing
• Named tracers
• Tracers use OTEP 66 Context mechanism - This is an implementation detail and does not affect the API

Metrics

• Documentation
• Examples
• Stable API of every spec'd feature
• SDK Implementation of every spec'd feature
• Basic SDK
• Add observer open-telemetry/opentelemetry-specification#430
• Remove gauge open-telemetry/opentelemetry-specification#430
• Push controller
• Pull controller

Resources

• Stable API of every spec'd feature #789
• SDK Implementation of every spec'd feature

Context Propagation

• Stable API of every spec'd feature #741
• Basic context mechanism #769
• Global Propagators API #777 #797
• Global Context API (get and set active context) #792
• SDK Implementation of every spec'd feature
• Basic context mechanism #769
• Global Propagators #777

Exporters

• OpenTelemetry Native - Collector Exporter
• gRPC support
• Prometheus
• Jaeger
• Zipkin

Integrations

• HTTP
• gRPC
• SQL

Examples

• Manual tracing hello world example
• HTTP client/server using an instrumented framework
• gRPC client/server

Because of the API/SDK split there are a considerable amount of imports in order to use the types in this crate. e.g. https://github.com/open-telemetry/opentelemetry-rust/blob/master/examples/basic.rs#L1-L5

For ergonomic reasons, we could consider adding a prelude that could include the core API traits

See open-telemetry/opentelemetry-go#430 for context.

See open-telemetry/oteps#66 for context

I'm not sure what this would look like: maybe returning a SpanBuilder from start?

@jtescher thoughts on updating the authors to point to something generic, like "OpenTelemetry authors"? Not sure if there's a corresponding email.

This might take some experimentation to get right ergonomically.

Often span IDs between applications are encoded into base64, currently you need to use an external crate i.e. https://crates.io/crates/base64 it would be more user friendly

Currently spans are stored in a thread local span stack, and either manually added and removed via mark_span_as_active / mark_span_as_inactive or for the scope of a given closure by using with_span.

This has certain drawbacks: spans marked as active and not later marked as inactive will not be dropped, marking as inactive is unexpected as it is not part of the spec, etc.

We should investigate if there are more reliable / intuitive / ergonomic ways of coordinating active span information between components. E.g. web framework middleware needing to set the active span for use later in the application.

A stdout exporter (or something that can exporter to a Writer can be really valuable, especially for dev purposes.

The go stdout trace exporter might be useful inspiration.

As @MikeGoldsmith mentioned it would be useful to have a handle that can be awaited or blocked on for batch exporters to ensure that all spans have been exported before applications stop.

Jaeger exporter serialises the trace id in 2 64bit chunks. Unfortunately when exporting links the high and low chunks are in reverse order so downstream systems receiving the events cannot construct correct links to the correlated traces.

#117 fixes this.

This is an amazing project and I am attempting to use it in conjunction with the tracing crate. I have posted my initialization code below. I am getting traces to my collector for things that are running in tokio outside of Actix but the actix-web handlers don't work. My best guess after digging through the code is the problem is due to the use of the blocking reqwest client. For reference this is how I am instrumenting my actix-web handlers

#[tracing::instrument(skip(app))]
#[get("/health")]
pub async fn health(app: Data<Application>) -> Result<HttpResponse, ApplicationError> {

thread 'tokio-runtime-worker' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.', /home/glade/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.20/src/runtime/enter.rs:38:5

use opentelemetry::{global, sdk, api::Provider};
use tracing_subscriber::layer::SubscriberExt;
use tracing_opentelemetry::OpenTelemetryLayer;

pub fn init_tracer(collector_endpoint: &str, collector_username: &str, collector_password: &str) -> std::io::Result<()> {
    let exporter: opentelemetry_jaeger::Exporter = opentelemetry_jaeger::Exporter::builder()
        .with_collector_endpoint(collector_endpoint)
        .with_collector_username(collector_username)
        .with_collector_password(collector_password)
        .with_process(opentelemetry_jaeger::Process {
            service_name: "service".to_string(),
            tags: vec![opentelemetry::api::core::KeyValue::new("environment", "dev")],
        })
        .init()
        .map_err(|e| std::io::Error::new(std::io::ErrorKind::Other, e))?;

    let provider = sdk::Provider::builder()
        .with_simple_exporter(exporter)
        .with_config(sdk::Config {
            default_sampler: Box::new(sdk::Sampler::Always),
            ..Default::default()
        })
        .build();


    global::set_provider(provider);
    let tracer = global::trace_provider().get_tracer("service");
    let telemetry = OpenTelemetryLayer::with_tracer(tracer);
    let subscriber = tracing_subscriber::Registry::default().with(telemetry);

    tracing::subscriber::set_global_default(subscriber).expect("Could not set global subscriber");

    tracing::trace_span!("tracing_startup");

    Ok(())
}

Hey, I'm loving the direction this is going, I think it's really going to help me with my microservices backend written in tonic. I've already got my individual services reporting to Jaeger, now I'm trying to get context propagation working. tonic exposes a trace_fn that gives you a http::header::HeaderMap. I'm trying to use a B3Propagator to extract the context from the HeaderMap, but Carrier is only implemented for HashMap with &'static str as the key.
Could you make an implementation of Carrier for http::header::HeaderMap please? Because of Rust's rules around implementations, I can't make an implementation of a foreign trait on a foreign type.
Also in general, it seems like Carrier shouldn't be using &'static str, but should instead just be using &str. I can take a stab at a pull request if you like.

Note that async may not work yet, per #15 (comment)

We should probably spike on this in a PR to see the implications on semantics, implementation, etc.

Currently the span exporter infrastructure is bypassed because of rustracing_jaeger's implementation which reports spans on drop by sending them over a crossbeam-channel.

We should consider switching to use the thrift crate directly and generate a client as that would provide the majority of the implementation that the exporter requires. This could look very similar to the go jaeger exporter implementation.

This could be a separate crate as suggested in #4.

Per the spec.

Current MetricOptions implementation does not work for with_monotonic. The issue is the options do not know which instrument they are being created for.

We could consider moving to returning builders instead of accepting all options here?

This propagator is multi-purpose, i.e., valuable for use cases other than HTTP.

See also open-telemetry/opentelemetry-go#355.

Issue title is self explanatory when I have my jaeger service in docker compose I should be able to use the service name as the URL for the tracer_endpoint

Currently batch exporters must go through a blocking interface, they should be able to export spans using entirely async interfaces.

Add the following to README:

• Current state of project
• Active working targets
• Milestones with estimated release schedule

It would be great to have a set of benchmarks that we can reference as we make changes so we are aware of performance advancements and regressions.

Per discussion in the 12/17/2019 SIG meeting.

(This is just a placeholder issue to track adding @MikeGoldsmith to the GitHub team, since there should be no PR necessary.)

This will remove the main crate's dependency on Prometheus.

See the cargo workspace docs for more info on how we can accomplish this.

I'd like to be able to serialise and deserialise the public SpanData [1]. Since all of its fields are public I could do that manually or even use the magic "remote derive" feature of serde [2]. However, from a safety and usability perspective adding the standard #[derive(Serialize, Deserialize)] to SpanData would allow standard serde semantics.

[1] - kata-containers/kata-containers#60
[2] - https://serde.rs/remote-derive.html

According to the documentation of the Probability variant of opentelemetry::sdk::trace::sampler::Sampler,

Fractions >= 1 will always sample. If the parent span is sampled, then it's child spans will automatically be sampled.

This implies that a span may be sampled if its parent is not sampled, if a probability condition is met. Here is a link to the referenced documentation in the code:

In practice however, using the probability variant of Sampler will not sample any spans. Due to the implementation of should_sample which conflicts with the above documentation:

The implementation here first checks to see if the parent span was sampled, and only if it was, performs the probability check to see if the current span will be sampled. This does not match with the documentation shown above. If this behavior is intentional, the documentation should call out that the probability will only be tested, and spans will only be sampled if their parent span was sampled. I would expect the implementation to look more like this if the documentation is correct:

 if  *prob > 0.0 { 
     if *prob > 1.0 || parent_context.map(|ctx| ctx.is_sampled()).unwrap_or(false) || *prob > rand::random() { 
        // Mark span as sampled

A stdout exporter (or something that can exporter to a Writer can be really valuable, especially for dev purposes.

The go stdout metric exporter might be useful inspiration.

Currently span kind can only be assigned by setting the span.kind attribute. Span kind should be explicitly assignable when creating spans.

Note that we'll need an admin to configure the repo for this, e.g., to require that PRs pass checks.

At issue creation time, there are 68 clippy errors. Most (all?) look to be unreadable literals.

See open-telemetry/opentelemetry-go#183 for a similar issue.

I'm unsure if crates.io thinks this is MIT because previous releases were done under MIT - but the LICENSE file and Github both show this as Apache 2.0.

See open-telemetry/opentelemetry-specification#578 for spec changes

See the batching processor specs for details.

Implement span status management according to the spec. Currently status is being ignored as the underlying rustracing_jaeger does not have a way to track this information.

Propagating spans across different components can be a pain, especially if not all components currently "expect" a span.

Some sort of context-local variable (along the lines of Python's contextvars) might be useful here.

Named meters should be available to different parts of the application.

See also open-telemetry/opentelemetry-go#258

Let's make sure everyone has permission to review (and that PRs actually require appropriate checks!), get assigned issues, etc.

Per the spec, links can only be added at span creation time.

See open-telemetry/opentelemetry-go#329 for a similar issue.

This propagator is multi-purpose, i.e., valuable for use cases other than HTTP.

See also open-telemetry/opentelemetry-go#355.

See open-telemetry/opentelemetry-specification#609 for changes.