Introducing new Azure Monitor libraries for querying Logs and Metrics **Beta**

Scott Addie

Azure Monitor helps you maximize the availability and performance of your apps. It delivers a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments.

All data collected by Azure Monitor fits into one of two fundamental types:

  • Metrics—Numerical values that describe some aspect of a system at a particular point in time. They’re lightweight and can support near real-time scenarios.
  • Logs—Contain different kinds of data organized into records with different sets of properties for each type. In addition to performance data, telemetry such as events, exceptions, and traces are stored as Logs.

To better support analyzing these data sources, we’re pleased to announce the 1.0 Beta 1 release of the Azure Monitor Query client library. The library:

This blog post will highlight new features of the library.

Azure Monitor Query library highlights

The new packages offer the following benefits over their predecessors.

Unified client library

Before this release, the libraries used for querying Logs and Metrics data were maintained as separate packages. The two distinct querying libraries have been combined into a single package. The table below lists packages being replaced by these new packages.

Language New package Old packages being replaced
.NET Azure.Monitor.Query
Java com.azure/azure-monitor-query
JavaScript / TypeScript @azure/monitor-query
Python azure-monitor-query

New client library features

The new libraries were updated to include the following new features:

Batch API for Logs query

The new libraries support the execution of multiple Logs queries in a single request. Consider this C# example, which executes two Kusto queries:

// code omitted for brevity

var client = new LogsQueryClient(endpoint, new DefaultAzureCredential());

// Query TOP 10 resource groups by event count
// And total event count
var batch = new LogsBatchQuery();
string countQueryId = batch.AddQuery(
    workspace: workspaceId,
    query: "AzureActivity | count",
    timeRange: TimeSpan.FromDays(1));
string topQueryId = batch.AddQuery(
    workspace: workspaceId, 
    query: "AzureActivity | summarize Count = count() by ResourceGroup | top 10 by Count",
    timeRange: TimeSpan.FromDays(1));

Response<LogsBatchQueryResult> response = await client.QueryBatchAsync(batch);

Performance statistics

Logs query performance statistics, such as execution time and resource usage, can be included in the response by opting in. Consider the following C# example, which opts in via the LogsQueryOptions class’ IncludeStatistics property:

// code omitted for brevity

var client = new LogsQueryClient(endpoint, new DefaultAzureCredential());
Response<LogsQueryResult> response = await client.QueryAsync(
    workspaceId, "AzureActivity | top 10 by TimeGenerated", TimeSpan.FromDays(1),
    new LogsQueryOptions
    {
        IncludeStatistics = true
    });

Server timeout

Logs query execution times vary widely based on several factors. Examples of such factors include:

  • The query’s complexity.
  • The amount of data being analyzed.
  • The system and workspace load at the time of the query.

Some Logs queries take longer than three minutes to execute. The default server timeout is three minutes. With the new libraries, you can increase the server timeout to a maximum of 10 minutes. Consider the following C# example, which sets the server timeout to five minutes:

// code omitted for brevity

var client = new LogsQueryClient(endpoint, new DefaultAzureCredential());
Response<LogsQueryResult> response = await client.QueryAsync(
    workspaceId, "AzureActivity | top 10 by TimeGenerated", TimeSpan.FromDays(1),
    new LogsQueryOptions
    {
        ServerTimeout = TimeSpan.FromMinutes(5)
    });

Handwritten client libraries

Except for the .NET library, code generation was used to produce the old libraries. The new libraries for Java, JavaScript/TypeScript, and Python are handwritten to achieve parity with .NET. Per the design principles for the new Azure SDK libraries, the libraries strive to be idiomatic. As a developer in the target language, interacting with the library should feel natural.

Azure Active Directory authentication

The new library includes Azure Active Directory authentication support for both Logs and Metrics queries. Azure Identity is used, which improves the local development experience in editors and IDEs. Some popular examples include IntelliJ, Visual Studio Code, and Visual Studio.

Conclusion

The Azure Monitor Query libraries have enhanced querying Logs and Metrics data sources. To get started with the library, see the language-specific instructions below.

For language-specific examples, see the following code samples:

You’re encouraged to provide feedback before the library reaches general availability. To report issues or send feedback to the Azure SDK engineering team, use the language-specific links below:

Azure SDK Blog Contributions

Thank you for reading this Azure SDK blog post! We hope that you learned something new and welcome you to share this post. We are open to Azure SDK blog contributions. Please contact us at azsdkblog@microsoft.com with your topic and we’ll get you set up as a guest blogger.

2 comments

Discussion is closed. Login to edit/delete existing comments.

  • ZippyV 0

    What’s the difference between these libraries and Microsoft.Azure.Management.Monitor?

    • Scott AddieMicrosoft employee 0

      Microsoft.Azure.Management.Monitor is focused on managing Azure Monitor resources. For example, creation, deletion, and adding alerts. It’s an older library that doesn’t follow the new Azure SDK design guidelines. It also doesn’t support querying customer data in the Monitor resource (that’s what Azure.Monitor.Query is for).

      There is, however, a little bit of overlap. For example, both libraries support listing Metrics definitions and namespaces.

Feedback usabilla icon