{"id":3451,"date":"2017-09-27T00:00:00","date_gmt":"2017-09-27T00:00:00","guid":{"rendered":"https:\/\/azure.microsoft.com\/blog\/azure-log-analytics-meet-our-new-query-language-2"},"modified":"2025-06-25T09:00:45","modified_gmt":"2025-06-25T16:00:45","slug":"azure-log-analytics-meet-our-new-query-language-2","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/azure-log-analytics-meet-our-new-query-language-2\/","title":{"rendered":"Azure Log Analytics \u2013 meet our new query language"},"content":{"rendered":"\n

Azure Log Analytics has recently been enhanced to work with a new query language. The query language itself actually isn\u2019t new at all, and has been used extensively by Application Insights for some time. Recently, the language and the platform it operates on have been integrated into Log Analytics, which allows us to introduce a wealth of new capabilities, and a new portal designed for advanced analytics.<\/p>\n\n\n\n

This post reviews some of the cool new features now supported. It\u2019s just the tip of the iceberg though, and you’re invited to also review the tutorials on our language site<\/a> and our Log Analytics community space<\/a>. The examples shown throughout the post can also be run in our Log Analytics playground<\/a> \u2013 a free demo environment you can always use, no registration needed.<\/p>\n\n\n\n

Pipe-away<\/h2>\n\n\n\n

Queries collect data, stored in one or more tables. Check out this basic query:<\/p>\n\n\n\n

Event<\/code><\/p>\n\n\n\n

This is as simple as you can get, but it’s still a valid query, that simply returns everything in the Event<\/i> table. Grabbing every record in a table usually means way too many results though. When analyzing data, a common first step is to review just a bunch of records from a table, and plan how to zoom in on relevant data. This is easily done with \u201ctake\u201d:<\/p>\n\n\n\n

Event
\n| take 10<\/code><\/p>\n\n\n\n

This is the general structure of queries \u2013 multiple elements separated by pipes. The output of the first element (i.e the entire Event<\/i> table) is the input of the next one. In this case, the final query output will be 10 records from the Event<\/i> table. After reviewing them, we can decide how to make our query more specific. Often, we will use where<\/i> to filter by a specific condition, such as this:<\/p>\n\n\n\n

Event
\n| where EventLevelName == \"Error\"<\/code><\/p>\n\n\n\n

This query will return all records in the table, where EventLevelName equals \u201cError\u201d (case sensitive).<\/p>\n\n\n\n

Looks like our query still returns a lot of records though. To make sense of all that data, we can use summarize<\/i>. Summarize identifies groups of records by a common value, and can also apply aggregations to each group.<\/p>\n\n\n\n

Event
\n| where EventLevelName == \"Error\"
\n| summarize count() by Computer <\/code><\/p>\n\n\n\n

This example returns the number of Events<\/i> records marked as Error, grouped by computer.<\/p>\n\n\n\n

Try it out<\/a> on our playground!<\/p>\n\n\n\n

Search<\/h3>\n\n\n\n

Sometimes we need to search across all our data, instead of restricting the query to a specific table. For this type of query, use the \u201csearch<\/i>\u201d keyword:<\/p>\n\n\n\n

search \"212.92.108.214\"
\n| where TimeGenerated > ago(1h)<\/code><\/p>\n\n\n\n

The above example searches all records from the last hour, that contain a specific IP address.<\/p>\n\n\n\n

Scanning all data could take a bit longer to run. To search for a term across a set of tables, scope the search this way:<\/p>\n\n\n\n

search in (ConfigurationData, ApplicationInsights) \"logon\" or \"login\"<\/code><\/p>\n\n\n\n

This example searches only the ConfigurationData<\/i> and ApplicationInsights<\/i> tables for records that contain the terms \u201clogon\u201d or \u201clogin\u201d.<\/p>\n\n\n\n

Note that search terms are by default case insensitive. Search queries have many variants, you can read more about them in our tabular operators<\/a>.<\/p>\n\n\n\n

Query-time custom fields<\/h4>\n\n\n\n

We often find that we want to calculate custom fields on the fly, and use them in our analysis. One way to do it is to assign our own name to automatically-created columns, such as ErrorsCount<\/i>:<\/p>\n\n\n\n

Event
\n| where EventLevelName == \"Error\"
\n| summarize ErrorsCount=count() by Computer
\n| sort by ErrorsCount<\/code><\/p>\n\n\n\n

But adding fields does not require using summarize<\/i>. The easiest way to do it is with extend:<\/i><\/p>\n\n\n\n

Event
\n| where TimeGenerated > datetime(2017-09-16)
\n| where EventLevelName == \"Error\"
\n| extend PST_time = TimeGenerated-8h
\n| where PST_time between (datetime(2017-09-17T04:00:00) .. datetime(2017-09-18T04:00:00))<\/code><\/p>\n\n\n\n

This example calculates PST_time<\/i> which is based on TimeGenerated<\/i>, but adapted from UTC to PST time zone. The query uses the new field to filter only records created between 2017-09-17 at 4 AM and 2017-09-18 at 4 AM, PST time.<\/p>\n\n\n\n

A similar operator is project<\/i>. Instead of adding the calculated field to the results set, project<\/i> keeps only the projected fields. In this example, the results will have only four columns:<\/p>\n\n\n\n

Event
\n| where EventLevelName == \"Error\"
\n| project TimeGenerated, Computer, EventID, RenderedDescription<\/code><\/p>\n\n\n\n

Try it out<\/a> on our playground.<\/p>\n\n\n\n

A complementary operator is Project-away<\/i>, which specifies columns to remove from the result set.<\/p>\n\n\n\n

Joins<\/h4>\n\n\n\n

Join merges the records of two data sets by matching values of the specified columns. This allows richer analysis, that relies on the correlation between different data sources.<\/p>\n\n\n\n

The following example joins records from two tables \u2013 Update<\/i> and SecurityEvent<\/i>:<\/p>\n\n\n\n

Update
\n| where TimeGenerated > ago(1d)
\n| where Classification == \"Security Updates\" and UpdateState == \"Needed\"
\n| summarize missing_updates=makeset(Title) by Computer
\n| join (
\nSecurityEvent
\n| where TimeGenerated > ago(1h)
\n| summarize count() by Computer
\n) on Computer<\/code><\/p>\n\n\n\n

Let\u2019s review the two data sets being matched. The first data set is:<\/p>\n\n\n\n

Update
\n| where TimeGenerated > ago(1d)
\n| where Classification == \"Security Updates\" and UpdateState == \"Needed\"
\n| summarize missing_updates=makeset(Title) by Computer<\/code><\/p>\n\n\n\n

This takes Update<\/i> records from the last day, that describe needed security updates. It then summarizes the set of required updates per computer.<\/p>\n\n\n\n

The second data set is:<\/p>\n\n\n\n

SecurityEvent
\n| where TimeGenerated > ago(1h)
\n| summarize count() by Computer<\/code><\/p>\n\n\n\n

This counts how many of SecurityEvent<\/i> records were created in the last hour per computer.<\/p>\n\n\n\n

The common field we matched on is Computer<\/i>, so eventually we get a list of computers that each has a list of missing security updates, and the total number of security events in the last hour.<\/p>\n\n\n\n

\"join\"<\/figure>\n\n\n\n

The default visualization for most queries is a table. To visualize the data graphically, add “| render barchart<\/em>\u201d at the end of the query, or select the Chart<\/em> button shown above the results. The outcome can help us decide how to manage our next updates:<\/p>\n\n\n\n

\"barchart\"<\/figure>\n\n\n\n

We can see that the most required update is 2017-09 Cumulative Update for Windows Server<\/em> and that the 1st<\/sup> computer to handle should probably be ContosoAzADDS1.ContosoRetail.com<\/em>.<\/p>\n\n\n\n

Joins have many flavors – inner, outer, semi, etc. These flavors define how matching should be performed and what the output should be. To learn more on joins, review our joins tutorial<\/a>.<\/p>\n\n\n\n

Next steps<\/h4>\n\n\n\n

Learn more on how to analyze your data:<\/p>\n\n\n\n