Rename Logs Bridge API to Logs API

CHANGELOG.md

@@ -33,6 +33,8 @@ release.
   ([#4203](https://github.com/open-telemetry/opentelemetry-specification/pull/4203))
 - Make all fields as identifying for Logger. Previously attributes were omitted from being identifying.
   ([#4161](https://github.com/open-telemetry/opentelemetry-specification/pull/4161))
+- Rename Logs Bridge API to Logs API and do not discourage from direct usage.
+  ([#9999](https://github.com/open-telemetry/opentelemetry-specification/pull/9999))
 
 ### Events
 

specification/README.md

@@ -28,9 +28,7 @@ path_base_for_github_subdir:
   - [Baggage](baggage/api.md)
   - [Tracing](trace/api.md)
   - [Metrics](metrics/api.md)
-  - [Logs](logs/README.md)
-    - [Bridge API](logs/bridge-api.md)
-    - [Event API](logs/event-api.md)
+  - [Logs](logs/api.md)
 - SDK Specification
   - [Tracing](trace/sdk.md)
   - [Metrics](metrics/sdk.md)

specification/configuration/sdk.md

@@ -283,7 +283,7 @@ try {
 // Access SDK components and install instrumentation
 TracerProvider tracerProvider = openTelemetry.getTracerProvider();
 MeterProvider meterProvider = openTelemetry.getMeterProvider();
-LoggerProvider loggerProvider = openTelemetry.getLogsBridge();
+LoggerProvider loggerProvider = openTelemetry.getLoggerProvider();
 ContextPropagators propagators = openTelemetry.getPropagators();
 ConfigProvider configProvider = openTelemetry.getConfigProvider();
 ```
@@ -311,7 +311,7 @@ try {
 // Access SDK components and install instrumentation
 TracerProvider tracerProvider = openTelemetry.getTracerProvider();
 MeterProvider meterProvider = openTelemetry.getMeterProvider();
-LoggerProvider loggerProvider = openTelemetry.getLogsBridge();
+LoggerProvider loggerProvider = openTelemetry.getLoggerProvider();
 ContextPropagators propagators = openTelemetry.getPropagators();
 ConfigProvider configProvider = openTelemetry.getConfigProvider();
 ```
@@ -339,7 +339,7 @@ OpenTelemetry openTelemetry = AutoConfiguredOpenTelemetrySdk.initialize().getOpe
 // Access SDK components and install instrumentation
 TracerProvider tracerProvider = openTelemetry.getTracerProvider();
 MeterProvider meterProvider = openTelemetry.getMeterProvider();
-LoggerProvider loggerProvider = openTelemetry.getLogsBridge();
+LoggerProvider loggerProvider = openTelemetry.getLoggerProvider();
 ContextPropagators propagators = openTelemetry.getPropagators();
 ConfigProvider configProvider = openTelemetry.getConfigProvider();
 ```

specification/glossary.md

@@ -192,7 +192,7 @@ concept the attributes of the scope cannot change at runtime.
 
 This refers to the `name` and (optional) `version` arguments specified when
 creating a new `Tracer` or `Meter` (see
-[Obtaining a Tracer](trace/api.md#tracerprovider)/[Obtaining a Meter](metrics/api.md#meterprovider))/[Obtaining a Logger](logs/bridge-api.md#loggerprovider).
+[Obtaining a Tracer](trace/api.md#tracerprovider)/[Obtaining a Meter](metrics/api.md#meterprovider))/[Obtaining a Logger](logs/api.md#loggerprovider).
 The name/version pair identifies the
 [Instrumentation Scope](#instrumentation-scope), for example the
 [Instrumentation Library](#instrumentation-library) or another unit of
@@ -250,7 +250,7 @@ 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
+API into OpenTelemetry using the [Logs API](./logs/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

@@ -140,16 +140,13 @@ Given the above state of the logging space we took the following approach:
   OpenTelemetry log data model. OpenTelemetry Collector can read such logs and
   translate them to OpenTelemetry log data model.
 
-- OpenTelemetry defines a Logs Bridge API
-  for [emitting LogRecords](./bridge-api.md#emit-a-logrecord). Application developers are
-  NOT encouraged to call this API directly. It is provided for library authors
-  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
+- OpenTelemetry defines a Logs API
+  for [emitting LogRecords](./api.md#emit-a-logrecord).
+  Existing logging libraries generally provide a much richer set of
   features than what is defined in OpenTelemetry. It is NOT a goal of
   OpenTelemetry to ship a feature-rich logging library.
 
-- OpenTelemetry defines an [SDK](./sdk.md) implementation of the [Bridge API](./bridge-api.md),
+- OpenTelemetry defines an [SDK](./sdk.md) implementation of the [API](./api.md),
   which enables configuration of [processing](./sdk.md#logrecordprocessor)
   and [exporting](./sdk.md#logrecordexporter) LogRecords.
 
@@ -230,8 +227,7 @@ processor.
 ### Infrastructure Logs
 
 These are logs generated by various infrastructure components, such as
-Kubernetes events (if you are wondering why events are discussed in the context
-of logs see [Event API Data model](./event-api.md#event-data-model)). Like system logs, the
+Kubernetes events. Like system logs, the
 infrastructure logs lack a trace context and can be enriched by the resource
 context - information about the node, pod, container, etc.
 
@@ -359,7 +355,7 @@ as parsers, log tailing and rotation. It also enables the possibility to send
 logs directly to the logging backend without using a log collection agent.
 
 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
+a [API](./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, [log appenders](../glossary.md#log-appender--bridge)
@@ -444,7 +440,7 @@ standard output.
 
 ## Specifications
 
-* [Logs Bridge API](./bridge-api.md)
+* [Logs API](./api.md)
 * [Logs SDK](./sdk.md)
 * [Logs Data Model](./data-model.md)
 * [Event API](./event-api.md)

specification/logs/bridge-api.md → specification/logs/api.md

@@ -1,7 +1,10 @@
-# Logs Bridge API
+# Logs API
 
 **Status**: [Stable](../document-status.md), except where otherwise specified
 
+**Note: the Logs API was previously called the Logs Bridge API, but has since been renamed
+to reflect that it is now a user-facing API.**
+
 <details>
 <summary>Table of Contents</summary>
 
@@ -25,14 +28,7 @@
 
 </details>
 
-<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
-[log appenders](./supplementary-guidelines.md#how-to-create-a-log4j-log-appender),
-which use this API to bridge between existing logging libraries and the
-OpenTelemetry log data model.</b>
-
-The Logs Bridge API consist of these main components:
+The Logs API consist of these main components:
 
 * [LoggerProvider](#loggerprovider) is the entry point of the API. It provides access to `Logger`s.
 * [Logger](#logger) is responsible for emitting logs as
@@ -167,22 +163,13 @@ provide it.
 
 ## Concurrency requirements
 
-For languages which support concurrent execution the Logs Bridge APIs provide
+For languages which support concurrent execution the Logs APIs provide
 specific guarantees and safeties.
 
 **LoggerProvider** - all methods are safe to be called concurrently.
 
 **Logger** - all methods are safe to be called concurrently.
 
-## Artifact Naming
-
-The Logs Bridge API is not intended to be called by application developers
-directly, and SHOULD include documentation that discourages direct use. However,
-in the event OpenTelemetry were to add a user facing API, the Logs Bridge API would
-be a natural starting point. Therefore, Log Bridge API artifact, package, and class
-names MUST NOT include the terms "bridge", "appender", or any other qualifier
-that would prevent evolution into a user facing API.
-
 ## References
 
 - [OTEP0150 Logging Library SDK Prototype Specification](https://github.com/open-telemetry/oteps/blob/main/text/logs/0150-logging-library-sdk.md)

specification/logs/event-api.md

@@ -55,9 +55,7 @@ both their `Attributes` and their `Body`.
 ## Event API use cases
 
 The Events API was designed to allow shared libraries to emit high quality
-logs without needing to depend on a third party logger. Unlike the
-[Logs Bridge API](./bridge-api.md), instrumentation authors and application
-developers are encouraged to call this API directly. It is appropriate to
+logs without needing to depend on a third party logger. It is appropriate to
 use the Event API when these properties fit your requirements:
 
 * Logging from a shared library that must run in many applications.

specification/logs/event-sdk.md

@@ -81,7 +81,7 @@ Emit a `LogRecord` representing an `Event`.
 **Implementation Requirements:**
 
 The implementation MUST use the parameters
-to [emit a logRecord](./bridge-api.md#emit-a-logrecord) as follows:
+to [emit a logRecord](./api.md#emit-a-logrecord) as follows:
 
 * The `Name` MUST be used to set
   the `event.name` [Attribute](./data-model.md#field-attributes). If
@@ -94,10 +94,10 @@ to [emit a logRecord](./bridge-api.md#emit-a-logrecord) as follows:
   the [Timestamp](./data-model.md#field-timestamp). If not provided, `Timestamp`
   MUST be set to the current time when [emit](#emit-event) was called.
 * The [Observed Timestamp](./data-model.md#field-observedtimestamp) MUST not be
-  set. (NOTE: [emit a logRecord](./bridge-api.md#emit-a-logrecord) will
+  set. (NOTE: [emit a logRecord](./api.md#emit-a-logrecord) will
   set `ObservedTimestamp` to the current time when unset.)
 * If provided by the user, the `Context` MUST be used to set
-  the [Context](./bridge-api.md#emit-a-logrecord). If not provided, `Context`
+  the [Context](./api.md#emit-a-logrecord). If not provided, `Context`
   MUST be set to the current Context.
 * If provided by the user, the `SeverityNumber` MUST be used to set
   the [Severity Number](./data-model.md#field-severitynumber) when emitting the

specification/logs/noop.md

@@ -2,7 +2,7 @@
 linkTitle: No-Op
 --->
 
-# Logs Bridge API No-Op Implementation
+# Logs API No-Op Implementation
 
 **Status**: [Stable](../document-status.md)
 
@@ -23,12 +23,12 @@ linkTitle: No-Op
 Users of OpenTelemetry need a way to disable the API from actually
 performing any operations. The No-Op OpenTelemetry API implementation
 (henceforth referred to as the No-Op) provides users with this
-functionally. It implements the [OpenTelemetry Logs Bridge API](./bridge-api.md)
+functionally. It implements the [OpenTelemetry Logs API](./api.md)
 so that no telemetry is produced and computation resources are minimized.
 
 All language implementations of OpenTelemetry MUST provide a No-Op.
 
-The [Logs Bridge API](./bridge-api.md) defines components with various operations.
+The [Logs API](./api.md) defines components with various operations.
 All No-Op components MUST NOT hold configuration or operational state. All No-op
 operations MUST accept all defined parameters, MUST NOT validate any arguments
 received, and MUST NOT return any non-empty error or log any message.
@@ -42,7 +42,7 @@ provide the same `LoggerProvider` instances to all creation requests.
 
 ### Logger Creation
 
-New `Logger` instances are always created with a [LoggerProvider](./bridge-api.md#loggerprovider).
+New `Logger` instances are always created with a [LoggerProvider](./api.md#loggerprovider).
 Therefore, `LoggerProvider` MUST allow for the creation of `Logger`s.
 All `Logger`s created MUST be an instance of the [No-Op Logger](#logger).
 
@@ -54,4 +54,4 @@ return the same `Logger` instances to all creation requests.
 ### Emit LogRecord
 
 The No-Op `Logger` MUST allow
-for [emitting LogRecords](./bridge-api.md#emit-a-logrecord).
+for [emitting LogRecords](./api.md#emit-a-logrecord).

specification/logs/sdk.md

@@ -40,7 +40,7 @@
 </details>
 
 Users of OpenTelemetry need a way for instrumentation interactions with the
-OpenTelemetry API to actually produce telemetry. The OpenTelemetry Logging SDK
+[OpenTelemetry API](api.md) to actually produce telemetry. The OpenTelemetry Logging SDK
 (henceforth referred to as the SDK) is an implementation of the OpenTelemetry
 API that provides users with this functionally.
 
@@ -59,9 +59,9 @@ The SDK SHOULD allow the creation of multiple independent `LoggerProviders`s.
 ### Logger Creation
 
 It SHOULD only be possible to create `Logger` instances through a `LoggerProvider`
-(see [Bridge API](bridge-api.md)).
+(see [API](api.md)).
 
-The `LoggerProvider` MUST implement the [Get a Logger API](bridge-api.md#get-a-logger).
+The `LoggerProvider` MUST implement the [Get a Logger API](api.md#get-a-logger).
 
 The input provided by the user MUST be used to create
 an [`InstrumentationScope`](../glossary.md#instrumentation-scope) instance which
@@ -186,7 +186,7 @@ It consists of the following parameters:
   to [No-op Logger](./noop.md#logger).
 
   The value of `disabled` MUST be used to resolve whether a `Logger`
-  is [Enabled](./bridge-api.md#enabled). If `disabled` is `true`, `Enabled`
+  is [Enabled](./api.md#enabled). If `disabled` is `true`, `Enabled`
   returns `false`. If `disabled` is `false`, `Enabled` returns `true`. It is not
   necessary for implementations to ensure that changes to `disabled` are
   immediately visible to callers of `Enabled`. I.e. atomic, volatile,
@@ -207,7 +207,7 @@ associated with the `LogRecord`.
 
 The [trace context fields](./data-model.md#trace-context-fields) MUST be populated from
 the resolved `Context` (either the explicitly passed `Context` or the
-current `Context`) when [emitted](./bridge-api.md#emit-a-logrecord).
+current `Context`) when [emitted](./api.md#emit-a-logrecord).
 
 Counts for attributes due to collection limits MUST be available for exporters
 to report as described in
@@ -311,7 +311,7 @@ components in the SDK:
 
 #### OnEmit
 
-`OnEmit` is called when a `LogRecord` is [emitted](bridge-api.md#emit-a-logrecord). This
+`OnEmit` is called when a `LogRecord` is [emitted](api.md#emit-a-logrecord). This
 method is called synchronously on the thread that emitted the `LogRecord`,
 therefore it SHOULD NOT block or throw exceptions.
 

specification/logs/supplementary-guidelines.md

@@ -1,7 +1,7 @@
 # Supplementary Guidelines
 
 Note: this document is NOT a spec, it is provided to support the Logs
-[API](./bridge-api.md) and [SDK](./sdk.md) specifications, it does NOT add any
+[API](./api.md) and [SDK](./sdk.md) specifications, it does NOT add any
 extra requirements to the existing specifications.
 
 <details>
@@ -34,8 +34,8 @@ and is [one of the supported](README.md#direct-to-collector) log collection
 approaches.
 
 The log appender implementation will typically acquire a
-[Logger](./bridge-api.md#logger), then
-call [Emit LogRecord](./bridge-api.md#emit-a-logrecord) for `LogRecord`s
+[Logger](./api.md#logger), then
+call [Emit LogRecord](./api.md#emit-a-logrecord) for `LogRecord`s
 received from the application.
 
 [Implicit Context Injection](#implicit-context-injection)
@@ -62,7 +62,7 @@ popular logging library.
 If the logging library has a concept that is similar to OpenTelemetry's
 definition of the [Instrumentation Scope's](../glossary.md#instrumentation-scope)
 name, then the appender's implementation should use that value as the
-name parameter when [obtaining the Logger](./bridge-api.md#get-a-logger).
+name parameter when [obtaining the Logger](./api.md#get-a-logger).
 
 This is for example applicable to:
 
@@ -72,7 +72,7 @@ This is for example applicable to:
 Appenders should avoid setting any attributes of the Instrumentation Scope.
 Doing so may result in different appenders setting different attributes on the
 same Instrumentation Scope, obtained with the same identity of the
-[Logger](./bridge-api.md#get-a-logger), which, according to the specification,
+[Logger](./api.md#get-a-logger), which, according to the specification,
 is an error.
 
 ### Context
@@ -81,13 +81,13 @@ is an error.
 
 When Context is implicitly available (e.g. in Java) the Appender can rely on
 automatic context propagation by NOT explicitly setting `Context` when
-calling [emit a LogRecord](./bridge-api.md#emit-a-logrecord).
+calling [emit a LogRecord](./api.md#emit-a-logrecord).
 
 Some log libraries have mechanisms specifically tailored for injecting
 contextual information into logs, such as MDC in Log4j. When available, it may
 be preferable to use these mechanisms to set the Context. A log appender can
 then fetch the Context and explicitly set it when
-calling [emit a LogRecord](./bridge-api.md#emit-a-logrecord). This allows the correct Context
+calling [emit a LogRecord](./api.md#emit-a-logrecord). This allows the correct Context
 to be included even when log records are emitted asynchronously, which can
 otherwise lead the Context to be incorrect.
 
@@ -100,7 +100,7 @@ In order for `TraceContext` to be recorded in `LogRecord`s in languages where
 the Context must be provided explicitly (e.g. Go), the end user must capture the
 Context and explicitly pass it to the logging subsystem. The log appender must
 take this Context and explicitly set it when
-calling [emit a LogRecord](./bridge-api.md#emit-a-logrecord).
+calling [emit a LogRecord](./api.md#emit-a-logrecord).
 
 Support for OpenTelemetry for logging libraries in these languages typically can
 be implemented in the form of logger wrappers that can capture the context once,