-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Add schema URL support #63651
Comments
Tagging subscribers to this area: @dotnet/area-system-diagnostics-activity Issue Detailsopen-telemetry/opentelemetry-dotnet#2417
|
We are going to wait for finalizing the semantic convention discussion on OpenTelemetry side to know if there will be any effect on this current proposal. We expect to have the feedback by the end of March or early April. |
Just looking at open-telemetry/opentelemetry-dotnet#3445. There are cases where instrumentation does not own the namespace System.Diagnostics
{
public sealed class ActivitySource : IDisposable
{
public ActivitySource(string name, string? version = "") { ... }
+ public ActivitySource(string name, string? version, string? telemetrySchemaUrl) { ... }
public string? Version {
get;
+ set;
}
+ public string? TelemetrySchemaUrl { get; set; }
}
} That would allow (for example) OpenTelemetry instrumentation augmenting the sources to pass along its version + schema url for the schema being augmented. Breaks if users have multiple augmenting libraries/schemas, but may not be a concern? |
@tarekgh I am curious if this was revisited at all with some of the changes made for .NET 8 (e.g. https://github.com/lmolkova/semantic-conventions/blob/dotnet8-metrics/docs/dotnet/dotnet-http-metrics.md). There was a comment that mentioned staying compatible with OTel but I am a bit concerned that this will be hard for consumers to manage if there are additional changes without the existence of schema URL. Do you have any idea when I might be able to expect this change? Speaking from someone whose organization sticks to mainly LTS releases, if this does not make .NET 8 then it becomes hard to manage across various language SDKs. |
@danelson the semantic convention discussion came very late in the 8.0 after passing the point of adding a new API. This is something we can consider for our next release. |
I doubt if this is going to be part of .NET 8 as it is too late. The earliest, hence, would be .NET 9. And I don' think it is relevant that your org recommends LTS only, as this change will be part of I believe the main reason why OTel .NET has not pushed for this to land in .NET 8 was that, the use cases of the schema url are still an experimental spec: (the schema_url part of tracer/meter itself is stable long ago, the above is just the spec about the schemas/ and its transformations etc.) |
Does it mean that we won't get any stable OpenTelemetry .NET instrumentation library before .NET 9 release? Take notice that the schema URL support is required by OpenTelemetry specification since 2021-06-07 (sic!). |
I don't think so. As the instrumentation libraries are expected to move to stable in couple months from what i heard (though there are lot of pending issues) The spec which talks about schema_url usages (transformation etc.)m fixed telemetry schema etc. are still experimental, with no sign of moving to stable. Even if they are needed, it should be possible to not change any schema OR wait until schema_url is available before making any changes. The schema_url could come from .NET itself OR we might leverage Meter attributes. |
But that is not relevant to this issue right? https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/telemetry-stability.md is still experimental, though that does not have to prevent us from adding schema_url support. |
@tarekgh is it in scope for .NET 9? thanks! |
So none of the .NET instrumentation can change after they are declared stable until at least .NET 10? Sounds like we're going to break this rule a lot. |
open-telemetry/opentelemetry-dotnet#2417
https://github.com/open-telemetry/opentelemetry-specification/pull/1666/files
Telemetry sources such as instrumented applications and consumers of telemetry such as observability backends sometimes make implicit assumptions about the emitted telemetry. They assume that the telemetry will contain certain attributes or otherwise have a certain shape and composition of data. Essentially there is a coupling between 3 parties: OpenTelemetry semantic conventions, telemetry sources and telemetry consumers. The coupling complicates the independent evolution of these 3 parties. The 3 parties should be able to evolve independently over time and Telemetry Schemas are central to how we make this possible.
Proposal
Usage
The text was updated successfully, but these errors were encountered: