Skip to content

Commit a74d0ef

Browse files
committed
Few doc updates for opentelemetry
1 parent 8e6b479 commit a74d0ef

File tree

2 files changed

+92
-42
lines changed

2 files changed

+92
-42
lines changed

examples/metrics-basic/Cargo.toml

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -6,12 +6,9 @@ license = "Apache-2.0"
66
publish = false
77

88
[dependencies]
9-
opentelemetry = { path = "../../opentelemetry", features = ["metrics", "otel_unstable"] }
9+
opentelemetry = { path = "../../opentelemetry", features = ["metrics"] }
1010
opentelemetry_sdk = { path = "../../opentelemetry-sdk", features = ["metrics", "rt-tokio"] }
1111
opentelemetry-stdout = { path = "../../opentelemetry-stdout", features = ["metrics"]}
1212
tokio = { workspace = true, features = ["full"] }
1313
serde_json = { workspace = true }
1414

15-
[features]
16-
default = ["otel_unstable"]
17-
otel_unstable = ["opentelemetry/otel_unstable"]

opentelemetry/src/lib.rs

Lines changed: 91 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -5,35 +5,15 @@
55
//! [`API`]: https://opentelemetry.io/docs/specs/otel/overview/#api
66
//! [OpenTelemetry]: https://opentelemetry.io/docs/what-is-opentelemetry/
77
//!
8-
//! # Getting Started
8+
//! # Getting Started with Traces
99
//!
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
2810
//!
2911
//! The [`trace`] module includes types for tracking the progression of a single
3012
//! request while it is handled by services that make up an application. A trace
3113
//! is a tree of [`Span`]s which are objects that represent the work being done
3214
//! by individual services or components involved in a request as it flows
3315
//! through a system.
3416
//!
35-
//! ### Creating and exporting spans
36-
//!
3717
//! ```
3818
//! # #[cfg(feature = "trace")]
3919
//! # {
@@ -55,40 +35,109 @@
5535
//! # }
5636
//! ```
5737
//!
38+
//! See the [examples](https://github.com/open-telemetry/opentelemetry-rust/tree/main/examples) directory for different integration patterns.
39+
//!
5840
//! See the [`trace`] module docs for more information on creating and managing
5941
//! spans.
6042
//!
6143
//! [`Span`]: crate::trace::Span
6244
//!
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
71105
//! ```
72-
//! # #[cfg(feature = "metrics")]
73-
//! # {
74106
//! use opentelemetry::{global, KeyValue};
75107
//!
76-
//! // get a meter from a provider
108+
//! // Get a meter from a provider.
77109
//! let meter = global::meter("my_service");
78110
//!
79-
//! // create an instrument
111+
//! // Create an instrument (in this case, a Counter).
80112
//! let counter = meter.u64_counter("my_counter").build();
81113
//!
82-
//! // record a measurement
114+
//! // Record a measurement by passing the value and a set of attributes.
83115
//! 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();
85129
//! ```
86130
//!
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+
//!
87136
//! See the [`metrics`] module docs for more information on creating and
88137
//! managing instruments.
89138
//!
90139
//!
91-
//! # Logs
140+
//! # Getting Started with Logs
92141
//!
93142
//! The [`logs`] module contains the Logs Bridge API. It is not intended to be
94143
//! called by application developers directly. It is provided for logging
@@ -109,14 +158,15 @@
109158
//! * `trace`: Includes the trace API.
110159
//! * `metrics`: Includes the metrics API.
111160
//! * `logs`: Includes the logs bridge API.
161+
//! * `internal-logs`: Includes internal logging for the OpenTelemetry library via `tracing`.
112162
//!
113-
//! The default feature flags are ["trace", "metrics", "logs"]
163+
//! The default feature flags are ["trace", "metrics", "logs", "internal-loggs"].
114164
//!
115165
//! The following feature flags provides additional configuration for `logs`:
116166
//! * `spec_unstable_logs_enabled`: Allow users to control the log level
117167
//!
118168
//! 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.
120170
//!
121171
//! ## Related Crates
122172
//!
@@ -133,6 +183,8 @@
133183
//! trace information from [`http`] headers.
134184
//! - [`opentelemetry-otlp`] exporter for sending telemetry in the
135185
//! OTLP format.
186+
//! - [`opentelemetry-stdout`] provides ability to output telemetry to stdout,
187+
//! primarily used for learning/debugging purposes.
136188
//! - [`opentelemetry-prometheus`] provides a pipeline and exporter for sending
137189
//! metrics information to [`Prometheus`].
138190
//! - [`opentelemetry-zipkin`] provides a pipeline and exporter for sending
@@ -148,6 +200,7 @@
148200
//! [`http`]: https://crates.io/crates/http
149201
//! [`open-telemetry/opentelemetry-rust`]: https://github.com/open-telemetry/opentelemetry-rust
150202
//! [`opentelemetry_sdk`]: https://crates.io/crates/opentelemetry_sdk
203+
//! [`opentelemetry-stdout`]: https://crates.io/crates/opentelemetry_stdout
151204
//! [`opentelemetry-http`]: https://crates.io/crates/opentelemetry-http
152205
//! [`opentelemetry-otlp`]: https://crates.io/crates/opentelemetry-otlp
153206
//! [`opentelemetry-prometheus`]: https://crates.io/crates/opentelemetry-prometheus

0 commit comments

Comments
 (0)