<commit_before># Glossary

This document defines some terms that are used across this specification.

Some other fundamental terms are documented in the [overview document](overview.md).

<details>
<summary>Table of Contents</summary>

<!-- toc -->

- [User Roles](#user-roles)
  * [Application Owner](#application-owner)
  * [Library Author](#library-author)
  * [Instrumentation Author](#instrumentation-author)
  * [Plugin Author](#plugin-author)
- [Common](#common)
  * [Signals](#signals)
  * [Packages](#packages)
  * [ABI Compatibility](#abi-compatibility)
  * [In-band and Out-of-band Data](#in-band-and-out-of-band-data)
  * [Manual Instrumentation](#manual-instrumentation)
  * [Automatic Instrumentation](#automatic-instrumentation)
  * [Telemetry SDK](#telemetry-sdk)
  * [Constructors](#constructors)
  * [SDK Plugins](#sdk-plugins)
  * [Exporter Library](#exporter-library)
  * [Instrumented Library](#instrumented-library)
  * [Instrumentation Library](#instrumentation-library)
  * [Instrumentation Scope](#instrumentation-scope)
  * [Tracer Name / Meter Name](#tracer-name--meter-name)
  * [Execution Unit](#execution-unit)
- [Logs](#logs)
  * [Log Record](#log-record)
  * [Log](#log)
  * [Embedded Log](#embedded-log)
  * [Standalone Log](#standalone-log)
  * [Log Attributes](#log-attributes)
  * [Structured Logs](#structured-logs)
  * [Flat File Logs](#flat-file-logs)

<!-- tocstop -->

</details>

## User Roles

### Application Owner

The maintainer of an application or service, responsible for configuring and managing the lifecycle of the OpenTelemetry SDK.

### Library Author

The maintainer of a shared library which is depended upon by many applications, and targeted by OpenTelemetry instrumentation.

### Instrumentation Author

The maintainer of OpenTelemetry instrumentation written against the OpenTelemetry API.
This may be instrumentation written within application code, within a shared library, or within an instrumentation library.

### Plugin Author

The maintainer of an OpenTelemetry SDK Plugin, written against OpenTelemetry SDK plugin interfaces.

## Common

### Signals

OpenTelemetry is structured around signals, or categories of telemetry.
Metrics, logs, traces, and baggage are examples of signals.
Each signal represents a coherent, stand-alone set of functionality.
Each signal follows a separate lifecycle, defining its current stability level.

### Packages

In this specification, the term **package** describes a set of code which represents a single dependency, which may be imported into a program independently from other packages.
This concept may map to a different term in some languages, such as "module."
Note that in some languages, the term "package" refers to a different concept.

### ABI Compatibility

An ABI (application binary interface) is an interface which defines interactions between software components at the machine code level, for example between an application executable and a compiled binary of a shared object library. ABI compatibility means that a new compiled version of a library may be correctly linked to a target executable without the need for that executable to be recompiled.

ABI compatibility is important for some languages, especially those which provide a form of machine code. For other languages, ABI compatibility may not be a relevant requirement.

### In-band and Out-of-band Data

> In telecommunications, **in-band signaling** is the sending of control information within the same band or channel used for data such as voice or video. This is in contrast to **out-of-band signaling** which is sent over a different channel, or even over a separate network ([Wikipedia](https://en.wikipedia.org/wiki/In-band_signaling)).

In OpenTelemetry we refer to **in-band data** as data that is passed
between components of a distributed system as part of business messages,
for example, when trace or baggages are included
in the HTTP requests in the form of HTTP headers.
Such data usually does not contain the telemetry,
but is used to correlate and join the telemetry produced by various components.
The telemetry itself is referred to as **out-of-band data**:
it is transmitted from applications via dedicated messages,
usually asynchronously by background routines
rather than from the critical path of the business logic.
Metrics, logs, and traces exported to telemetry backends are examples of out-of-band data.

### Manual Instrumentation

Coding against the OpenTelemetry API such as the [Tracing API](trace/api.md), [Metrics API](metrics/api.md), or others to collect telemetry from end-user code or shared frameworks (e.g. MongoDB, Redis, etc.).

### Automatic Instrumentation

Refers to telemetry collection methods that do not require the end-user to modify application's source code.
Methods vary by programming language, and examples include bytecode injection or monkey patching.
<commit_msg>Add more auto-instrumentation examples (#2853)<commit_after># Glossary

This document defines some terms that are used across this specification.

Some other fundamental terms are documented in the [overview document](overview.md).

<details>
<summary>Table of Contents</summary>

<!-- toc -->

- [User Roles](#user-roles)
  * [Application Owner](#application-owner)
  * [Library Author](#library-author)
  * [Instrumentation Author](#instrumentation-author)
  * [Plugin Author](#plugin-author)
- [Common](#common)
  * [Signals](#signals)
  * [Packages](#packages)
  * [ABI Compatibility](#abi-compatibility)
  * [In-band and Out-of-band Data](#in-band-and-out-of-band-data)
  * [Manual Instrumentation](#manual-instrumentation)
  * [Automatic Instrumentation](#automatic-instrumentation)
  * [Telemetry SDK](#telemetry-sdk)
  * [Constructors](#constructors)
  * [SDK Plugins](#sdk-plugins)
  * [Exporter Library](#exporter-library)
  * [Instrumented Library](#instrumented-library)
  * [Instrumentation Library](#instrumentation-library)
  * [Instrumentation Scope](#instrumentation-scope)
  * [Tracer Name / Meter Name](#tracer-name--meter-name)
  * [Execution Unit](#execution-unit)
- [Logs](#logs)
  * [Log Record](#log-record)
  * [Log](#log)
  * [Embedded Log](#embedded-log)
  * [Standalone Log](#standalone-log)
  * [Log Attributes](#log-attributes)
  * [Structured Logs](#structured-logs)
  * [Flat File Logs](#flat-file-logs)

<!-- tocstop -->

</details>

## User Roles

### Application Owner

The maintainer of an application or service, responsible for configuring and managing the lifecycle of the OpenTelemetry SDK.

### Library Author

The maintainer of a shared library which is depended upon by many applications, and targeted by OpenTelemetry instrumentation.

### Instrumentation Author

The maintainer of OpenTelemetry instrumentation written against the OpenTelemetry API.
This may be instrumentation written within application code, within a shared library, or within an instrumentation library.

### Plugin Author

The maintainer of an OpenTelemetry SDK Plugin, written against OpenTelemetry SDK plugin interfaces.

## Common

### Signals

OpenTelemetry is structured around signals, or categories of telemetry.
Metrics, logs, traces, and baggage are examples of signals.
Each signal represents a coherent, stand-alone set of functionality.
Each signal follows a separate lifecycle, defining its current stability level.

### Packages

In this specification, the term **package** describes a set of code which represents a single dependency, which may be imported into a program independently from other packages.
This concept may map to a different term in some languages, such as "module."
Note that in some languages, the term "package" refers to a different concept.

### ABI Compatibility

An ABI (application binary interface) is an interface which defines interactions between software components at the machine code level, for example between an application executable and a compiled binary of a shared object library. ABI compatibility means that a new compiled version of a library may be correctly linked to a target executable without the need for that executable to be recompiled.

ABI compatibility is important for some languages, especially those which provide a form of machine code. For other languages, ABI compatibility may not be a relevant requirement.

### In-band and Out-of-band Data

> In telecommunications, **in-band signaling** is the sending of control information within the same band or channel used for data such as voice or video. This is in contrast to **out-of-band signaling** which is sent over a different channel, or even over a separate network ([Wikipedia](https://en.wikipedia.org/wiki/In-band_signaling)).

In OpenTelemetry we refer to **in-band data** as data that is passed
between components of a distributed system as part of business messages,
for example, when trace or baggages are included
in the HTTP requests in the form of HTTP headers.
Such data usually does not contain the telemetry,
but is used to correlate and join the telemetry produced by various components.
The telemetry itself is referred to as **out-of-band data**:
it is transmitted from applications via dedicated messages,
usually asynchronously by background routines
rather than from the critical path of the business logic.
Metrics, logs, and traces exported to telemetry backends are examples of out-of-band data.

### Manual Instrumentation

Coding against the OpenTelemetry API such as the [Tracing API](trace/api.md), [Metrics API](metrics/api.md), or others to collect telemetry from end-user code or shared frameworks (e.g. MongoDB, Redis, etc.).

### Automatic Instrumentation

Refers to telemetry collection methods that do not require the end-user to modify application's source code.
Methods vary by programming language, and examples include code manipulation (during compilation or at runtime),
monkey patching, or running eBPF programs.

{'fraction_non_alphanumeric': 0.08340906795920427, 'fraction_numerical': 0.00040391800464505703, 'mean_word_length': 5.061199510403917, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 17, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2979866', 'n_tokens_mistral': 2636, 'n_tokens_neox': 2453, 'n_words': 1162}