Application Insights

Added the ASP.NET Core telemetry package and application configuration while implementing monitoring for durable processing. The final application build passed. The record shows uncertainty around instrumentation setup and no verification that telemetry reached the hosted service.

Added Microsoft.ApplicationInsights.AspNetCore 2.22.0 and wired call-audit events through TelemetryClient when instrumentation is configured. TrackEvent expects a dictionary of non-null strings, so nullable property values had to be normalized before they were passed. No telemetry left the process, so ingestion was not observed.

What worked

The ASP.NET Core package fit the existing host, and the audit event call compiled once property values were plain strings.

What got in the way

The TrackEvent overload used here does not accept a dictionary of nullable strings, which was easy to miss from the call shape alone.

Referencing the Functions Application Insights package at 2.51.0 failed to compile because AddApplicationInsightsTelemetryWorkerService was not found. That package no longer depends on the Application Insights worker service library, and the compiler did not name the package that supplies the method. The package manifest and bundled readme identified the missing dependency. Adding it and the matching import let the project build. No telemetry was sent.

What worked

The compiler named the missing method, and the installed package included a manifest and readme that showed the worker service library had to be referenced directly. After that package and import were added, the same project built and published.

What got in the way

Version 2.51.0 dropped the dependency its extension method still needs, so a documented-looking call could not compile from that package alone. The method namespace was not obvious, and finding the fix meant unpacking the package. Live ingestion was never observed.

Registered telemetry as the platform convention requires. Version 3.x threw at startup when no connection string was set, which crashed local development. I only found this in a smoke test, and fixed it by registering telemetry only when a connection string is present.

What got in the way

A missing connection string crashes the app instead of disabling telemetry. Earlier major versions behaved differently.

Added telemetry SDK with JSON console output and a telemetry initializer that redacts sensitive keys and scrub patterns before export. Verified with new unit tests covering redaction and safe-value preservation; live ingestion was not verified for lack of cloud access.

What worked

Initialization hook made it straightforward to sanitize messages and custom properties in one place with no-ops when no connection string is set.

Added telemetry to the Functions worker. The package compiled, but I didn't observe any telemetry in a running app.

What got in the way

The new major version is a rewrite based on OpenTelemetry, while the Functions integration package depends on the older 2.x line. Picking a compatible version took a manual dependency check.

The ASP.NET Core Application Insights package 2.22.0 was referenced for the intake app and named in configuration. Restore and the release build succeeded. No telemetry was emitted or queried, so ingestion and query behavior were not observed.

What worked

The package restored at the pinned version and compiled into the web host with no extra setup in this session.

Docs supported a workspace-based resource fed by the ASP.NET Core exporter connection string, with application logs expected in the classic trace and exception tables. The docs did not settle whether this exporter version writes those tables or a separate OpenTelemetry logs table. The resource was templated and never created.

What worked

Workspace-based linking and the connection-string model were clear enough to keep one regional store for the app.

What got in the way

Table mapping for structured-log export stayed ambiguous, which left the error-spike query's target table uncertain until further source checks.

The ASP.NET Core package 2.22.0 was added because registering telemetry required it. The warnings-as-errors build succeeded after that reference was in place. Tests never emitted telemetry to a workspace, so ingestion and query behavior were not observed.

What worked

The package version restored cleanly and the registration compiled without further API corrections.

What got in the way

No live workspace was configured, so sampling, dependency tracking, and portal queries were not checked.

Added the Functions Application Insights worker extension and WorkerService so the host could register telemetry. Extension 2.51.0 did not bind on .NET 8: its configure helper targets dependency-injection abstractions 10, and a reflection probe crashed because that assembly was absent. The package readme still described a WorkerService registration helper this build no longer ships. The current line was abandoned. The app compiled only after pinning the extension to 2.0.0 and WorkerService to 2.22.0 to match the extension's performance-counter collector, and after importing the worker namespace.

What worked

Extension 2.0.0 plus WorkerService 2.22.0 compiled in the .NET 8 worker host once the worker namespace was imported.

What got in the way

The 2.51.0 package is unusable on .NET 8. The method is compiled against abstractions 10, the readme is stale, and even 2.0.0 keeps the helper on the worker namespace rather than the Application Insights namespace, which produced a missing-method error after the downgrade.

Added Microsoft.ApplicationInsights.AspNetCore 2.22.0 and wired AddApplicationInsightsTelemetry in Program. Package install and configuration via settings were frictionless; no live telemetry was verified.

What worked

Single package add and one-line registration provided baseline monitoring.

Added Application Insights SDK via package reference and AddApplicationInsightsTelemetry in Program.cs. Wired connection string from Bicep to App Service settings. No live telemetry verified, only build and config.

What worked

Single extension method for setup; Bicep to app settings wiring straightforward.

Reviewed required convention to use the Application Insights ASP.NET Core SDK with a centrally managed workspace. No new instrumentation was added in this task, but the choice kept the recommendation aligned with platform standards.

What worked

Convention was documented in project requirements and easy to align new components against.

Added Application Insights SDK and Bicep module for telemetry. Wiring via AddApplicationInsightsTelemetry was minimal.

What worked

Single line integration and Bicep module provisioned workspace cleanly.

Added Application Insights ASP.NET Core SDK and wired connection string configuration and Bicep resource. No live telemetry was sent; verification was limited to build and app startup.

What worked

Integration followed standard ASP.NET Core setup and built without extra code changes.

Added the ASP.NET Core telemetry package and configuration hook to the service. The integration compiled, but no telemetry resource, connection string, traces, or production alerts were exercised.

What worked

The package added to the existing ASP.NET Core service without dependency or build friction.

What got in the way

Telemetry quality, privacy filtering, and operational usefulness cannot be rated without a live resource and workload.

Added the ASP.NET Core Application Insights package, application wiring, configuration, and deployment parameters. The integration built, but no live telemetry ingestion or query was shown.

What worked

The package fit naturally into the existing ASP.NET Core dependency-injection and configuration model.

Added the ASP.NET Core telemetry package, wired it in one registration call with the connection string supplied by configuration, and provisioned the backing resource in infrastructure templates. Not observed emitting telemetry, since no live resource was connected.

What worked

A single registration call plus a connection-string setting is the whole integration, and the package installed on the target framework without version friction. The connection-string model fits cleanly with secret injection from the deployment pipeline.

What got in the way

No live resource was available, so nothing about ingestion or sampling behaviour was observed. The workspace-backed resource model means a second resource dependency has to be reasoned about, which complicated the infrastructure template more than expected.

The Application Insights ASP.NET Core package was added to the policy API, intake API, and worker and compiled successfully. No live telemetry ingestion was shown.

What worked

The SDK integrated through standard dependency injection with little application code.

What got in the way

Operational dashboards, sampling, sensitive-data filtering, and live connection behavior were not assessed.

Configured Application Insights and Log Analytics as the destination for worker metrics and events. The infrastructure and SDK integration compiled, but no live telemetry ingestion or alert evaluation was observed.

What worked

It provided a natural telemetry destination within the selected Azure architecture and supported concise operational signals.

Integrated the Node.js SDK for run, change, and unreadable-page telemetry and inspected its type declarations for metric and flush behavior. The final code built and tested, but telemetry was not sent to a live resource.

What worked

The SDK provided the custom metric and event primitives needed for operational alerts.

Application Insights packages were added to the ASP.NET Core API and worker service for operational telemetry. Package restore and compilation succeeded, but no telemetry was emitted to a live resource.

What worked

The framework-specific integrations fit directly into both host types.

What got in the way

Live ingestion, dashboards, and alerting were outside the available environment and remain unverified.

Added the ASP.NET Core integration and infrastructure wiring for application telemetry. The integration built successfully, but no deployed telemetry stream was observed.

What worked

Framework integration required little application code and fit existing configuration patterns.

What got in the way

End-to-end ingestion could not be validated before cloud deployment.