Task 4.2: Monitor and troubleshoot Azure solutions

• ASet a distinct OTEL_SERVICE_NAME, or service.name resource attribute, for each service

  Correct

  The cloud role name comes from service.namespace and service.name, falling back to service.name alone.

• BGive each service its own Application Insights connection string

  Incorrect

  Separate resources would give separate nodes, but the services must keep reporting to the one shared resource.

• CSet the service.instance.id attribute to a different value per service

  Incorrect

  service.instance.id sets the cloud role instance, not the role name shown on the map node.

• DTurn off sampling so both services send all telemetry

  Incorrect

  Sampling affects volume, not how components are named on the map.

Without a configured role name, the cloud role name defaults to the Application Insights resource name. Set it per service through OpenTelemetry resource attributes, for example OTEL_SERVICE_NAME or OTEL_RESOURCE_ATTRIBUTES.

• AAppRequests | where TimeGenerated > ago(1h) and Name == "POST /chat" | summarize percentile(DurationMs, 95) by bin(TimeGenerated, 5m)

  Correct

  It filters first, then computes the percentile per five-minute bin.

• BAppRequests | where TimeGenerated > ago(1h) and Name == "POST /chat" | summarize avg(DurationMs) by bin(TimeGenerated, 5m)

  Incorrect

  This returns the average duration, not the 95th percentile.

• CAppRequests | summarize percentile(DurationMs, 95) by Name | where TimeGenerated > ago(1h)

  Incorrect

  After summarize only the grouping and aggregate columns remain, so TimeGenerated can't be filtered, and there are no time buckets.

• DAppRequests | where TimeGenerated > ago(1h) and Name == "POST /chat" | top 95 by DurationMs

  Incorrect

  top returns the 95 slowest rows, not a percentile per bucket.

Filter with where and ago(), then aggregate with summarize. percentile() estimates a nearest-rank percentile, and bin() rounds TimeGenerated into fixed-size buckets for the by clause.

• AUse summarize sum(ItemCount) instead of count()

  Correct

  Each retained record's ItemCount says how many original items it represents, so summing it restores the totals.

• BUse dcount(Id) instead of count()

  Incorrect

  A distinct count of retained IDs is still a count of sampled records.

• CMultiply count() by the sampling percentage

  Incorrect

  The sampling rate can vary over time; ItemCount already carries the right weight per record.

• DQuery the AppTraces table instead of AppRequests

  Incorrect

  Trace logs aren't requests, and they're also subject to sampling.

Sampling keeps a representative subset of telemetry and records on each kept item how many items it stands for. Log queries that count events must sum ItemCount rather than count rows.

• ARecord each job as a custom event instead of a span

  Incorrect

  Custom events go to the customEvents table, not to requests.

• BAdd a span attribute named request with the value true

  Incorrect

  An attribute adds a custom property; it doesn't change which table the span lands in.

• CStart the span with kind=SpanKind.SERVER

  Correct

  Spans of kind SERVER are stored in the requests table; the default kind lands in dependencies as InProc.

• DLower the sampling rate so more spans reach requests

  Incorrect

  Sampling changes how many spans are kept, not their telemetry type.

Manual spans created with the OpenTelemetry API default to internal spans, which Application Insights records as InProc dependencies. For background work that autoinstrumentation doesn't capture, set the span kind to SERVER so it appears as a request.

• AInstall the opencensus-ext-azure package and configure its exporter

  Incorrect

  The OpenCensus Python SDK is retired; Microsoft directs users to OpenTelemetry instead.

• BDeploy an OpenTelemetry Collector, which the distro needs to reach Azure Monitor

  Incorrect

  The distro exports directly to Azure Monitor; a collector isn't required.

• CAdd a separate SDK package for each signal and register three exporters by hand

  Incorrect

  The distro bundles the instrumentations and exporters, so manual wiring per signal isn't needed.

• DInstall the microsoft-opentelemetry package and call use_microsoft_opentelemetry() with Azure Monitor export enabled at startup

  Correct

  The Microsoft OpenTelemetry Distro is the recommended starting point for new Python apps and collects all three signals.

• ESet APPLICATIONINSIGHTS_CONNECTION_STRING to the resource's connection string before the app starts

  Correct

  The connection string identifies the Application Insights resource that receives the telemetry.

For new .NET, Node.js and Python apps, Microsoft recommends the Microsoft OpenTelemetry Distro; apps already on the Azure Monitor OpenTelemetry Distro need no change. Point it at the resource with the connection string, usually through APPLICATIONINSIGHTS_CONNECTION_STRING.

• Awhere Message contains "timeout"

  Incorrect

  contains scans for a substring anywhere, which is slower and also matches inside longer words.

• Bwhere Message == "timeout"

  Incorrect

  == matches only messages that are exactly the word timeout.

• Cwhere Message startswith "timeout"

  Incorrect

  startswith matches only messages that begin with the word.

• Dwhere Message has "timeout"

  Correct

  has matches whole indexed terms and is the preferred, faster operator for this kind of search.

KQL indexes terms of three or more characters. has looks them up in the term index, while contains must scan values; Microsoft's best practices prefer has over contains when you're looking for full terms.

• AMonitoring Reader on the Application Insights resource

  Incorrect

  A reader role lets an identity view monitoring data, not send it.

• BLog Analytics Reader on the linked workspace

  Incorrect

  Reading the workspace doesn't authorize ingestion into Application Insights.

• CMonitoring Metrics Publisher on the Application Insights resource

  Correct

  Despite its name, this role publishes all telemetry types to the resource.

• DKey Vault Secrets User on a vault that holds the connection string

  Incorrect

  The connection string isn't a credential for Entra ingestion; the identity itself must be authorized on the resource.

When local authentication is off, the SDK must authenticate with a Microsoft Entra credential, and that identity needs the Monitoring Metrics Publisher role scoped to the Application Insights resource.

• Asummarize ErrorRate = countif(Success == false) by bin(TimeGenerated, 15m)

  Incorrect

  This is the number of failures per bin, not a percentage.

• Bsummarize ErrorRate = 100 * count() / countif(Success == false) by bin(TimeGenerated, 15m)

  Incorrect

  The ratio is inverted, dividing all requests by failures.

• Csummarize ErrorRate = dcount(Success) by bin(TimeGenerated, 15m)

  Incorrect

  dcount returns the number of distinct values of Success, at most two.

• Dsummarize ErrorRate = 100.0 * countif(Success == false) / count() by bin(TimeGenerated, 15m)

  Correct

  countif counts failed rows and count() counts all rows in each bin, giving a percentage.

countif() counts the rows for which a predicate is true. Dividing it by count() per time bin, with a decimal literal to avoid integer arithmetic, gives the failure percentage for each bucket.

• ADeploymentStatus | summarize max(TimeGenerated) by DeploymentId, Status

  Incorrect

  This returns the latest timestamp per ID and status pair, not the latest full row per deployment.

• BDeploymentStatus | top 1 by TimeGenerated

  Incorrect

  This returns the single latest row across all deployments.

• CDeploymentStatus | summarize arg_max(TimeGenerated, *) by DeploymentId

  Correct

  arg_max returns the row with the highest TimeGenerated in each group, with all its columns.

• DDeploymentStatus | distinct DeploymentId

  Incorrect

  This lists the IDs without any of their status columns.

arg_max(ExprToMaximize, *) finds the row that maximizes an expression in each group and returns the requested columns, here all of them.

• ALog Analytics queries on AppRequests

  Incorrect

  Log data is aggregated and ingested over minutes, not shown within a second.

• BLive metrics

  Correct

  Live metrics shows data within about a second while the pane is open, and it's enabled by default for Python.

• CApplication map

  Incorrect

  Application map shows components and dependencies, not a second-by-second feed.

• DMetrics explorer with a one-hour aggregation

  Incorrect

  Metrics explorer aggregates over minutes or more.

Live metrics streams selected metrics and sampled failures to the portal in near real time. Nothing is retained after it leaves the chart, and there's no charge for the stream.

• AThe distro defaults to rate-limited sampling at five traces per second

  Correct

  That's the default for Azure Monitor export in the .NET, Node.js and Python distros.

• BApplication Insights drops all traces beyond 50 per second on ingestion

  Incorrect

  The reduction comes from the distro's sampler, not from a fixed ingestion cap.

• CThe distro samples a fixed 10 percent of traces by default

  Incorrect

  Fixed-rate sampling is an option you configure; the default is rate-limited.

• DMetrics are sampled at the same rate, so request counts are wrong too

  Incorrect

  Metrics aren't sampled, which is why they're recommended for alerting.

Sampling lowers telemetry volume and cost. You can switch to a fixed ratio or a different traces-per-second rate; the Application Insights sampler keeps traces complete and stays compatible with Live Metrics.