Search
5 results for “log-analytics”
Search results
Azure Monitor
How Azure Monitor, Log Analytics, and Application Insights fit together as one platform, and why KQL, not a dashboard, is where real incident investigation happens.
How do Azure Monitor, Log Analytics, and Application Insights relate to each other?
Azure Monitor is the umbrella platform for all monitoring data in Azure, metrics, logs, and alerts across every resource. Log Analytics is the query and storage engine underneath it that holds log data in workspaces and is queried using KQL (Kusto Query Language). Application Insights is Azure Monitor's application-performance-monitoring feature specifically, which auto-instruments application code to collect request traces, dependency calls, and exceptions, and stores that data in a Log Analytics workspace like everything else. They are not three separate products so much as one platform (Azure Monitor) with a query engine (Log Analytics) and an application-specific instrumentation layer (Application Insights) on top of it.
What is the difference between a metric alert and a log alert in Azure Monitor?
A metric alert evaluates near-real-time numeric metrics (CPU percentage, request count) against a threshold, with low latency, typically triggering within a minute or so of the threshold being crossed. A log alert runs a KQL query against Log Analytics on a schedule (e.g., every 5 minutes) and alerts based on the query's results, which supports much richer conditions (joining multiple data sources, complex filtering) but has higher latency, bounded by both the query schedule and log ingestion delay. Choose metric alerts for fast-reacting, simple threshold conditions, and log alerts for anything requiring more complex logic than a single metric can express.
Why does effective incident investigation in Azure usually require writing KQL rather than relying only on dashboards?
Dashboards are built in advance for questions someone anticipated asking; they're monitoring, not investigation. A real incident usually raises a question nobody built a dashboard for ("which specific requests failed, and what did they have in common?"), and answering that requires querying the underlying log data directly. KQL is Log Analytics' query language, and being able to write ad hoc queries, joining traces, filtering by custom dimensions, correlating across data types, is what turns "I can see something is wrong" into "I know why," which is the actual goal of observability, not just monitoring.
A query filters WHERE logdate >= 2008-01-01 against a table range-partitioned by logdate across dozens of monthly partitions. What does partition pruning actually do, and what does it depend on?
Partition pruning lets the planner prove, from the query's WHERE clause and each partition's declared bounds, that some partitions cannot possibly contain a matching row, and it excludes them from the plan entirely rather than scanning and filtering every partition. In this example, `logdate >= 2008-01-01` has no upper bound, so it prunes only the partitions entirely before 2008-01, decades of older monthly partitions are eliminated before execution, while every partition from 2008-01 onward, including all of them up to the present, is still considered and scanned. Pruning down to a single partition would need a bounded predicate on both ends, for example `logdate >= 2008-01-01 AND logdate < 2008-02-01`. This depends entirely on the partition bounds themselves, not on any index, a partitioned table with no indexes at all still benefits from pruning, and pruning specifically requires the WHERE clause to reference the partition key directly with values (or parameters) the planner can actually compare against those bounds.