A spruce-fen App Service site can enable Application Insights in the portal, but the team also wants custom spans. How do the two instrumentation paths compare?
Select an answer to reveal the explanation.
Short Explanation
Portal auto-instrumentation gets you going without code. Need custom spans? Add the OpenTelemetry Distro in the app. AKS previews and Redis are side quests.
Full Explanation
App Service offers two complementary instrumentation paths. Codeless auto-instrumentation (enabled in the portal) is the fast host path for baseline requests, dependencies, and exceptions without code changes. When the spruce-fen team also needs custom spans, they add the Azure Monitor OpenTelemetry Distro in application code—the extensibility path—while still targeting Application Insights. Auto-instrumentation gets you going; the Distro deepens control.
Claiming only AKS auto-instrumentation preview can add custom spans on App Service fails because custom spans on App Service come from in-app OpenTelemetry/Distro instrumentation, not from requiring AKS.
Claiming codeless auto-instrumentation never works on App Service and that code is mandatory for any signal fails because App Service does support portal/codeless Application Insights enablement for baseline telemetry.
Requiring that custom spans disable Application Insights and use Redis metrics instead fails because custom spans are emitted through OpenTelemetry/Insights APIs; Redis metrics are unrelated and turning Insights off removes the destination.
Exam caveat: understand overlap—codeless plus Distro can double-collect if both are left on carelessly; follow current docs for coexistence or prefer Distro when you need custom spans. Operational check: enable auto-instrumentation and verify baseline requests, then add a custom span via the Distro and confirm it appears under the same operation without breaking existing charts.