Add log appender / bridge to glossary (#3335)

Co-authored-by: Reiley Yang <reyang@microsoft.com>
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>

CHANGELOG.md

@@ -28,6 +28,8 @@ release.
   ([#3331](https://github.com/open-telemetry/opentelemetry-specification/pull/3331))
 - Ensure Logs Bridge API doesn't contain SDK implementation details
   ([#3275](https://github.com/open-telemetry/opentelemetry-specification/pull/3275))
+- Add log appender / bridge to glossary.
+  ([#3335](https://github.com/open-telemetry/opentelemetry-specification/pull/3335))
 
 ### Resource
 

specification/glossary.md

@@ -38,6 +38,7 @@ Some other fundamental terms are documented in the [overview document](overview.
   * [Log Attributes](#log-attributes)
   * [Structured Logs](#structured-logs)
   * [Flat File Logs](#flat-file-logs)
+  * [Log Appender / Bridge](#log-appender--bridge)
 
 <!-- tocstop -->
 
@@ -234,3 +235,11 @@ records are possible too). There is no common industry agreement whether
 logs written to text files in more structured formats (e.g. JSON files)
 are considered Flat File Logs or not. Where such distinction is important it is
 recommended to call it out specifically.
+
+### Log Appender / Bridge
+
+A log appender or bridge is a component which bridges logs from an existing log
+API into OpenTelemetry using the [Log Bridge API](./logs/bridge-api.md). The
+terms "log bridge" and "log appender" are used interchangeably, reflecting that
+these components bridge data into OpenTelemetry, but are often called appenders
+in the logging domain.

specification/logs/README.md

@@ -139,7 +139,7 @@ Given the above state of the logging space we took the following approach:
 - OpenTelemetry defines a Logs Bridge API
   for [emitting LogRecords](./bridge-api.md#emit-logrecord). Application developers are
   NOT encouraged to call this API directly. It is provided for library authors
-  to build [Appenders](./bridge-api.md#how-to-create-log4j-style-appender), which use
+  to build [log appender](../glossary.md#log-appender--bridge), which use
   the API to bridge between existing logging libraries and the OpenTelemetry log
   data model. Existing logging libraries generally provide a much richer set of
   features than what is defined in OpenTelemetry. It is NOT a goal of
@@ -292,8 +292,8 @@ collected from all applications that can be instrumented in this manner.
 
 Some logging libraries are designed to be extended in this manner relatively
 easily. There is no need to actually modify the libraries, instead we can
-implement "appender" or "exporter" components for such libraries and implement
-the additional LogRecord enrichment in these components.
+implement "log appender" or "log bridge" components for such libraries and
+implement the additional LogRecord enrichment in these components.
 
 There are typically 2 ways to collect logs from these applications.
 
@@ -358,7 +358,7 @@ To facilitate both approaches described above OpenTelemetry provides
 a [Bridge API](./bridge-api.md) and [SDK](./sdk.md), which can be used together with existing
 logging libraries to automatically inject the trace context in the emitted logs,
 and provide an easy way to send the logs via OTLP. Instead of
-modifying each logging statement, [Appenders](./bridge-api.md#how-to-create-log4j-style-appender)
+modifying each logging statement, [log appenders](../glossary.md#log-appender--bridge)
 use the API to bridge logs from existing logging libraries to the OpenTelemetry
 data model, where the SDK controls how the logs are processed and exported.
 Application developers only need to configure the Appender and SDK at
@@ -369,8 +369,8 @@ application startup.
 These are greenfield developments. OpenTelemetry provides recommendations and
 best practices about how to emit logs (along with traces and metrics) from these
 applications. For applicable languages and frameworks the auto-instrumentation
-or simple configuration of a logging library to use an OpenTelemetry appender or
-extension will still be the easiest way to emit context-enriched logs. As
+or simple configuration of a logging library to use an OpenTelemetry log appender
+will still be the easiest way to emit context-enriched logs. As
 already described earlier we provide extensions to some popular logging
 libraries languages to support the manual instrumentation cases. The extensions
 will support the inclusion of the trace context in the logs and allow to send

specification/logs/bridge-api.md

@@ -19,7 +19,7 @@
 - [Optional and required parameters](#optional-and-required-parameters)
 - [Concurrency requirements](#concurrency-requirements)
 - [Usage](#usage)
-  * [How to Create Log4J Style Appender](#how-to-create-log4j-style-appender)
+  * [How to Create a Log4J Log Appender](#how-to-create-a-log4j-log-appender)
   * [Implicit Context Injection](#implicit-context-injection)
   * [Explicit Context Injection](#explicit-context-injection)
 
@@ -29,7 +29,7 @@
 
 <b>Note: this document defines a log *backend* API. The API is not intended to be called
 by application developers directly. It is provided for logging library authors
-to build [Appenders](#how-to-create-log4j-style-appender), which use
+to build [log appenders](#how-to-create-a-log4j-log-appender), which use
 this API to bridge between existing logging libraries and the OpenTelemetry log
 data model.</b>
 
@@ -160,15 +160,16 @@ specific guarantees and safeties.
 
 ## Usage
 
-### How to Create Log4J Style Appender
+### How to Create a Log4J Log Appender
 
-An Appender implementation can be used to bridge logs into the [Log SDK](./sdk.md)
+A [log appender](../glossary.md#log-appender--bridge) implementation can be used
+to can be used to bridge logs into the [Log SDK](./sdk.md)
 OpenTelemetry [LogRecordExporters](sdk.md#logrecordexporter). This approach is
 typically used for applications which are fine with changing the log transport
 and is [one of the supported](README.md#direct-to-collector) log collection
 approaches.
 
-The Appender implementation will typically acquire a [Logger](#logger) from the
+The log appender implementation will typically acquire a [Logger](#logger) from the
 global [LoggerProvider](#loggerprovider) at startup time, then
 call [Emit LogRecord](#emit-logrecord) for `LogRecord`s received from the
 application.
@@ -186,7 +187,7 @@ This same approach can be also used for example for:
   there is no implicit Context in Go it is not possible to get and use the
   active Span.
 
-Appenders can be created in OpenTelemetry language libraries by OpenTelemetry
+Log appenders can be created in OpenTelemetry language libraries by OpenTelemetry
 maintainers, or by 3rd parties for any logging library that supports a similar
 extension mechanism. This specification recommends each OpenTelemetry language
 library to include out-of-the-box Appender implementation for at least one