Is Application Insight's TelemetryClient Thread Safe?

TelemetryClient is thread safe. A valid usage is to create a singleton and reuse it. You will not run into issues reusing an instance.

The MSDN Docs are frequently incorrect when they say a given class is not thread-safe. I'm not sure how people have to flag their code to get those docs to reflect a class's thread-safety, but I've seen numerous instances where those docs are incorrect.

The current version of the Azure article you linked says:

TelemetryClient is thread-safe.

For ASP.NET and Java projects, incoming HTTP Requests are automatically captured. You might want to create additional instances of TelemetryClient for other module of your app. For instance, you may have one TelemetryClient instance in your middleware class to report business logic events. You can set properties such as UserId and DeviceId to identify the machine. This information is attached to all events that the instance sends.

TelemetryClient.Context.User.Id = "...";TelemetryClient.Context.Device.Id = "...";

That last bit is extremely important. Even though the class is thread-safe, if you are writing something like a web application where the UserId might change, you should probably reuse an instance of the telemetry client for each scope in which these values would all be the same (like each Request), but not as a static/singleton instance.

Update

In ASP.NET Core, Application Insights makes heavy use of dependency injection and registers TelemetryClient as a singleton! As explained in the docs:

We don't recommend creating new TelemetryClient instances in an ASP.NET Core application. A singleton instance of TelemetryClient is already registered in the DependencyInjection container, which shares TelemetryConfiguration with rest of the telemetry. Creating a new TelemetryClient instance is recommended only if it needs a configuration that's separate from the rest of the telemetry.

This means you should avoid setting variables on the client context which you don't want to be used throughout the application, and instead leverage Telemetry Initializers to set things like the user ID on each telemetry object.