This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Secure, monitor, and troubleshoot Azure solutions (20–25%)
   --> Monitor and troubleshoot Azure solutions
      --> Write KQL queries to analyze logs and metrics

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure applications generate large amounts of telemetry, including application logs, resource logs, requests, dependencies, exceptions, performance information, and metrics. For an AI cloud developer, being able to turn this telemetry into useful information is an important troubleshooting and monitoring skill.

Kusto Query Language (KQL) is the query language used by Azure Monitor Logs and Log Analytics. It is designed for querying and analyzing large volumes of structured and semi-structured data. KQL is also used across several Microsoft services, including Azure Monitor, Azure Data Explorer, Microsoft Fabric, and Microsoft Sentinel.

For the AI-200 exam, you should be comfortable reading and writing KQL queries that:

• Filter log records
• Select and rename columns
• Sort results
• Limit returned records
• Create calculated columns
• Aggregate data
• Group results
• Analyze data over time
• Identify errors and exceptions
• Analyze application performance
• Join or combine related data
• Create time-series visualizations
• Investigate trends and anomalies
• Analyze telemetry from distributed applications

1. What Is Kusto Query Language?

Kusto Query Language (KQL) is a read-only query language optimized for analyzing large datasets.

A KQL query generally starts with a table and then applies a sequence of operations to that table.

For example:

AzureActivity
| where TimeGenerated > ago(1h)
| where ActivityStatus == "Failed"
| project TimeGenerated, OperationNameValue, ActivityStatus

The pipe character (|) passes the output of one operation to the next.

Conceptually:

Table
   ↓
Filter
   ↓
Filter
   ↓
Select columns
   ↓
Results

This pipeline-oriented approach is one of the most important characteristics of KQL.

KQL queries are read-only. They retrieve and analyze data rather than modifying the underlying records.

2. Azure Monitor Logs and Log Analytics

Azure Monitor Logs stores telemetry in a Log Analytics workspace.

Log Analytics is one of the primary tools used in the Azure portal to write and execute KQL queries.

The general relationship is:

Azure Resources / Applications
             ↓
        Azure Monitor
             ↓
      Diagnostic data
             ↓
    Log Analytics Workspace
             ↓
          KQL
             ↓
     Analysis / Alerts /
     Workbooks / Reports

Resource logs aren’t automatically available in a Log Analytics workspace simply because the resource exists. A diagnostic setting generally needs to be configured to send resource logs to the workspace.

KQL queries can subsequently be used for troubleshooting, analysis, dashboards, alerts, and reporting.

3. Understanding the Basic KQL Query Structure

A simple KQL query looks like this:

TableName
| operator
| operator
| operator

For example:

AppRequests
| where TimeGenerated > ago(1h)
| where Success == false
| project TimeGenerated, Name, ResultCode

Each line operates on the results produced by the previous line.

Important exam concept

KQL isn’t SQL.

For example:

SQL:

SELECT Name, ResultCode
FROM AppRequests
WHERE Success = 0;

KQL:

AppRequests
| where Success == false
| project Name, ResultCode

The order and syntax are different.

4. The where Operator

The where operator filters records.

AppRequests
| where Success == false

This returns only unsuccessful requests.

Multiple conditions can be combined:

AppRequests
| where Success == false
| where ResultCode == 500

Or:

AppRequests
| where Success == false and ResultCode == 500

You can also use or:

AppRequests
| where ResultCode == 500 or ResultCode == 503

Common comparison operators

Example:

AppRequests
| where ResultCode in (500, 502, 503)

5. Filtering by Time

Time filtering is extremely important when troubleshooting.

A common approach is the ago() function.

AppRequests
| where TimeGenerated > ago(1h)

This means:

Return records generated within the last hour.

Other examples:

| where TimeGenerated > ago(30m)

| where TimeGenerated > ago(24h)

| where TimeGenerated > ago(7d)

You can also specify explicit timestamps:

| where TimeGenerated between (
    datetime(2026-08-10 08:00:00) ..
    datetime(2026-08-10 12:00:00)
)

Exam tip

When investigating an incident, filtering by time early is usually a good practice because it reduces the amount of data being processed and makes the results easier to interpret.

6. The project Operator

Use project to select the columns you want returned.

AppRequests
| project TimeGenerated, Name, ResultCode

Instead of returning every available column, the query returns only the selected columns.

You can also rename columns:

AppRequests
| project Timestamp = TimeGenerated, Endpoint = Name, Status = ResultCode

This is particularly useful when creating clean results for reports or troubleshooting.

7. The project-away Operator

project-away removes columns from the result.

For example:

AppRequests
| project-away Computer, TenantId

This can be useful when you want most columns but need to exclude a few.

8. The extend Operator

extend creates a calculated column.

For example:

AppRequests
| extend DurationSeconds = DurationMs / 1000.0
| project Name, DurationMs, DurationSeconds

The original columns remain available, and the calculated column is added to the result.

Another example:

AppRequests
| extend IsSlow = DurationMs > 2000

Now each record has an IsSlow value indicating whether the request exceeded two seconds.

extend vs. project

This distinction is important:

• extend adds or calculates columns.
• project controls which columns appear in the final result.

They are frequently used together.

9. The summarize Operator

summarize performs aggregations.

For example:

AppRequests
| summarize count()

This returns the number of records.

You can calculate averages:

AppRequests
| summarize avg(DurationMs)

Other common aggregation functions include:

10. Grouping with summarize

You can group results using by.

For example:

AppRequests
| summarize count() by ResultCode

This produces a count for each result code.

You can also group by multiple columns:

AppRequests
| summarize count() by Name, ResultCode

This is similar conceptually to a GROUP BY operation in SQL.

11. Conditional Aggregations

KQL’s conditional aggregation functions are particularly useful for monitoring.

For example:

AppRequests
| summarize
    TotalRequests = count(),
    FailedRequests = countif(Success == false)

You could calculate an error rate:

AppRequests
| summarize
    TotalRequests = count(),
    FailedRequests = countif(Success == false)
| extend ErrorRate = 100.0 * FailedRequests / TotalRequests

This is an excellent example of using KQL to turn raw telemetry into a meaningful application-health metric.

12. Sorting Results

Use order by or sort by to sort results.

AppRequests
| order by DurationMs desc

This puts the slowest requests first.

You can sort ascending:

AppRequests
| order by DurationMs asc

Troubleshooting example

To find the slowest requests:

AppRequests
| where TimeGenerated > ago(1h)
| order by DurationMs desc
| take 20

This returns the 20 slowest requests from the last hour.

13. Limiting Results with take

Use take to return a specified number of records.

AppRequests
| take 10

For troubleshooting:

AppExceptions
| where TimeGenerated > ago(30m)
| take 50

take is particularly useful when exploring an unfamiliar table.

14. The distinct Operator

Use distinct to return unique values.

AppRequests
| distinct Name

You can use multiple columns:

AppRequests
| distinct Name, ResultCode

This is useful for understanding the values contained in a dataset.

15. Searching Text

KQL provides several operators for text analysis.

For example:

AppExceptions
| where OuterMessage contains "timeout"

You can also use:

AppRequests
| where Name startswith "/api/"

And:

AppRequests
| where Name endswith "/health"

The has operator can also be useful for term-based searches:

AppExceptions
| where OuterMessage has "timeout"

Understanding the difference between text-search operators can matter when troubleshooting log data.

16. Working with Null and Empty Values

Use isnull() and isnotnull() when checking for null values.

AppRequests
| where isnull(UserId)

Or:

AppRequests
| where isnotnull(UserId)

For strings, isempty() and isnotempty() can be useful.

AppRequests
| where isnotempty(Name)

17. Binning Data with bin()

When analyzing data over time, you often don’t want every individual event.

Instead, you can group events into time intervals.

For example:

AppRequests
| summarize count() by bin(TimeGenerated, 5m)

This produces request counts in five-minute intervals.

You can use different intervals:

bin(TimeGenerated, 1m)

bin(TimeGenerated, 1h)

bin(TimeGenerated, 1d)

This is one of the most important techniques for creating time-series analyses.

18. Creating Time-Series Charts

A typical query might be:

AppRequests
| summarize RequestCount = count()
    by bin(TimeGenerated, 5m)
| render timechart

The query:

1. Counts requests.
2. Groups them into five-minute intervals.
3. Produces a time-series visualization.

Azure Monitor’s Metrics and log-based analysis commonly use this type of time-binning approach.

19. Analyzing Errors Over Time

Suppose an application is experiencing intermittent failures.

You could use:

AppRequests
| where TimeGenerated > ago(24h)
| summarize
    TotalRequests = count(),
    FailedRequests = countif(Success == false)
    by bin(TimeGenerated, 15m)
| extend ErrorRate = 100.0 * FailedRequests / TotalRequests
| render timechart

This allows you to see whether error rates are increasing, decreasing, or occurring in bursts.

20. Finding the Most Common Errors

For exception analysis:

AppExceptions
| where TimeGenerated > ago(24h)
| summarize Count = count() by OuterMessage
| order by Count desc
| take 20

This identifies the most frequently occurring exception messages.

A developer could then investigate whether the most common exception corresponds to a particular application component or deployment.

21. Analyzing HTTP Status Codes

A useful troubleshooting query is:

AppRequests
| where TimeGenerated > ago(1h)
| summarize Count = count() by ResultCode
| order by Count desc

To focus specifically on server errors:

AppRequests
| where TimeGenerated > ago(1h)
| where ResultCode startswith "5"
| summarize Count = count() by ResultCode
| order by Count desc

This can help identify whether an application is experiencing widespread 5xx failures.

22. Identifying Slow Requests

A simple performance query:

AppRequests
| where TimeGenerated > ago(1h)
| where DurationMs > 2000
| project TimeGenerated, Name, DurationMs, ResultCode
| order by DurationMs desc

This finds requests taking more than two seconds.

You can instead summarize performance by endpoint:

AppRequests
| summarize
    AverageDuration = avg(DurationMs),
    MaximumDuration = max(DurationMs),
    RequestCount = count()
    by Name
| order by AverageDuration desc

This helps identify endpoints that consistently perform poorly.

23. Counting Distinct Users

The dcount() function provides an approximate distinct count.

For example:

AppRequests
| summarize UniqueUsers = dcount(UserId)

This is often useful for telemetry where an exact distinct count isn’t required.

For example:

AppRequests
| summarize UniqueUsers = dcount(UserId)
    by bin(TimeGenerated, 1h)
| render timechart

24. Joining Data

Sometimes the information needed to investigate a problem is stored in multiple tables.

KQL supports operations such as join.

Conceptually:

TableA
| join kind=inner TableB on SomeColumn

For example, you might correlate application records with another dataset containing additional information.

The join operator combines rows from two tables based on matching values.

Important exam consideration

Don’t automatically use join simply because two datasets exist. First determine whether the required information can be obtained from a single table.

Also remember that Azure Monitor has some KQL differences and limitations compared with Azure Data Explorer. For example, certain cross-cluster functionality isn’t supported in Azure Monitor.

25. The union Operator

union combines data from multiple tables or datasets.

Conceptually:

union TableA, TableB

This is useful when similar telemetry exists in multiple tables.

For example, Application Insights telemetry can be analyzed across multiple telemetry tables.

26. Working with Application Insights Telemetry

Application Insights provides application telemetry such as:

• Requests
• Dependencies
• Exceptions
• Traces
• Page views
• Availability results
• Custom events
• Custom metrics

For example, you can examine requests:

requests
| where timestamp > ago(1h)
| summarize count() by resultCode

Or exceptions:

exceptions
| where timestamp > ago(1h)
| summarize count() by type
| order by count_ desc

The exact tables and schema depend on the telemetry architecture and Azure Monitor/Application Insights configuration being used, so the ability to inspect the available table schema is important.

27. Logs Versus Metrics

A key concept for AI-200 is understanding that logs and metrics are complementary.

Metrics

Metrics are typically numerical measurements designed for efficient monitoring and alerting.

Examples include:

• CPU percentage
• Request count
• Memory utilization
• Network traffic
• Latency

Logs

Logs provide detailed records about events and operations.

Examples include:

• Exceptions
• HTTP requests
• Dependency calls
• Resource operations
• Application traces
• Security events

A metric might tell you:

Error rate increased to 12%.

A log query can help answer:

Which endpoint is failing, what exception is occurring, and which dependency is involved?

Azure Monitor supports working with both metrics and logs, and log-based metrics can themselves be represented through KQL queries.

28. Querying Resource Logs

Azure resources can send resource logs to Log Analytics through diagnostic settings.

Once the logs are available, KQL can be used to analyze them.

For example:

AzureActivity
| where TimeGenerated > ago(1h)
| summarize count() by Category

Or:

AzureActivity
| where TimeGenerated > ago(24h)
| where ActivityStatus == "Failed"
| project TimeGenerated, OperationNameValue, ActivityStatus

The exact table and fields depend on the Azure service and diagnostic configuration.

29. Using render

The render operator specifies how query results should be visualized.

For example:

AppRequests
| summarize count() by bin(TimeGenerated, 5m)
| render timechart

Other visualization types can be used depending on the data and analysis.

The important exam concept is that render affects how results are displayed, not how the underlying records are filtered or aggregated.

30. Detecting Anomalies

KQL includes capabilities for time-series analysis and anomaly detection.

For example, a time series can be created using make-series.

KQL also provides functions and operators that can be used for anomaly detection and forecasting. Azure Monitor documents these capabilities for analyzing telemetry without having to export the data to an external machine-learning system.

For AI-200, understand the general purpose:

Use KQL time-series capabilities to identify unusual behavior in application or infrastructure telemetry.

31. Example: Detecting an Increase in Errors

A practical investigation might proceed in stages.

Step 1 – Determine whether errors are occurring

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count()

Step 2 – Determine when they occurred

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count() by bin(TimeGenerated, 15m)
| render timechart

Step 3 – Identify the failing endpoints

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count() by Name
| order by count_ desc

Step 4 – Identify the status codes

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize count() by ResultCode
| order by count_ desc

This demonstrates a very useful troubleshooting methodology:

Detect → locate → categorize → investigate

32. Example: Investigating a Slow AI Application

Suppose an AI application suddenly becomes slow.

You could start with:

AppRequests
| where TimeGenerated > ago(1h)
| summarize
    AverageDuration = avg(DurationMs),
    MaximumDuration = max(DurationMs),
    Requests = count()

Then identify slow endpoints:

AppRequests
| where TimeGenerated > ago(1h)
| summarize
    AverageDuration = avg(DurationMs)
    by Name
| order by AverageDuration desc

Then examine individual slow requests:

AppRequests
| where TimeGenerated > ago(1h)
| where DurationMs > 5000
| project TimeGenerated, Name, DurationMs, ResultCode
| order by DurationMs desc

Finally, investigate dependencies associated with those requests.

This type of correlation is especially useful in distributed AI applications where an API might call several backend services.

33. Query Performance and Cost

KQL can process very large datasets, but query design still matters.

Good practices include:

Filter early

Prefer:

AppRequests
| where TimeGenerated > ago(1h)
| where Success == false
| summarize count() by Name

rather than processing an unnecessarily large historical dataset.

Select only required columns

Use:

| project TimeGenerated, Name, ResultCode

when you don’t need every column.

Use appropriate time ranges

Don’t query seven days of telemetry when the incident occurred five minutes ago.

Aggregate when appropriate

Instead of returning millions of individual records:

| summarize count() by Name

may provide the information you actually need.

This is especially relevant when working with billable data and large workspaces.

34. Querying Basic and Auxiliary Logs

Azure Monitor supports different table plans, including Analytics, Basic, and Auxiliary tables.

There are additional query limitations for Basic and Auxiliary tables. For example, certain multi-table operations aren’t supported, and Basic table queries are limited to a single table in relevant scenarios. Query costs can also depend on the amount of data scanned.

For the exam, understand that not every KQL query capability is necessarily available against every type of Azure Monitor log table.

35. Running KQL Programmatically

KQL isn’t limited to the Azure portal.

The Azure Monitor Logs Query API allows applications and automation tools to execute KQL queries against a Log Analytics workspace. The API accepts a KQL query and optional time range and returns the query results.

For example, conceptually:

{
    "query": "AzureActivity | summarize count() by Category",
    "timespan": "PT12H"
}

This makes it possible to build custom monitoring applications and automation around Azure Monitor data.

36. Important KQL Operators for AI-200

You should be familiar with at least the following:

37. KQL Exam Tips

For AI-200, focus on understanding why an operator is used rather than simply memorizing syntax.

Remember:

where = filter

| where Status == "Failed"

project = choose columns

| project TimeGenerated, Status

extend = calculate/add columns

| extend DurationSeconds = DurationMs / 1000

summarize = aggregate

| summarize count() by Status

order by = sort

| order by DurationMs desc

take = limit rows

| take 10

bin = group into intervals

| summarize count() by bin(TimeGenerated, 5m)

render = visualize

| render timechart

A particularly important pattern is:

TABLE
→ where
→ extend/project
→ summarize
→ order
→ render

38. Putting It All Together

Consider this query:

AppRequests
| where TimeGenerated > ago(24h)
| where Success == false
| summarize
    FailedRequests = count()
    by bin(TimeGenerated, 30m), Name
| order by TimeGenerated asc
| render timechart

This query:

1. Starts with AppRequests.
2. Limits the analysis to the last 24 hours.
3. Keeps unsuccessful requests.
4. Groups failures into 30-minute intervals.
5. Separates them by endpoint name.
6. Sorts the results chronologically.
7. Creates a time-series visualization.

Understanding how each stage transforms the data is exactly the type of reasoning that can help with AI-200 scenario-based questions.

39. Key Takeaways

For the “Write KQL queries to analyze logs and metrics” topic, make sure you can:

• Explain what KQL is.
• Explain the role of Log Analytics and Azure Monitor Logs.
• Understand KQL’s pipeline syntax.
• Filter records with where.
• Select columns with project.
• Create calculated values with extend.
• Aggregate records with summarize.
• Group data with by.
• Sort results with order by.
• Limit results with take.
• Find unique values with distinct.
• Filter by relative time using ago().
• Group time-series data using bin().
• Calculate counts, averages, sums, minimums, and maximums.
• Use conditional aggregations such as countif().
• Analyze errors and exceptions.
• Analyze request duration and performance.
• Correlate data using join when appropriate.
• Combine datasets using union.
• Create visualizations using render.
• Understand the relationship between logs and metrics.
• Understand how diagnostic settings make resource logs available for querying.
• Recognize that Azure Monitor has some KQL differences and limitations compared with Azure Data Explorer.
• Understand how KQL can be executed programmatically through the Azure Monitor Logs Query API.

Practice Exam Questions

Question 1

An AI-powered web application is experiencing intermittent HTTP 500 errors. You need to determine how many failed requests occurred during each 10-minute interval during the last hour.

Which KQL query should you use?

A.

AppRequests
| where TimeGenerated > ago(1h)
| where ResultCode == 500
| summarize count() by bin(TimeGenerated, 10m)

B.

AppRequests
| where TimeGenerated > ago(10m)
| summarize count() by ResultCode

C.

AppRequests
| summarize count() by TimeGenerated
| where ResultCode == 500

D.

AppRequests
| project ResultCode
| take 10

Answer: A

Explanation

where filters the data to the desired time period and status code. summarize count() counts the records, while bin(TimeGenerated, 10m) groups the results into 10-minute intervals.

Question 2

You need to identify the 20 slowest API requests made during the last two hours.

Which query should you use?

A.

AppRequests
| summarize avg(DurationMs) by Name
| take 20

B.

AppRequests
| where TimeGenerated > ago(2h)
| order by DurationMs desc
| take 20

C.

AppRequests
| where DurationMs > 20
| summarize count()

D.

AppRequests
| project DurationMs
| order by DurationMs asc

Answer: B

Explanation

The query first restricts the data to the last two hours, sorts individual requests by duration in descending order, and then returns the first 20 records. This identifies the slowest individual requests.

Question 3

An application team wants to calculate the average request duration for each API endpoint.

Which operator should primarily be used?

A. project

B. extend

C. summarize

D. take

Answer: C

Explanation

summarize is the KQL operator used for aggregation. For example:

AppRequests
| summarize AverageDuration = avg(DurationMs) by Name

project selects columns, extend creates calculated columns, and take limits the number of returned records.

Question 4

You need to add a column called DurationSeconds containing the request duration converted from milliseconds to seconds.

Which KQL statement should you use?

A.

| summarize DurationSeconds = DurationMs / 1000

B.

| project DurationSeconds = DurationMs / 1000

C.

| extend DurationSeconds = DurationMs / 1000.0

D.

| where DurationSeconds = DurationMs / 1000

Answer: C

Explanation

extend adds a calculated column while retaining the existing columns. Using 1000.0 also ensures the calculation is performed as a floating-point calculation.

Question 5

An administrator wants to identify the number of failed operations grouped by operation name.

Which query is most appropriate?

A.

AzureActivity
| summarize FailedOperations = countif(ActivityStatus == "Failed")
    by OperationNameValue

B.

AzureActivity
| where OperationNameValue == "Failed"
| project ActivityStatus

C.

AzureActivity
| order by ActivityStatus
| take 10

D.

AzureActivity
| distinct OperationNameValue

Answer: A

Explanation

countif() counts records that satisfy a condition, and by OperationNameValue groups the counts by operation. This directly answers the requirement.

Question 6

You are investigating application traffic and want to see request counts in five-minute intervals displayed as a time-series chart.

Which query should you use?

A.

AppRequests
| take 5
| render timechart

B.

AppRequests
| summarize count() by TimeGenerated
| render piechart

C.

AppRequests
| summarize count() by bin(TimeGenerated, 5m)
| render timechart

D.

AppRequests
| project TimeGenerated
| render timechart

Answer: C

Explanation

bin() groups timestamps into five-minute intervals, summarize count() counts requests in each interval, and render timechart produces the time-series visualization.

Question 7

You want to return only the TimeGenerated, Name, and ResultCode columns from a request table.

Which operator should you use?

A. extend

B. project

C. summarize

D. distinct

Answer: B

Explanation

project controls which columns are returned.

For example:

AppRequests
| project TimeGenerated, Name, ResultCode

Question 8

You need to investigate exceptions generated during the previous 30 minutes and display only records where the exception message contains the word “timeout.”

Which query is appropriate?

A.

AppExceptions
| where TimeGenerated > ago(30m)
| where OuterMessage contains "timeout"

B.

AppExceptions
| summarize count() by OuterMessage

C.

AppExceptions
| project TimeGenerated
| take 30

D.

AppExceptions
| order by OuterMessage

Answer: A

Explanation

The first where restricts the data to the previous 30 minutes. The second filters exception messages containing "timeout".

Question 9

An application team wants to determine the approximate number of distinct users who generated requests during each hour.

Which query should you use?

A.

AppRequests
| summarize count(UserId) by bin(TimeGenerated, 1h)

B.

AppRequests
| summarize distinct(UserId) by bin(TimeGenerated, 1h)

C.

AppRequests
| summarize dcount(UserId) by bin(TimeGenerated, 1h)

D.

AppRequests
| distinct UserId
| render timechart

Answer: C

Explanation

dcount() provides an approximate distinct count. Combining it with bin(TimeGenerated, 1h) produces an approximate unique-user count for each hour.

Question 10

An application has experienced a sudden increase in failures. You want to determine whether the failures are concentrated in particular API endpoints and identify the number of failures per endpoint.

Which query is most appropriate?

A.

AppRequests
| take 10

B.

AppRequests
| project Name, Success

C.

AppRequests
| summarize avg(DurationMs) by Name

D.

AppRequests
| where Success == false
| summarize FailureCount = count() by Name
| order by FailureCount desc

Answer: D

Explanation

The query filters for failed requests, groups those failures by endpoint name, counts the failures, and sorts the endpoints from the highest failure count to the lowest. This is an effective way to identify which API endpoints are contributing most to the incident.

Final Exam Perspective

The most important thing to remember for this AI-200 topic is that KQL is fundamentally about turning large volumes of telemetry into actionable information.

A scenario might give you thousands or millions of log records and ask you to determine:

What failed?

Use where.

How many failed?

Use summarize count() or countif().

Where did the failures occur?

Use summarize ... by.

When did they occur?

Use bin() with a timestamp.

Which endpoint is the slowest?

Use summarize avg() or inspect individual records with order by.

What happened during the last hour?

Use ago(1h).

What does the trend look like?

Use time-based summarize and render timechart.

What information do I actually need to see?

Use project.

If you can recognize these patterns quickly, you will be well prepared for the KQL-related scenario questions in AI-200. Azure Monitor’s KQL capabilities are specifically designed for exploring logs, transforming and aggregating telemetry, identifying patterns and anomalies, troubleshooting applications, and supporting alerts and reports.

Go to the AI-200 Exam Prep Hub main page