OpenTelemetry

Here is the set of technical interview flashcards covering observability in a .NET project from scratch, both without cloud providers and with AWS, following your exact formatting rules:

Q: What are the core NuGet packages required to set up OpenTelemetry for tracing and metrics in a standard .NET application from scratch (without AWS)?

Answer

To configure open-standard observability from scratch, you need the following core packages:

• OpenTelemetry.Extensions.Hosting (manages the lifecycle inside the .NET generic host)

• OpenTelemetry.Instrumentation.AspNetCore (automatically traces incoming web requests)

• OpenTelemetry.Instrumentation.Http (automatically traces outgoing HTTP client requests)

• OpenTelemetry.Instrumentation.Runtime (collects system metrics like garbage collection and CPU threads)

• OpenTelemetry.Exporter.OpenTelemetryProtocol (exports telemetry using the vendor-neutral OTLP format)

Common Pitfall

Installing only the base OpenTelemetry package. The core library only provides empty abstractions (no-ops); you must explicitly pull in the instrumentation and exporter packages to actually capture and emit data.

Q: How do you wire up OpenTelemetry tracing and metrics inside Program.cs using .NET dependency injection?

You configure it using the extension methods provided by OpenTelemetry.Extensions.Hosting:

C#

builder.Services.AddOpenTelemetry()
    .ConfigureResource(resource => resource.AddService("MyMicroservice"))
    .WithTracing(tracing => tracing
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddOtlpExporter())
    .WithMetrics(metrics => metrics
        .AddAspNetCoreInstrumentation()
        .AddRuntimeInstrumentation()
        .AddOtlpExporter());

This registers the OpenTelemetry providers into the DI container, which automatically starts listening to requests and exporting them via OTLP (typically to an endpoint like http://localhost:4317).

Q: How do you integrate OpenTelemetry with AWS services like Amazon CloudWatch and X-Ray in a .NET application?

Answer

You use the AWS Distro for OpenTelemetry (ADOT) tools and libraries.

• For Code-based Integration: Install packages like OpenTelemetry.Extensions.AWS, OpenTelemetry.Resources.AWS, and OpenTelemetry.Sampler.AWS.

• For Zero-Code Instrumentation: Use the NuGet package AWS.Distro.OpenTelemetry.AutoInstrumentation or inject the ADOT .NET Profiler via host startup hooks.

Your app typically sends data via OTLP to an ADOT Collector sidecar running in your ECS/EKS container, which handles authentication and forwards the traces to X-Ray and metrics to CloudWatch.

Mnemonic / Tip

“Instrument once, route anywhere.” By using ADOT with standard OpenTelemetry APIs instead of proprietary AWS SDKs, your code remains completely cloud-agnostic while still integrating natively with AWS backends.

Q: What is the purpose of the OTLP exporter ( OpenTelemetry.Exporter.OpenTelemetryProtocol), and why is it preferred over vendor-specific exporters?

The OTLP (OpenTelemetry Protocol) exporter serializes and sends telemetry data using the official open standard protocol over gRPC or HTTP.

It is preferred because it decouples your .NET application from any specific vendor (such as Datadog, New Relic, Dynatrace, or AWS). If you decide to switch monitoring platforms later, you only change the collector endpoint destination in your configuration without modifying a single line of your application code or swapping out NuGet packages.

Q: What is a major performance hazard when enabling tracing on a high-throughput .NET API, and how is it mitigated?

Answer

Generating, serializing, and exporting trace spans for every single incoming request under heavy production traffic can saturate network input/output, increase latency, and cause massive storage billing spikes at your observability backend.

This is mitigated using Head Sampling via the OpenTelemetry SDK configuration (e.g., setting a trace-id ratio sampler to only record and export a fraction of requests, such as 10%).

Common Pitfall

Leaving 100% trace sampling enabled in high-traffic production microservices. Without a sampler, a sudden traffic surge can overwhelm your local exporter buffer or crash your OTLP collector pipeline.