Application Insights
Does ZopNight manage Application Insights?
Azure Application Insights bills for the GB of telemetry it ingests into its backing Log Analytics workspace, not for the component itself. ZopNight discovers each component via Resource Graph, links it to that workspace, and attributes ingestion spend from Cost Management so heavy unsampled senders stand out.
Rules that fire on Application Insights
No active rule family targets Application Insights today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only. |
Application Insights provides APM telemetry for applications, billed by data ingested into its backing Log Analytics workspace. Unsampled telemetry from chatty apps quietly multiplies monitoring spend.
Telemetry volume is the whole bill
An Application Insights component carries no charge of its own. Every request trace, dependency call, exception, and custom event it collects lands as ingested data in the Log Analytics workspace behind it, and that ingestion, metered per GB, is what appears on the invoice. The consequence is that cost tracks application chattiness, not application count: one verbose microservice emitting a dependency record for every cache hit can out-bill a dozen quiet production apps. Retention of that data beyond the workspace’s included window then adds a second, smaller charge on the same bytes.
How ZopNight ties a component to its ingestion spend
Discovered via Azure Resource Graph and linked to its backing workspace, so the component-to-workspace relationship is explicit rather than inferred. Cost Management billing attributes ingestion spend, flagging components with heavy unsampled telemetry. Because an APM component has no meaningful off state, it is not schedulable. The savings lever is configuration, and ZopNight’s role is making the spend attributable enough that the right team fixes the right sender.
Where APM spend runs away
Three senders dominate most overruns. Sampling left disabled: the SDKs support adaptive sampling, and a service that ships every single request record pays for telemetry no human will read. Dependency noise: instrumented apps that record each Redis or SQL round-trip generate enormous volume from healthy, boring calls. Non-production parity: dev and staging environments instrumented identically to production ingest at production rates while nobody watches their dashboards, which is pure monitoring overhead.
Reviewing a component in the Azure portal
Azure portal → Application Insights lists every component with its linked workspace. Open a component and its Usage and estimated costs blade breaks down ingestion by telemetry type. That is the fastest way to see whether requests, dependencies, or traces are carrying the bill, and whether sampling is doing anything at all.