Skip to content
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

Azure Monitor Exporter - Parse dependency types #15533

Closed

Conversation

rajkumar-rangaraj
Copy link
Contributor

@rajkumar-rangaraj rajkumar-rangaraj commented Sep 29, 2020

  • Added support for azure namespace and component tags
  • Added Event Hub extraction support

[MethodImpl(MethodImplOptions.AggressiveInlining)]
internal static string GetHost(Dictionary<string, string> tags)
{
if (tags != null && tags.TryGetValue(SemanticConventions.AttributeHttpHost, out var host))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will get this as a part of next PR. This changes makes this PR complex.

var testCases = new List<Tuple<string, string, string, Dictionary<string, string>, string>>()
{
// Database operations
Tuple.Create("Create database", "POST", "https://myaccount.documents.azure.com/dbs", defaultProperties, defaultResultCode),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pakrym wish to get your perspective here.

I think we want the DocumentDB SDK to put information indicating the logical operation name, instead of coupling the logic inside the Azure Monitor Exporter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what we have been doing for track 2 SDKs but I'm not sure how much leeway we would have for existing libraries. We might need to keep these implementations for back-compat.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to throw some thoughts here - would it be possible for us to only support track 2 SDKs in this exporter.
Folks who are using legacy SDKs can use ApplicationInsights SDK, and we'll continue to support it until X% of customers move to track 2 SDKs + OpenTelemetry .NET + Azure Monitor Exporter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree we shouldn't do any complex domain specific parsing in the exporter. Its good idea to callout that only track2 SDKs are supported in Otel + this exporter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree we shouldn't do any complex domain specific parsing in the exporter. Its good idea to callout that only track2 SDKs are supported in Otel + this exporter.

Yeah, I think this exporter will only have knowledge about the Azure Monitor schema/endpoint/protocol. It should have no idea what Service Bus, Cosmos DB and Azure Search are.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed all HTTP parsers. Now we check based on az.namespace tag

@rajkumar-rangaraj
Copy link
Contributor Author

These changes should not be part of exporter, it should come from .NET Azure Collector.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants