|
5 | 5 | //! [`API`]: https://opentelemetry.io/docs/specs/otel/overview/#api |
6 | 6 | //! [OpenTelemetry]: https://opentelemetry.io/docs/what-is-opentelemetry/ |
7 | 7 | //! |
8 | | -//! # Getting Started |
9 | | -//! |
10 | | -//! ```no_run |
11 | | -//! # #[cfg(feature = "trace")] |
12 | | -//! # { |
13 | | -//! use opentelemetry::{global, trace::{TraceContextExt, Tracer}, Context }; |
14 | | -//! |
15 | | -//! fn do_something() { |
16 | | -//! let tracer = global::tracer("my_component"); |
17 | | -//! let _guard = Context::current_with_span(tracer.start("my_span")).attach(); |
18 | | -//! // do work tracked by the now current span |
19 | | -//! } |
20 | | -//! # } |
21 | | -//! ``` |
22 | | -//! |
23 | | -//! See the [examples] directory for different integration patterns. |
24 | | -//! |
25 | | -//! [examples]: https://github.com/open-telemetry/opentelemetry-rust/tree/main/examples |
26 | | -//! |
27 | | -//! # Traces |
| 8 | +//! # Getting Started with Traces |
28 | 9 | //! |
29 | 10 | //! The [`trace`] module includes types for tracking the progression of a single |
30 | 11 | //! request while it is handled by services that make up an application. A trace |
31 | 12 | //! is a tree of [`Span`]s which are objects that represent the work being done |
32 | 13 | //! by individual services or components involved in a request as it flows |
33 | 14 | //! through a system. |
34 | 15 | //! |
35 | | -//! ### Creating and exporting spans |
36 | | -//! |
37 | 16 | //! ``` |
38 | 17 | //! # #[cfg(feature = "trace")] |
39 | 18 | //! # { |
|
55 | 34 | //! # } |
56 | 35 | //! ``` |
57 | 36 | //! |
| 37 | +//! See the [examples](https://github.com/open-telemetry/opentelemetry-rust/tree/main/examples) directory for different integration patterns. |
| 38 | +//! |
58 | 39 | //! See the [`trace`] module docs for more information on creating and managing |
59 | 40 | //! spans. |
60 | 41 | //! |
61 | 42 | //! [`Span`]: crate::trace::Span |
62 | 43 | //! |
63 | | -//! # Metrics |
64 | | -//! |
65 | | -//! |
66 | | -//! The [`metrics`] module includes types for recording measurements about a |
67 | | -//! service at runtime. |
68 | | -//! |
69 | | -//! ### Creating instruments and recording measurements |
70 | | -//! |
| 44 | +//! # Getting Started with Metrics |
| 45 | +//! |
| 46 | +//! The [`metrics`] module provides types for recording measurements about a |
| 47 | +//! service at runtime. Below are the key steps to report measurements using |
| 48 | +//! OpenTelemetry Metrics: |
| 49 | +//! |
| 50 | +//! 1. **Obtain a Meter:** Get a `Meter` from a `MeterProvider`. |
| 51 | +//! 2. **Create Instruments:** Use the `Meter` to create one or more instruments |
| 52 | +//! (e.g., counters, histograms). |
| 53 | +//! 3. **Record Measurements:** Use the instruments to record measurement values |
| 54 | +//! along with optional attributes. |
| 55 | +//! |
| 56 | +//! ## How Metrics work in OpenTelemetry |
| 57 | +//! In OpenTelemetry, raw measurements recorded using instruments are |
| 58 | +//! **aggregated in memory** to form metrics. These aggregated metrics are |
| 59 | +//! periodically exported by the [`opentelemetry_sdk`] at fixed intervals (e.g., |
| 60 | +//! every 60 seconds) via exporters such as [`opentelemetry-stdout`] or |
| 61 | +//! [`opentelemetry-otlp`]. This reduces reporting overhead while ensuring |
| 62 | +//! up-to-date data. The aggregation strategy and export interval can be |
| 63 | +//! customized in the [`opentelemetry_sdk`] based on your use case. |
| 64 | +//! |
| 65 | +//! ## Choosing the Right Instrument |
| 66 | +//! Selecting the correct instrument is critical for accurately representing |
| 67 | +//! your metrics data: |
| 68 | +//! |
| 69 | +//! - Use **Counters** for values that only increase, such as the number of |
| 70 | +//! requests served or errors encountered. |
| 71 | +//! - Use **UpDownCounters** for values that can increase or decrease, such as |
| 72 | +//! the number of active connections, number of items in a queue etc. |
| 73 | +//! - **Gauges:** Use for values that can go up or down and represent the |
| 74 | +//! current state, such as CPU usage, temperature etc. |
| 75 | +//! - Use **Histograms** for measuring the distribution of a value, such as |
| 76 | +//! response times or payload sizes. |
| 77 | +//! |
| 78 | +//! ### Observable Instruments |
| 79 | +//! |
| 80 | +//! Counters, UpDownCounters, and Gauges have Observable variants that allow |
| 81 | +//! values to be reported through a callback function. Observable instruments |
| 82 | +//! are ideal when the metric value is managed elsewhere and needs to be |
| 83 | +//! observed by OpenTelemetry instrumentation. The callbacks are automatically |
| 84 | +//! invoked by the OpenTelemetry SDK before every export (e.g., every 60 |
| 85 | +//! seconds). |
| 86 | +//! |
| 87 | +//! For example: |
| 88 | +//! - An **ObservableCounter** can monitor the number of page faults in a |
| 89 | +//! process as reported by the operating system. |
| 90 | +//! - An **ObservableUpDownCounter** can monitor the size of an in-memory queue |
| 91 | +//! by reporting the size using queue's len() method within the callback |
| 92 | +//! function. |
| 93 | +//! - An **ObservableGauge** can monitor the CPU temperature by using |
| 94 | +//! temperature sensor APIs within the callback function. |
| 95 | +//! |
| 96 | +//! For detailed guidance, refer to [OpenTelemetry Metrics API - Instrumentation |
| 97 | +//! Guidance](https://opentelemetry.io/docs/specs/otel/metrics/supplementary-guidelines/#instrument-selection). |
| 98 | +//! |
| 99 | +//! ## Best Practices |
| 100 | +//! - **Re-use Instruments:** Instruments are designed for |
| 101 | +//! reuse. Avoid creating new instruments repeatedly. |
| 102 | +//! - **Clone for Sharing:** If the same instrument needs to be used across |
| 103 | +//! multiple parts of your code, you can safely clone it to share. |
| 104 | +//! |
| 105 | +//! ## Example Usage |
71 | 106 | //! ``` |
72 | | -//! # #[cfg(feature = "metrics")] |
73 | | -//! # { |
74 | 107 | //! use opentelemetry::{global, KeyValue}; |
75 | 108 | //! |
76 | | -//! // get a meter from a provider |
| 109 | +//! // Get a meter from a provider. |
77 | 110 | //! let meter = global::meter("my_service"); |
78 | 111 | //! |
79 | | -//! // create an instrument |
80 | | -//! let counter = meter.u64_counter("my_counter").build(); |
| 112 | +//! // Create an instrument (in this case, a Counter). |
| 113 | +//! let counter = meter.u64_counter("request.count").build(); |
81 | 114 | //! |
82 | | -//! // record a measurement |
| 115 | +//! // Record a measurement by passing the value and a set of attributes. |
83 | 116 | //! counter.add(1, &[KeyValue::new("http.client_ip", "83.164.160.102")]); |
84 | | -//! # } |
| 117 | +//! |
| 118 | +//! // Create an ObservableCounter and register a callback that reports the measurement. |
| 119 | +//! let _observable_counter = meter |
| 120 | +//! .u64_observable_counter("bytes_received") |
| 121 | +//! .with_callback(|observer| { |
| 122 | +//! observer.observe( |
| 123 | +//! 100, |
| 124 | +//! &[ |
| 125 | +//! KeyValue::new("protocol", "udp"), |
| 126 | +//! ], |
| 127 | +//! ) |
| 128 | +//! }) |
| 129 | +//! .build(); |
85 | 130 | //! ``` |
86 | 131 | //! |
| 132 | +//! See the |
| 133 | +//! [examples](https://github.com/open-telemetry/opentelemetry-rust/tree/main/examples/metrics-basic) |
| 134 | +//! directory that show a runnable example with all type of instruments. |
| 135 | +//! |
| 136 | +//! |
87 | 137 | //! See the [`metrics`] module docs for more information on creating and |
88 | 138 | //! managing instruments. |
89 | 139 | //! |
90 | 140 | //! |
91 | | -//! # Logs |
| 141 | +//! # Getting Started with Logs |
92 | 142 | //! |
93 | 143 | //! The [`logs`] module contains the Logs Bridge API. It is not intended to be |
94 | 144 | //! called by application developers directly. It is provided for logging |
|
102 | 152 | //! [`opentelemetry-appender-tracing`](https://crates.io/crates/opentelemetry-appender-tracing) |
103 | 153 | //! crates. |
104 | 154 | //! |
105 | | -//! ## Crate Feature Flags |
| 155 | +//! # Crate Feature Flags |
106 | 156 | //! |
107 | 157 | //! The following core crate feature flags are available: |
108 | 158 | //! |
109 | 159 | //! * `trace`: Includes the trace API. |
110 | 160 | //! * `metrics`: Includes the metrics API. |
111 | 161 | //! * `logs`: Includes the logs bridge API. |
| 162 | +//! * `internal-logs`: Includes internal logging for the OpenTelemetry library via `tracing`. |
112 | 163 | //! |
113 | | -//! The default feature flags are ["trace", "metrics", "logs"] |
| 164 | +//! The default feature flags are ["trace", "metrics", "logs", "internal-logs"]. |
114 | 165 | //! |
115 | 166 | //! The following feature flags provides additional configuration for `logs`: |
116 | 167 | //! * `spec_unstable_logs_enabled`: Allow users to control the log level |
117 | 168 | //! |
118 | 169 | //! The following feature flags enable APIs defined in OpenTelemetry specification that is in experimental phase: |
119 | | -//! * `otel_unstable`: Includes unstable APIs. |
| 170 | +//! * `otel_unstable`: Includes unstable APIs. There are no features behind this flag at the moment. |
120 | 171 | //! |
121 | | -//! ## Related Crates |
| 172 | +//! # Related Crates |
122 | 173 | //! |
123 | 174 | //! In addition to `opentelemetry`, the [`open-telemetry/opentelemetry-rust`] |
124 | 175 | //! repository contains several additional crates designed to be used with the |
|
133 | 184 | //! trace information from [`http`] headers. |
134 | 185 | //! - [`opentelemetry-otlp`] exporter for sending telemetry in the |
135 | 186 | //! OTLP format. |
| 187 | +//! - [`opentelemetry-stdout`] provides ability to output telemetry to stdout, |
| 188 | +//! primarily used for learning/debugging purposes. |
136 | 189 | //! - [`opentelemetry-prometheus`] provides a pipeline and exporter for sending |
137 | 190 | //! metrics information to [`Prometheus`]. |
138 | 191 | //! - [`opentelemetry-zipkin`] provides a pipeline and exporter for sending |
|
148 | 201 | //! [`http`]: https://crates.io/crates/http |
149 | 202 | //! [`open-telemetry/opentelemetry-rust`]: https://github.com/open-telemetry/opentelemetry-rust |
150 | 203 | //! [`opentelemetry_sdk`]: https://crates.io/crates/opentelemetry_sdk |
| 204 | +//! [`opentelemetry-stdout`]: https://crates.io/crates/opentelemetry_stdout |
151 | 205 | //! [`opentelemetry-http`]: https://crates.io/crates/opentelemetry-http |
152 | 206 | //! [`opentelemetry-otlp`]: https://crates.io/crates/opentelemetry-otlp |
153 | 207 | //! [`opentelemetry-prometheus`]: https://crates.io/crates/opentelemetry-prometheus |
154 | 208 | //! [`opentelemetry-zipkin`]: https://crates.io/crates/opentelemetry-zipkin |
155 | 209 | //! [`Prometheus`]: https://prometheus.io |
156 | 210 | //! [`Zipkin`]: https://zipkin.io |
157 | 211 | //! |
158 | | -//! ## Supported Rust Versions |
| 212 | +//! # Supported Rust Versions |
159 | 213 | //! |
160 | 214 | //! OpenTelemetry is built against the latest stable release. The minimum |
161 | 215 | //! supported version is 1.70. The current OpenTelemetry version is not |
|
0 commit comments