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