Skip to content
This repository was archived by the owner on Dec 18, 2025. It is now read-only.

Commit 70974b3

Browse files
committed
adding baggage to whitepaper
1 parent ae0fa1d commit 70974b3

1 file changed

Lines changed: 12 additions & 0 deletions

File tree

whitepaper.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,7 @@ See [the contributing section](#contributing) on proposing changes to this paper
2323
* [Logs](#logs)
2424
* [Traces](#traces)
2525
* [Profiles](#profiles)
26+
* [Baggage](#baggage)
2627
* [Dumps](#dumps)
2728
* [Correlating Observability Signals](#correlating-observability-signals)
2829
* [Signal correlation](#signal-correlation)
@@ -259,6 +260,17 @@ Profiling data produced by runtimes typically includes statistics down to the li
259260

260261
> Image 2 shows an example icicle graph for a CPU profile of an application written in Go. It includes a kernel operation done by the Syscall call. This profile highlights that 35% of CPU time was used to compute hash, indicating potential optimization opportunities. [Source](https://pprof.me/9ce2c2d/).
261262
263+
### Baggage
264+
265+
OpenTelemetry Baggage is a mechanism for propagating small key-value pairs throughout a distributed system. It allows you to attach contextual information to a request as it flows through various services. While Baggage is not primarily designed for debugging or monitoring like the other signals, it complements them by enabling advanced context-sharing capabilities.
266+
267+
Baggage consists of:
268+
- Key-Value Pairs: Lightweight metadata (e.g., user_id=12345, region=us-west-1).
269+
- Global Context: Shared across services as part of the request context.
270+
- Cross-Service Propagation: Automatically carried by OpenTelemetry propagators.
271+
272+
Checkout [OpenTelemetry Baggage](https://opentelemetry.io/docs/concepts/signals/baggage/) for detail.
273+
262274
### Dumps
263275

264276
In software development, core dump files are used to troubleshoot a program, i.e., a crashed process. Classically, the operating system, with the help of some configuration such as location, name convention or file size, writes an image of the process's memory at the time of the crash for analysis. In cloud-native, however, core dump files' collection of a large cluster can easily create a bottleneck in storage or even the network, depending on how the cluster's storage is attached to the cluster nodes. For example, processing-intensive applications could generate core dump files of double-digit Gigabyte size.

0 commit comments

Comments
 (0)