Discover Good First Issues for open-telemetry/opentelemetry-dotnet

[feature request] Add support to 'add links' to TelemetrySpan as it was added to Activity in .net9 Created: 2024-12-18T18:21:41Z

Package

OpenTelemetry

Is your feature request related to a problem?

I want to be able to add span links to already created spans. This ability was recently added to System.Diagnostics.Activity (see AddLinks method)

What is the expected behavior?

Add ‘AddLinks’ method to TelemetrySpan

Which alternative solutions or features have you considered?

Right now I use a Activity directly, but would like to use the shim

E.g.

// todo: replace with shim implementation as soon as AddLink is available Activity currentActivity = Activity.Current!; currentActivity.AddLink(new ActivityLink(span.Context));

Additional context

No response

Comments: 0

[feature request] Support for adding default tags to specific Tracer Created: 2024-12-10T00:45:25Z

Package

OpenTelemetry

Is your feature request related to a problem?

For example, I have multiple instances of an app which have different configurations. I’d like to tag those differences in spans. The request is similar to this one (https://github.com/dotnet/runtime/issues/84321) but for tracing.

What is the expected behavior?

In .net9 System.Diagnostics.ActivitySource got new ctor overload which has the ‘tags’: public ActivitySource(string name, string? version = “”, IEnumerable>? tags = default)

Please add similar overload to TracerProvider.GetTracer

Which alternative solutions or features have you considered?

I can use System.Diagnostics.ActivitySource but I’d like to use the shim.

Additional context

No response

Comments: 0

[doc] Improve wording regarding to overflow attribute once cardinality limit is reached for easier understanding for end-users Created: 2024-10-30T21:56:40Z

Package

OpenTelemetry

Is your feature request related to a problem?

According to the spec https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#overflow-attribute, once cardinality limit is reached, the measurements could not be “independently aggregated”, but it’s not called “dropped”. What happens is a “synthetic aggregation”:

An overflow attribute set is defined, containing a single attribute otel.metric.overflow having (boolean) value true, which is used to report a synthetic aggregation of the Measurements that could not be independently aggregated because of the limit.

This can be confusing to end-users.

I’m opening this issue to track @cijothomas’ suggestion for improvement at https://github.com/open-telemetry/opentelemetry-dotnet/pull/5909#discussion_r1817686949:

Agree that the wording may not easily be understood by all end-users. The https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics#cardinality-limits doc is very good, and perhaps we can make some additions to it to explain how the sdk behaves when limit is hit, and how to interpret overflow attribute correctly.

One important think I’d like called out is, if user has a query like sum of all requests, where route=foo, and an overflow exists - then that query is no longer trustable, as there is no way to tell if a route=foo measurement was folded into overflow. The only thing trustable in the event an overflow exists is the total metrics (i.e the one which do not filter based on any dimensions).

If none volunteers to make this change in the doc, I can cover it. (I am implementing similar thing for OTel Rust right now, so I can hopefully steal some wordings! Ideally this should be covered in otel docs website, so every language can benefit) https://github.com/utpilla/MetricOverflowAttribute?tab=readme-ov-file can be a good starting point.

What is the expected behavior?

N/A

Which alternative solutions or features have you considered?

N/A

Additional context

No response

Comments: 0

[feature request] Being able to filter logs like activities with a processor Created: 2024-10-25T12:56:11Z

Package

OpenTelemetry

Is your feature request related to a problem?

Is it possible to give the possibility to custom processors to be able to filter “logs” as it is already possible with custom processors on “activities”?

What is the expected behavior?

Example:

/// <summary>
///     Represents the processor for filtering logs on <see cref="LogRecord"/> if is necessary.
/// </summary>
public class FilterLogsProcessor : BaseProcessor<LogRecord>
{
/// <inheritdoc/>
public override void OnEnd(LogRecord data)
{
var pathAttributeValue = data.Attributes?.FirstOrDefault(attribute => attribute.Key == "Path").Value?.ToString();
if (!string.IsNullOrEmpty(pathAttributeValue)
&& (pathAttributeValue.Contains("liveness") || pathAttributeValue.Contains("health") || pathAttributeValue.Contains("metrics")))
{
// TODO: Configure the log record here, so that it is not exported
}

var endpointNameAttributeValue = data.Attributes?.FirstOrDefault(attribute => attribute.Key == "EndpointName").Value?.ToString();
if (!string.IsNullOrEmpty(endpointNameAttributeValue)
&& (endpointNameAttributeValue.Contains("Health")))
{
// TODO: Configure the log record here, so that it is not exported
}

base.OnEnd(data);
}
}

Which alternative solutions or features have you considered?

At the moment, we have not found any workaround to avoid polluting our Azure Application Insights with the logs of our healthchecks

Additional context

We use the Azure Monitor exporter as follows:

builder.Logging.AddOpenTelemetry(builder =>
{
builder.SetResourceBuilder(ResourceBuilder.CreateDefault().AddService(TelemetryHelper.ServiceName, serviceInstanceId: TelemetryHelper.ServiceInstanceId));

builder.IncludeFormattedMessage = true;
builder.IncludeScopes = true;
builder.ParseStateValues = true;

builder.AddProcessor(new RemoveExceptionProcessor());
builder.AddProcessor(new FilterLogsProcessor());

builder.AddAzureMonitorLogExporter(options => options.ConnectionString = configuration["AzureMonitor:ApplicationInsights:ConnectionString"]);
});

Comments: 1

Remove the peer service resolver logic from zipkin exporter Created: 2024-12-10T20:52:05Z

Package: OpenTelemetry.Exporter.Zipkin

More Information: https://github.com/open-telemetry/opentelemetry-dotnet/pull/6015/files#r1878832826

Comments: 5

Update documentation for .NET 9 Advice API Created: 2024-09-23T20:26:04Z

Originally posted by @cijothomas in https://github.com/open-telemetry/opentelemetry-dotnet/issues/5854#issuecomment-2368882470

Comments: 2

[docs-metrics] Show AddView API using delegate Created: 2024-04-19T18:03:23Z

See: https://github.com/open-telemetry/opentelemetry-dotnet/pull/5554#issuecomment-2066915358

We should have some sort of advanced documentation which shows the AddView API which exposes a callback/delegate. The important part is strong wording that it isn’t recommended to be used due to failures being swallowed at runtime and only written to self-diagnostic logging.

Comments: 7