opentelemetry-jaeger 0.22.0

Jaeger exporter for OpenTelemetry
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178

![OpenTelemetry — An observability framework for cloud-native software.][splash]

[splash]: https://raw.githubusercontent.com/open-telemetry/opentelemetry-rust/main/assets/logo-text.png

# OpenTelemetry Jaeger (Deprecated)

**WARNING**
As of [Jaeger 1.35.0], released in Sept 2022, ingesting the OpenTelemetry Protocol (OTLP) is stable and
as a result, language specific Jaeger exporters within OpenTelemetry SDKs are [recommended for deprecation by the OpenTelemetry project][jaeger-deprecation].
More information and examples of using OTLP with Jaeger can be found in [Introducing native support for OpenTelemetry in Jaeger][jaeger-otlp]
and [Exporting OTLP traces to Jaeger][exporting-otlp].

The opentelemetry-jaeger crate previously contained both a Jaeger exporter and a Jaeger propagator.
To prepare for the deprecation of the Jaeger exporter, the Jaeger propagator implementation has been migrated to
[opentelemetry-jaeger-propagator](../opentelemetry-jaeger-propagator/).

The 0.22.0 is the last release of the Jaeger exporter. This means that future versions of the OpenTelemetry
SDK will not work with the exporter.

If you have any questions please comment on the [Jaeger Deprecation Issue][deprecation-issue].

[`Jaeger`] integration for applications instrumented with [`OpenTelemetry`]. This includes a jaeger exporter and a jaeger propagator.

[![Crates.io: opentelemetry-jaeger](https://img.shields.io/crates/v/opentelemetry-jaeger.svg)](https://crates.io/crates/opentelemetry-jaeger)
[![Documentation](https://docs.rs/opentelemetry-jaeger/badge.svg)](https://docs.rs/opentelemetry-jaeger)
[![LICENSE](https://img.shields.io/crates/l/opentelemetry-jaeger)](./LICENSE)
[![GitHub Actions CI](https://github.com/open-telemetry/opentelemetry-rust/workflows/CI/badge.svg)](https://github.com/open-telemetry/opentelemetry-rust/actions?query=workflow%3ACI+branch%3Amain)
[![Slack](https://img.shields.io/badge/slack-@cncf/otel/rust-brightgreen.svg?logo=slack)](https://cloud-native.slack.com/archives/C03GDP0H023)

## Overview

[`OpenTelemetry`] is a collection of tools, APIs, and SDKs used to instrument,
generate, collect, and export telemetry data (metrics, logs, and traces) for
analysis in order to understand your software's performance and behavior. This
crate provides a trace pipeline and exporter for sending span information to a
Jaeger `agent` or `collector` endpoint for processing and visualization.

*Compiler support: [requires `rustc` 1.65+][msrv]*

[`Jaeger`]: https://www.jaegertracing.io/
[jaeger-otlp]: https://medium.com/jaegertracing/introducing-native-support-for-opentelemetry-in-jaeger-eb661be8183c
[jaeger-deprecation]: https://opentelemetry.io/blog/2022/jaeger-native-otlp/
[exporting-otlp]: https://github.com/open-telemetry/opentelemetry-rust/tree/main/examples/tracing-jaeger
[Jaeger 1.35.0]: https://github.com/jaegertracing/jaeger/releases/tag/v1.35.0
[deprecation-issue]: https://github.com/open-telemetry/opentelemetry-rust/issues/995
[`OpenTelemetry`]: https://crates.io/crates/opentelemetry
[msrv]: #supported-rust-versions

### Quickstart

First make sure you have a running version of the Jaeger instance you want to
send data to:

```shell
$ docker run -d -p6831:6831/udp -p6832:6832/udp -p16686:16686 -p14268:14268 jaegertracing/all-in-one:latest
```

Then install a new jaeger pipeline with the recommended defaults to start
exporting telemetry:

```rust
use opentelemetry::global;
use opentelemetry::trace::Tracer;
use opentelemetry_jaeger_propagator;

fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync + 'static>> {
    global::set_text_map_propagator(opentelemetry_jaeger_propagator::Propagator::new());
    let tracer = opentelemetry_jaeger::new_agent_pipeline().install_simple()?;

    tracer.in_span("doing_work", |cx| {
        // Traced app logic here...
    });

    global::shutdown_tracer_provider(); // sending remaining spans

    Ok(())
}
```

![Jaeger UI](https://raw.githubusercontent.com/open-telemetry/opentelemetry-rust/main/opentelemetry-jaeger/trace.png)

## Performance

For optimal performance, a batch exporter is recommended as the simple exporter
will export each span synchronously on drop. You can enable the [`rt-tokio`],
[`rt-tokio-current-thread`] or [`rt-async-std`] features and specify a runtime
on the pipeline builder to have a batch exporter configured for you
automatically.

```toml
[dependencies]
opentelemetry_sdk = { version = "*", features = ["rt-tokio"] }
opentelemetry-jaeger = { version = "*", features = ["rt-tokio"] }
```

```rust
let tracer = opentelemetry_jaeger::new_agent_pipeline()
    .install_batch(opentelemetry_sdk::runtime::Tokio)?;
```

[`rt-tokio`]: https://tokio.rs
[`rt-tokio-current-thread`]: https://tokio.rs
[`rt-async-std`]: https://async.rs

### Jaeger Exporter From Environment Variables

The jaeger pipeline builder can be configured dynamically via environment
variables. All variables are optional, a full list of accepted options can be
found in the [jaeger variables spec].

[jaeger variables spec]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md

### Jaeger Collector Example

If you want to skip the agent and submit spans directly to a Jaeger collector,
you can enable the optional `collector_client` feature for this crate. This
example expects a Jaeger collector running on `http://localhost:14268`.

```toml
[dependencies]
opentelemetry-jaeger = { version = "..", features = ["isahc_collector_client"] }
```

Then you can use the [`with_collector_endpoint`] method to specify the endpoint:

[`with_collector_endpoint`]: https://docs.rs/opentelemetry-jaeger/latest/opentelemetry_jaeger/config/collector/struct.CollectorPipeline.html#method.with_endpoint

```rust
// Note that this requires one of the following features enabled so that there is a default http client implementation
// * hyper_collector_client
// * reqwest_collector_client
// * reqwest_blocking_collector_client
// * reqwest_rustls_collector_client
// * isahc_collector_client

// You can also provide your own implementation by enable
// `collector_client` and set it with
// new_pipeline().with_http_client() method.
use opentelemetry::trace::Tracer;

fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync + 'static>> {
    let tracer = opentelemetry_jaeger::new_collector_pipeline()
        .with_endpoint("http://localhost:14268/api/traces")
        // optionally set username and password as well.
        .with_username("username")
        .with_password("s3cr3t")
        .install_batch()?;

    tracer.in_span("doing_work", |cx| {
        // Traced app logic here...
    });

    opentelemetry::global::shutdown_tracer_provider(); // sending remaining spans

    Ok(())
}
```

## Kitchen Sink Full Configuration

[`Example`] showing how to override all configuration options. See the
[`AgentPipeline`] docs for details of each option.

[`Example`]: https://docs.rs/opentelemetry-jaeger/latest/opentelemetry_jaeger/#kitchen-sink-full-configuration
[`AgentPipeline`]: https://docs.rs/opentelemetry-jaeger/latest/opentelemetry_jaeger/config/agent/struct.AgentPipeline.html

## Supported Rust Versions

OpenTelemetry is built against the latest stable release. The minimum supported
version is 1.65. The current OpenTelemetry version is not guaranteed to build
on Rust versions earlier than the minimum supported version.

The current stable Rust compiler and the three most recent minor versions
before it will always be supported. For example, if the current stable compiler
version is 1.49, the minimum supported version will not be increased past 1.46,
three minor versions prior. Increasing the minimum supported compiler version
is not considered a semver breaking change as long as doing so complies with
this policy.