Use GFM NOTES syntax (#5219)

This commit is contained in:
Reiley Yang 2024-01-12 15:17:10 -08:00 committed by GitHub
parent b9d09bee5c
commit c78363211e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
20 changed files with 90 additions and 87 deletions

View File

@ -232,7 +232,7 @@ analysis](https://learn.microsoft.com/dotnet/fundamentals/code-analysis/overview
New projects MUST enable static analysis by specifying
`<AnalysisLevel>latest-all</AnalysisLevel>` in the project file (`.csproj`).
> **Note**
> [!NOTE]
> There are other project-level features enabled automatically via
[Common.props](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/build/Common.props)
new projects must NOT manually override these settings.
@ -248,7 +248,7 @@ context in every project by updating code as it is worked on, this requirement
is to make sure the surface area of code needing updates is shrinking and not
expanding.
> **Note**
> [!NOTE]
> The first time a project is updated to use nullable context in public APIs
some housekeeping needs to be done in public API definitions (`.publicApi`
folder). This can be done automatically via a code fix offered by the public API

View File

@ -16,8 +16,9 @@ explicitly marked some feature as
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.
> [!NOTE]
> Experimental APIs are exposed as `public` in pre-release builds and `internal`
in stable builds.
For defined diagnostics see: [OpenTelemetry .NET Experimental
APIs](./experimental-apis/README.md)

View File

@ -7,9 +7,9 @@ Specification has explicitly marked some feature as
or when the SIG members are still working through the design for a feature and
want to solicit feedback from the community.
> **Note**
> [!NOTE]
> Experimental APIs are exposed as `public` in pre-release builds and `internal`
> in stable builds.
in stable builds.
## Active

View File

@ -125,7 +125,7 @@ generic `ILogger<T>` is not an option, `app.Logger` is used instead:
app.Logger.StartingApp();
```
> **Note**
> [!NOTE]
> There are cases where logging is needed before the [dependency injection
(DI)](https://learn.microsoft.com/dotnet/core/extensions/dependency-injection)
logging pipeline is available (e.g. before `builder.Build()`) or after the DI

View File

@ -97,7 +97,7 @@ public static partial class ApplicationLogs
}
```
> **Note**
> [!NOTE]
> For applications which use `ILogger` with [dependency injection
(DI)](https://learn.microsoft.com/dotnet/core/extensions/dependency-injection)
(e.g. [ASP.NET Core](https://learn.microsoft.com/aspnet/core) and [.NET

View File

@ -102,7 +102,7 @@ using var meterProvider = Sdk.CreateMeterProviderBuilder()
See [Program.cs](./Program.cs) for complete example.
> **Note**
> [!NOTE]
> A common mistake while configuring `MeterProvider` is forgetting to
add the required `Meter`s to the provider. It is recommended to leverage the
wildcard subscription model where it makes sense. For example, if your
@ -323,7 +323,7 @@ within the maximum number of buckets defined by `MaxSize`. The default
})
```
> **Note**
> [!NOTE]
> The SDK currently does not support any changes to `Aggregation` type
by using Views.
@ -377,7 +377,7 @@ ignored. The SDK chooses the key/value combinations in the order in which they
are emitted. `SetMaxMetricPointsPerMetricStream` can be used to override the
default.
> **Note**
> [!NOTE]
> One `MetricPoint` is reserved for every `MetricStream` for the
special case where there is no key/value pair associated with the metric. The
maximum number of `MetricPoint`s has to accommodate for this special case.
@ -444,7 +444,7 @@ AnotherFruitCounter.Add(5, new("name", "banana"), new("color", "yellow")); // Ex
AnotherFruitCounter.Add(4, new("name", "mango"), new("color", "yellow")); // Not exported
```
> **Note**
> [!NOTE]
> The above limit is *per* metric stream, and applies to all the metric
streams. There is no ability to apply different limits for each instrument at
this moment.
@ -503,7 +503,7 @@ using var meterProvider = Sdk.CreateMeterProviderBuilder()
.Build();
```
> **Note**
> [!NOTE]
> As of today, there is no separate toggle for enable/disable Exemplar feature.
Exemplars can be disabled by setting filter as `AlwaysOffExemplarFilter`, which
is also the default (i.e Exemplar feature is disabled by default). Users can
@ -538,7 +538,7 @@ reservoir](https://en.wikipedia.org/wiki/Reservoir_sampling). The reservoir pool
size (currently defaulting to 1) determines the maximum number of exemplars
stored.
> **Note**
> [!NOTE]
> Currently there is no ability to change or configure Reservoir.
### Instrumentation

View File

@ -78,7 +78,7 @@ appBuilder.Services.AddOpenTelemetry()
);
```
> **Note**
> [!NOTE]
> The `AddOpenTelemetry` extension is part of the
[OpenTelemetry.Extensions.Hosting](../../../src/OpenTelemetry.Extensions.Hosting/README.md)
package.

View File

@ -37,7 +37,7 @@ appBuilder.Services.AddOpenTelemetry()
.WithTracing(builder => builder.AddConsoleExporter());
```
> **Note**
> [!NOTE]
> The
[AddOpenTelemetry](../../../src/OpenTelemetry.Extensions.Hosting/README.md#extension-method-reference)
extension automatically starts and stops the `TracerProvider` with the host.
@ -51,7 +51,7 @@ required.
Call `Sdk.CreateTracerProviderBuilder()` to obtain a builder and then call
`Build()` once configuration is done to retrieve the `TracerProvider` instance.
> **Note**
> [!NOTE]
> Once built changes to `TracerProvider` configuration are not allowed,
with the exception of adding more processors.
@ -128,7 +128,7 @@ var tracerProvider = Sdk.CreateTracerProviderBuilder()
See [Program.cs](./Program.cs) for complete example.
> **Note**
> [!NOTE]
> A common mistake while configuring `TracerProvider` is forgetting to
add all `ActivitySources` to the provider. It is recommended to leverage the
wild card subscription model where it makes sense. For example, if your
@ -173,7 +173,7 @@ processor classes `SimpleExportProcessor` & `BatchExportProcessor` are provided
to support invoking exporters through the processor pipeline and implement the
standard behaviors prescribed by the OpenTelemetry specification.
> **Note**
> [!NOTE]
> The SDK only ever invokes processors and has no direct knowledge of
any registered exporters.
@ -196,13 +196,13 @@ var tracerProvider = Sdk.CreateTracerProviderBuilder()
tracerProvider.AddProcessor(new MyProcessor3());
```
> **Note**
> [!NOTE]
> The order of processor registration is important. Each processor added
is invoked in order by the SDK. For example if a simple exporting processor is
added before an enrichment processor the exported data will not contain anything
added by the enrichment because it happens after the export.
<!-- This comment is to make sure the two notes above and below are not merged -->
> **Note**
> [!NOTE]
> A `TracerProvider` assumes ownership of **all** processors added to
it. This means that the provider will call the `Shutdown` method on all
registered processors when it is shutting down and call the `Dispose` method on
@ -238,13 +238,13 @@ For exporting purposes, the SDK provides the following built-in processors:
: This is an exporting processor which passes telemetry to the configured
exporter immediately without any batching.
> **Note**
> [!NOTE]
> A special processor
[CompositeProcessor&lt;T&gt;](../../../src/OpenTelemetry/CompositeProcessor.cs)
is used by the SDK to chain multiple processors together and may be used as
needed by users to define sub-pipelines.
<!-- This comment is to make sure the two notes above and below are not merged -->
> **Note**
> [!NOTE]
> The processors shipped from this SDK are generic implementations and support
tracing and logging by implementing `Activity` and `LogRecord` respectively.
@ -382,7 +382,7 @@ Sdk.SetDefaultTextMapPropagator(new MyCustomPropagator());
## Dependency injection support
> **Note**
> [!NOTE]
> This information applies to the OpenTelemetry SDK version 1.4.0 and
newer only.
@ -427,14 +427,14 @@ When using the `Sdk.CreateTracerProviderBuilder` method the `TracerProvider`
owns its own `IServiceCollection`. It will only be able to see services
registered into that collection.
> **Note**
> [!NOTE]
> It is important to correctly manage the lifecycle of the
`TracerProvider`. See [Building a TracerProvider](#building-a-tracerprovider)
for details.
#### Using the OpenTelemetry.Extensions.Hosting package
> **Note**
> [!NOTE]
> If you are authoring an [ASP.NET Core
application](https://learn.microsoft.com/aspnet/core/fundamentals/host/web-host)
or using the [.NET Generic
@ -463,7 +463,7 @@ which is used to automatically start the `TracerProvider` when the host starts
and the host will automatically shutdown and dispose the `TracerProvider` when
it is shutdown.
> **Note**
> [!NOTE]
> Multiple calls to `WithTracing` will configure the same
`TracerProvider`. Only a single `TraceProvider` may exist in an
`IServiceCollection` \ `IServiceProvider`.
@ -488,7 +488,7 @@ it is shutdown.
* `ConfigureServices`: Registers a callback function for configuring the
`IServiceCollection` used by the `TracerProviderBuilder`.
> **Note**
> [!NOTE]
> `ConfigureServices` may only be called before the `IServiceProvider`
has been created after which point services can no longer be added.
@ -499,7 +499,7 @@ it is shutdown.
implementationFactory)`: Adds a sampler into the `TracerProvider` using a
factory function to create the sampler instance.
> **Note**
> [!NOTE]
> The factory functions accepting `IServiceProvider` may always be used
regardless of how the SDK is initialized. When using an external service
collection (ex: `appBuilder.Services.AddOpenTelemetry()`), as is common in
@ -510,7 +510,7 @@ build an `IServiceProvider` from it to make available to extensions.
## Configuration files and environment variables
> **Note**
> [!NOTE]
> This information applies to the OpenTelemetry SDK version 1.4.0 and
newer only.
@ -575,7 +575,7 @@ variables users may also manage these settings via the command-line,
configuration files, or any other source registered with the .NET configuration
engine. This provides greater flexibility than what the specification defines.
> **Note**
> [!NOTE]
> Not all of the environment variables defined in the specification are
supported. Consult the individual project README files for details on specific
environment variable support.
@ -610,7 +610,7 @@ environment variables.
dotnet run --OTEL_SERVICE_NAME "MyService"
```
> **Note**
> [!NOTE]
> The [.NET
Configuration](https://learn.microsoft.com/dotnet/core/extensions/configuration)
pattern is hierarchical meaning the order of registered configuration sources

View File

@ -123,7 +123,7 @@ guidelines.
This section describes the steps required to write a custom instrumentation
library.
> **Note**
> [!NOTE]
> If you are writing a new library or modifying an existing library the
recommendation is to use the [ActivitySource API/OpenTelemetry
API](../../../src/OpenTelemetry.Api/README.md#introduction-to-opentelemetry-net-tracing-api)
@ -206,7 +206,7 @@ Writing an instrumentation library typically involves 3 steps.
can enable it by calling `AddSource` on the `TracerProviderBuilder`
being configured.
> **Note**
> [!NOTE]
> Changing the name of the source should be considered a
breaking change.
@ -357,7 +357,7 @@ A demo ResourceDetector is shown [here](./MyResourceDetector.cs).
## Registration extension method guidance for library authors
> **Note**
> [!NOTE]
> This information applies to the OpenTelemetry SDK version 1.4.0 and
newer only.
@ -366,7 +366,7 @@ register custom OpenTelemetry components into their `TracerProvider`s. These
extension methods can target either the `TracerProviderBuilder` or the
`IServiceCollection` classes. Both of these patterns are described below.
> **Note**
> [!NOTE]
> Libraries providing SDK plugins such as exporters, resource detectors,
and/or samplers should take a dependency on the [OpenTelemetry SDK
package](https://www.nuget.org/packages/opentelemetry). Library authors
@ -402,7 +402,7 @@ When providing registration extensions:
from starting. The OpenTelemetry SDK is allowed to crash if it cannot be
started. It **MUST NOT** crash once running.
> **Note**
> [!NOTE]
> The SDK implementation of `TracerProviderBuilder` ensures that the
[.NET
Configuration](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration)
@ -631,7 +631,7 @@ single `AddMyLibrary` extension to configure the library itself and optionally
turn on OpenTelemetry integration for multiple signals (tracing & metrics in
this case).
> **Note**
> [!NOTE]
> `ConfigureOpenTelemetryTracerProvider` and
`ConfigureOpenTelemetryMeterProvider` do not automatically start OpenTelemetry.
The host is responsible for either calling `AddOpenTelemetry` in the

View File

@ -78,7 +78,7 @@ builder.Services.AddOpenTelemetry()
.AddConsoleExporter());
```
> **Note**
> [!NOTE]
> The `AddOpenTelemetry` extension is part of the
[OpenTelemetry.Extensions.Hosting](../../../src/OpenTelemetry.Extensions.Hosting/README.md)
package.

View File

@ -452,8 +452,9 @@ and
[extract](../../examples/MicroserviceExample/Utils/Messaging/MessageReceiver.cs)
context.
**Note on instrumentation libraries**: If you are using the instrumentation
libraries shipped from this repo [e.g. [ASP.NET
> [!NOTE]
> If you are using the instrumentation libraries shipped from this repo [e.g.
[ASP.NET
Core](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Instrumentation.AspNetCore)
or
[HttpClient](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Instrumentation.Http)],
@ -503,7 +504,7 @@ Windows-based .NET implementation).
The above requires import of the `System.Diagnostics.Metrics` namespace.
> **Note**
> [!NOTE]
> It is important to note that `Meter` instances are created by
using its constructor, and *not* by calling a `GetMeter` method on the
`MeterProvider`. This is an important distinction from the [OpenTelemetry

View File

@ -6,7 +6,7 @@
The console exporter prints data to the Console window.
ConsoleExporter supports exporting logs, metrics and traces.
> **Note**
> [!NOTE]
> This exporter is intended to be used during learning how telemetry
data are created and exported. It is not recommended for any production
environment.

View File

@ -75,7 +75,7 @@ customize the `LogRecordExportProcessorOptions` or see the [Environment
Variables](#environment-variables) section below on how to customize using
environment variables.
> **Note**
> [!NOTE]
> For details on how to configure logging with OpenTelemetry check the
[Console](../../docs/logs/getting-started-console/README.md) or [ASP.NET
Core](../../docs/logs/getting-started-aspnetcore/README.md) tutorial.
@ -85,7 +85,7 @@ Attributes. Scopes must be enabled at the SDK level using
[IncludeScopes](../../docs/logs/customizing-the-sdk/Readme.md#includescopes)
setting on `OpenTelemetryLoggerOptions`.
> **Note**
> [!NOTE]
> Scope attributes with key set as empty string or `{OriginalFormat}`
are ignored by exporter. Duplicate keys are exported as is.
@ -94,7 +94,7 @@ are ignored by exporter. Duplicate keys are exported as is.
You can configure the `OtlpExporter` through `OtlpExporterOptions`
and environment variables.
> **Note**
> [!NOTE]
> The `OtlpExporterOptions` type setters take precedence over the environment variables.
This can be achieved by providing an `Action<OtlpExporterOptions>` delegate to
@ -132,7 +132,7 @@ appBuilder.Services.AddOptions<OtlpExporterOptions>()
});
```
> **Note**
> [!NOTE]
> The `OtlpExporterOptions` class is shared by logging, metrics, and tracing. To
> bind configuration specific to each signal use the `name` parameter on the
> `AddOtlpExporter` extensions:

View File

@ -7,7 +7,7 @@ An [OpenTelemetry Prometheus exporter](https://github.com/open-telemetry/opentel
for configuring an ASP.NET Core application with an endpoint for Prometheus
to scrape.
> **Note**
> [!NOTE]
> This exporter does not support [OpenMetrics
format](https://github.com/OpenObservability/OpenMetrics), and consequently,
does not support Exemplars. For using Exemplars, use the [OTLP

View File

@ -29,13 +29,13 @@ Targeting `Microsoft.Extensions.DependencyInjection.IServiceCollection`:
[IServiceCollection](https://learn.microsoft.com/dotnet/api/microsoft.extensions.dependencyinjection.iservicecollection)
and then returns an `OpenTelemetryBuilder` class.
> **Note**
> [!NOTE]
> `AddOpenTelemetry` should be called by application host code only. Library
authors see: [Registration extension method guidance for library
authors](../../docs/trace/extending-the-sdk/README.md#registration-extension-method-guidance-for-library-authors).
<!-- This comment is to make sure the two notes above and below are not merged
-->
> **Note**
> [!NOTE]
> Multiple calls to `AddOpenTelemetry` will **NOT** result in multiple
providers. Only a single `TracerProvider` and/or `MeterProvider` will be
created in the target `IServiceCollection`. To establish multiple providers

View File

@ -150,20 +150,20 @@ metrics, you can utilize
[Views](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/customizing-the-sdk#drop-an-instrument)
to achieve this.
**Note:** There is no difference in features or emitted metrics when enabling
metrics using `AddMeter()` or `AddAspNetCoreInstrumentation()` on `.NET8.0` and
newer versions.
> **Note**
> The `http.server.request.duration` metric is emitted in `seconds` as
per the semantic convention. While the convention [recommends using custom
histogram
buckets](https://github.com/open-telemetry/semantic-conventions/blob/release/v1.23.x/docs/http/http-metrics.md)
, this feature is not yet available via .NET Metrics API. A
[workaround](https://github.com/open-telemetry/opentelemetry-dotnet/pull/4820)
has been included in OTel SDK starting version `1.6.0` which applies
recommended buckets by default for `http.server.request.duration`. This
applies to all targeted frameworks.
> [!NOTE]
> There is no difference in features or emitted metrics when enabling metrics
using `AddMeter()` or `AddAspNetCoreInstrumentation()` on `.NET8.0` and newer
versions.
<!-- This comment is to make sure the two notes above and below are not merged -->
> [!NOTE]
> The `http.server.request.duration` metric is emitted in `seconds` as per the
semantic convention. While the convention [recommends using custom histogram
buckets](https://github.com/open-telemetry/semantic-conventions/blob/release/v1.23.x/docs/http/http-metrics.md)
, this feature is not yet available via .NET Metrics API. A
[workaround](https://github.com/open-telemetry/opentelemetry-dotnet/pull/4820)
has been included in OTel SDK starting version `1.6.0` which applies recommended
buckets by default for `http.server.request.duration`. This applies to all
targeted frameworks.
## Advanced configuration

View File

@ -7,7 +7,8 @@ This is an [Instrumentation Library](https://github.com/open-telemetry/opentelem
which instruments [Grpc.Net.Client](https://www.nuget.org/packages/Grpc.Net.Client)
and collects traces about outgoing gRPC requests.
**Note: This component is based on the OpenTelemetry semantic conventions for
> [!NOTE]
> This component is based on the OpenTelemetry semantic conventions for
[traces](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/rpc/rpc-spans.md).
These conventions are
[Experimental](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/document-status.md),
@ -15,7 +16,7 @@ and hence, this package is a [pre-release](../../VERSIONING.md#pre-releases).
Until a [stable
version](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/telemetry-stability.md)
is released, there can be breaking changes. You can track the progress from
[milestones](https://github.com/open-telemetry/opentelemetry-dotnet/milestone/23).**
[milestones](https://github.com/open-telemetry/opentelemetry-dotnet/milestone/23).
## Supported .NET Versions

View File

@ -153,20 +153,20 @@ metrics, you can utilize
[Views](https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/customizing-the-sdk#drop-an-instrument)
to achieve this.
**Note:** There is no difference in features or emitted metrics when enabling
metrics using `AddMeter()` or `AddHttpClientInstrumentation()` on `.NET8.0` and
newer versions.
> **Note**
> The `http.client.request.duration` metric is emitted in `seconds` as
per the semantic convention. While the convention [recommends using custom
histogram
buckets](https://github.com/open-telemetry/semantic-conventions/blob/release/v1.23.x/docs/http/http-metrics.md)
, this feature is not yet available via .NET Metrics API. A
[workaround](https://github.com/open-telemetry/opentelemetry-dotnet/pull/4820)
has been included in OTel SDK starting version `1.6.0` which applies
recommended buckets by default for `http.client.request.duration`. This
applies to all targeted frameworks.
> [!NOTE]
> There is no difference in features or emitted metrics when enabling metrics
using `AddMeter()` or `AddHttpClientInstrumentation()` on `.NET8.0` and newer
versions.
<!-- This comment is to make sure the two notes above and below are not merged -->
> [!NOTE]
> The `http.client.request.duration` metric is emitted in `seconds` as per the
semantic convention. While the convention [recommends using custom histogram
buckets](https://github.com/open-telemetry/semantic-conventions/blob/release/v1.23.x/docs/http/http-metrics.md)
, this feature is not yet available via .NET Metrics API. A
[workaround](https://github.com/open-telemetry/opentelemetry-dotnet/pull/4820)
has been included in OTel SDK starting version `1.6.0` which applies recommended
buckets by default for `http.client.request.duration`. This applies to all
targeted frameworks.
## Advanced configuration

View File

@ -16,7 +16,7 @@ and collects traces about database operations.
the [issue](https://github.com/dotnet/SqlClient/pull/1258). It was fixed in 4.0
and later.
>
> **Note**
> [!NOTE]
> This component is based on the OpenTelemetry semantic conventions for
[traces](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/database-spans.md).
These conventions are
@ -148,7 +148,7 @@ using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.Build();
```
> **Note**
> [!NOTE]
> When using the built-in `System.Data.SqlClient` only stored procedure
command names will ever be captured. When using the `Microsoft.Data.SqlClient`
NuGet package (v1.1+) stored procedure command names, full query text, and other
@ -156,7 +156,7 @@ command text will be captured.
### EnableConnectionLevelAttributes
> **Note**
> [!NOTE]
> EnableConnectionLevelAttributes is supported on all runtimes.
By default, `EnabledConnectionLevelAttributes` is disabled and this
@ -180,7 +180,7 @@ using var tracerProvider = Sdk.CreateTracerProviderBuilder()
### Enrich
> **Note**
> [!NOTE]
> Enrich is supported on .NET and .NET Core runtimes only.
This option can be used to enrich the activity with additional information from
@ -217,7 +217,7 @@ access to `SqlCommand` object.
### RecordException
> **Note**
> [!NOTE]
> RecordException is supported on .NET and .NET Core runtimes only.
This option can be set to instruct the instrumentation to record SqlExceptions
@ -236,7 +236,7 @@ using var tracerProvider = Sdk.CreateTracerProviderBuilder()
### Filter
> **Note**
> [!NOTE]
> Filter is supported on .NET and .NET Core runtimes only.
This option can be used to filter out activities based on the properties of the

View File

@ -5,7 +5,7 @@ This stress test is specifically for Metrics SDK, and is based on the
* [Running the stress test](#running-the-stress-test)
> **Note**
> [!NOTE]
> To run the stress tests for Histogram, comment out the `Run` method
for `Counter` and uncomment everything related to `Histogram` in the
[Program.cs](../OpenTelemetry.Tests.Stress.Metrics/Program.cs).