How to disable or customize telemetry?

[roeih-opti]

Hi,

I've noticed that telemetry collection is enabled by default in the SDK.
Unlike azure-sdk-for-go, I couldn't find a way to opt out or configure it.

The closest workaround I’ve found is to inject my own telemetry (and tracing) by customizing the HTTP transport, but it feels a bit awkward, as the transport is created and then replaced:

authProvider, _ := authentication.NewAzureIdentityAuthenticationProviderWithScopes(credential, scopes)
clientOptions := graph.GetDefaultClientOptions()
middleware := graphcore.GetDefaultMiddlewaresWithOptions(&clientOptions)
httpClient := khttp.GetDefaultClient(middleware...)
httpClient.Transport = khttp.NewCustomTransportWithParentTransport(myTransport, middleware...)
adapter, _ := graph.NewGraphRequestAdapterWithParseNodeFactoryAndSerializationWriterFactoryAndHttpClient(authProvider, nil, nil, httpClient)

Is there a way to:

1. Disable the default telemetry collection or customize it?
2. Cleanly set a custom HTTP transport before the default one is initialized?

Thanks!

[baywet]

HI @roeih-opti
Thank you for using the SDK and for reaching out.

That's the only way to achieve this at the moment.

But in the bigger picture, I'd strongly advise AGAINST disabling telemetry. This additional header is effectively the ONLY way our management knows whether people are using the SDKs. The lower the numbers the least incentive they have to invest in staffing to: publish weekly releases on time, triage GitHub issues, fix bugs, or even implement new features. This in turns puts your application in danger, since it has a dependency that you're actively contributing to reduce funding for, and which might get defunded/unmaintained as a consequence.

If the concern is performance, the header itself is minimal, and with things like headers compression in HTTP/2, the difference is negligeable. If the concern is privacy, this is already reaching out to a service you don't own. And the only use of this header is in aggregates (how many active users/tenants/applications depend on the SDK).

Let us know if you have any additional comments or questions.

[roeih-opti]

Hi @baywet,
Thanks for your detailed response!

Just to clarify, I’m not looking to disable the telemetry header, and performance or privacy aren’t big concerns in this case.
My main goal is to have more control over the OpenTelemetry spans generated by the SDK. Specifically, I’d like to be able to add custom spans and suppress some of the default ones that are too noisy for our use case.

I’m using a custom OTel-instrumented HTTP transport that better aligns with the schema and verbosity of our other instrumented HTTP traffic.

Is there a recommended way to achieve this?

Thanks again!

[roeih-opti]

Thanks for pointing to the previous discussion for Java, specifically:

existing configuration ability:

• handlers are paired with an option type
• request adapter accepts a lot of parameters
• so does the authentication provider

I looked into the Go equivalents in kiota-http-go.

For the third bullet (authentication provider configuration), I’m already passing credential options like this:

credential, err := azidentity.NewClientSecretCredential(
		tenantID,
		clientID,
		clientSecret,
		&azidentity.ClientSecretCredentialOptions{
			ClientOptions: azpolicy.ClientOptions{
				Telemetry: azpolicy.TelemetryOptions{
					Disabled: true,
				},
				Transport: myHTTPClient,
			},
		},
	)

Regarding the first and second bullets (configuring handlers and request adapter options), it seems that some parts of the kiota Go implementation can accept observability-related options. However, I haven't found a clear way to set those when creating a Graph service client or a request adapter.

Could you clarify how this type of customization is intended to be handled in the Go SDK? Or is there a recommended pattern for injecting such configuration during client setup?

Thanks!

[baywet]

If I understand your question correctly, the handlers options are meant to be passed here

middleware := graphcore.GetDefaultMiddlewaresWithOptions(&clientOptions)

as for the options for the request adapter, it's meant to be passed to the request adapter constructor, but it's possible we forgot to add an overload in the Microsoft Graph core layer.

[roeih-opti]

If I understand your question correctly, the handlers options are meant to be passed here

middleware := graphcore.GetDefaultMiddlewaresWithOptions(&clientOptions)

Yes, as shown in my initial post, I’m already passing the options this way. However, GraphClientOptions appears to only include versioning information and doesn't expose any settings that would impact OTel behavior.

as for the options for the request adapter, it's meant to be passed to the request adapter constructor, but it's possible we forgot to add an overload in the Microsoft Graph core layer.

Understood. Given that, what are my current options for configuring the request adapter? Is there a workaround to safely set the request adapter's OTel configuration until the overload is added?

[baywet]

Yes, as shown in my initial post, I’m already passing the options this way. However, GraphClientOptions appears to only include versioning information and doesn't expose any settings that would impact OTel behavior.

I'm suggesting these additional settings need to be added in the options, and then read in the handlers.

Understood. Given that, what are my current options for configuring the request adapter? Is there a workaround to safely set the request adapter's OTel configuration until the overload is added?

This overload https://github.com/microsoft/kiota-http-go/blob/cc4e1f859ef6acab1bc8e1911b969e02d79d8fb6/nethttp_request_adapter.go#L74

Is not available here

https://github.com/microsoftgraph/msgraph-sdk-go-core/blob/5788ec71a9ba7bac78a1a24598378706a5b322e3/graph_request_adapter_base.go#L33

Neither there

msgraph-sdk-go/graph_request_adapter.go

Line 67 in e03f044

func NewGraphRequestAdapterWithParseNodeFactoryAndSerializationWriterFactoryAndHttpClient(authenticationProvider absauth.AuthenticationProvider, parseNodeFactory absser.ParseNodeFactory, serializationWriterFactory absser.SerializationWriterFactory, httpClient *nethttp.Client) (*GraphRequestAdapter, error) {

The best way forward for you is probably to send pull requests in all 3 (beta as well) repos to fix that gap.

[roeih-opti]

Hi @baywet,

After looking more closely at kiota-http-go, I’ve realized the changes needed are broader than we’re willing to take on at the moment.

I’ll keep an eye out for any roadmap item or issue that tracks first-class OTel configuration support. If one already exists, please let me know and I’ll be happy to add our use case and upvote it.

Thanks again for your help!