-
Notifications
You must be signed in to change notification settings - Fork 780
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[api-logs] Define OTEL1000 & OTEL1001 diagnostics and decorate APIs #4963
Merged
CodeBlanch
merged 22 commits into
open-telemetry:main
from
CodeBlanch:api-log-diagnostics
Dec 8, 2023
Merged
Changes from 17 commits
Commits
Show all changes
22 commits
Select commit
Hold shift + click to select a range
ab42bd4
Define OT1000 & OT1001 diagnostics and decorate APIs in OpenTelemetry…
CodeBlanch 87361d6
Revert accidental changes.
CodeBlanch e5a1401
Merge branch 'main' into api-log-diagnostics
CodeBlanch 8ccc64f
Code review.
CodeBlanch 843f394
Merge from main.
CodeBlanch 3d470e6
Merge branch 'api-log-diagnostics' of https://github.com/CodeBlanch/o…
CodeBlanch 1516d1a
Warning cleanup.
CodeBlanch ba9d4ef
Merge branch 'main' into api-log-diagnostics
CodeBlanch 2bc3bf2
Typo fix.
CodeBlanch 8b65c4f
Merge branch 'main' into api-log-diagnostics
CodeBlanch b13fac2
Merge branch 'main' into api-log-diagnostics
utpilla d1a3bab
Code review.
CodeBlanch 1de3258
Code review.
CodeBlanch ac80204
Tweaks.
CodeBlanch 2ae36f4
Merge branch 'api-log-diagnostics' of https://github.com/CodeBlanch/o…
CodeBlanch 5b6281f
Rename landing doc to be plural.
CodeBlanch 7d90823
Lint.
CodeBlanch f76bba1
Update docs/diagnostics/EXPERIMENTAL_APIS.md
CodeBlanch 982bb68
Merge remote-tracking branch 'upstream/main' into api-log-diagnostics
CodeBlanch 09dec3a
Copyright header updates.
CodeBlanch 54b5bdc
Code review.
CodeBlanch 749ee6e
Merge branch 'main' into api-log-diagnostics
CodeBlanch File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# OpenTelemetry .NET Experimental APIs | ||
|
||
This document describes experimental APIs exposed in OpenTelemetry .NET | ||
pre-relase builds. APIs are exposed experimentally when either the OpenTelemetry | ||
Specification has explicitly marked some feature as | ||
[experimental](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/document-status.md) | ||
or when the SIG members are still working through the design for a feature and | ||
want to solicit feedback from the community. | ||
|
||
> **Note** | ||
> Experimental APIs are exposed as `public` in pre-release builds and `internal` | ||
> in stable builds. | ||
|
||
## Active | ||
|
||
Experimental APIs available in the pre-release builds: | ||
|
||
### OTEL1000 | ||
|
||
Description: `LoggerProvider` and `LoggerProviderBuilder` | ||
|
||
Details: [OTEL1000](./OTEL1000.md) | ||
|
||
### OTEL1001 | ||
|
||
Description: Log Bridge API | ||
|
||
Details: [OTEL1000](./OTEL1001.md) | ||
CodeBlanch marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Inactive | ||
|
||
Experimental APIs which have been released stable or removed: | ||
|
||
<!-- When an experimental API is released or removed: | ||
1) Move the section from above down here. | ||
2) Delete the individual file from the repo and switch the link here to a | ||
permalink to the last version. | ||
3) Add the version info for when the API was released stable or removed. If | ||
removed add details for alternative solution or reasoning. | ||
--> | ||
|
||
None |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# OpenTelemetry .NET Diagnostic: OTEL1000 | ||
|
||
## Overview | ||
|
||
This is an Experimental API diagnostic covering the following APIs: | ||
|
||
* `LoggerProviderBuilder` | ||
* `LoggerProvider` | ||
* `IDeferredLoggerProviderBuilder` | ||
|
||
Experimental APIs may be changed or removed in the future. | ||
|
||
## Details | ||
|
||
The OpenTelemetry Specification defines a `LoggerProvider` as part of its | ||
[API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md) | ||
& | ||
[SDK](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/sdk.md) | ||
components. | ||
|
||
The SDK allows calling `Shutdown` and `ForceFlush` on the `LoggerProvider` and | ||
also allows processors to be added dynamically to a pipeline after its creation. | ||
|
||
Today the OpenTelemetry .NET log pipeline is built on top of the | ||
Microsoft.Extensions.Logging `ILogger` \ `ILoggerProvider` \ `ILoggerFactory` | ||
APIs which do not expose such features. | ||
|
||
We also have an issue with the `ILoggingBuilder.AddOpenTelemetry` API in that it | ||
interacts with the `OpenTelemetryLoggerOptions` class. Options classes are NOT | ||
available until the `IServiceProvider` is available and services can no longer | ||
be registered at that point. This prevents the current logging pipeline from | ||
exposing the same dependency injection surface we have for traces and metrics. | ||
|
||
We are exposing these APIs to solve these issues and gather feedback about their | ||
usefulness. | ||
|
||
## Log Bridge API | ||
|
||
The OpenTelemetry Specification defines a Log Bridge API which is rooted off of | ||
the `LoggerProvider` (`GetLogger`) and exposes a `Logger` API to submit log | ||
records. See [OTEL1001](.\OTEL1001.md) for details about the Log Bridge API | ||
implementation status. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
# OpenTelemetry .NET Diagnostic: OTEL1001 | ||
|
||
## Overview | ||
|
||
This is an Experimental API diagnostic covering the following APIs: | ||
|
||
* `LoggerProvider.GetLogger` | ||
* `Logger` | ||
* `LogRecordAttributeList` | ||
* `LogRecordData` | ||
* `LogRecordSeverity` | ||
|
||
Experimental APIs may be changed or removed in the future. | ||
|
||
## Details | ||
|
||
The OpenTelemetry Specification defines a [Logs Bridge | ||
API](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/bridge-api.md). | ||
|
||
The log bridge API is used by library authors to build log appenders which route | ||
messages from different log frameworks into OpenTelemetry. | ||
|
||
Today the OpenTelemetry .NET log pipeline is built on top of the | ||
Microsoft.Extensions.Logging `ILogger` \ `ILoggerProvider` \ `ILoggerFactory` | ||
APIs. | ||
|
||
We are exposing these APIs gather feedback about their usefulness. An | ||
alternative approach may be taken which would be to append into `ILogger` | ||
instead of OpenTelemetry directly. | ||
|
||
## LoggerProvider API | ||
|
||
The OpenTelemetry Specification defines a `LoggerProvider` API. See | ||
[OTEL1000](.\OTEL1001.md) for details about the `LoggerProvider` implementation | ||
status. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,4 +48,3 @@ services: | |
- GF_FEATURE_TOGGLES_ENABLE=traceqlEditor | ||
ports: | ||
- "3000:3000" | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. unintended? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ya |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed in our meeting a few weeks back anticipating some code taxonomy. A few points of reference for further discussion:
They both take the approach that every 100 or 1000 codes represent a new category of warnings/errors. We could do similar. Another option would be to use a different prefix specifically for feature flags since unlike normal codes, they're ephemeral e.g.,
OTELFF
or something.I have no strong opinions, just sharing additional thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been thinking about this but so far haven't come up with anything super useful. We could always just say the 1XXX codes are for experimental features and use other codes (eg 2XXX) for some future category?