Use GFM NOTES syntax (#5219)
This commit is contained in:
parent
b9d09bee5c
commit
c78363211e
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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<T>](../../../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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
Loading…
Reference in New Issue