Implement an instrumentation strategy
Telemetry model
Application Insights records requests, dependencies, exceptions, traces, events and metrics. Workspace-based Application Insights stores everything in a Log Analytics workspace, so you query with KQL and can join across resources in the same workspace. Distributed tracing uses the W3C traceparent header, and operation_Id correlates a request with its dependencies and exceptions. Telemetry initializers add or overwrite properties such as cloud role name before ingestion.
Sampling, the classic trap
Adaptive sampling is on by default for ASP.NET Core SDKs; fixed-rate and ingestion sampling are the alternatives. Sampling means request counts and metric values are estimates, and some item types may be excluded - so "how many requests hit the API?" is a question about sampling configuration, not just a query.
Monitoring and alerting
Application Map, Live Metrics, Failures and Performance blades surface behaviour. Availability tests probe endpoints from multiple locations - the standard URL ping test, or a custom test that calls TrackAvailability. Alerts split into metric alerts and log-search alerts, each needing an action group plus an evaluation frequency and aggregation granularity. Workbooks and Azure dashboards visualise; smart detection raises anomalies automatically.
Release instrumentation
Continuous monitoring closes the loop: a post-deployment gate queries Application Insights and fails or rolls back the release when error rate or latency breaches a threshold.
Traps
- Naming the wrong table:
requestsfor server calls,customEventsforTrackEvent,pageViewsfor client views. - Assuming alerts fire without an action group.
- Forgetting retention settings when historical queries return nothing.
Rule of thumb
Write the table first (requests, dependencies, exceptions, customEvents), then filter on timestamp and cloud_RoleName; if the numbers look low, check sampling.