The Azure Monitor Query client module is used to execute read-only queries against Azure Monitor's two data platforms:
- Logs - Collects and organizes log and performance data from monitored resources. Data from different sources such as platform logs from Azure services, log and performance data from virtual machines agents, and usage and performance data from apps can be consolidated into a single Azure Log Analytics workspace. The various data types can be analyzed together using the Kusto Query Language. See the Kusto to SQL cheat sheet for more information.
- Metrics - Collects numeric data from monitored resources into a time series database. Metrics are numerical values that are collected at regular intervals and describe some aspect of a system at a particular time. Metrics are lightweight and capable of supporting near real-time scenarios, making them particularly useful for alerting and fast detection of issues.
Source code | Package (pkg.go.dev) | REST API documentation | Product documentation | Samples
- Go, version 1.18 or higher - Install Go
- Azure subscription - Create a free account
- To query Logs, you need one of the following things:
- An Azure Log Analytics workspace
- The resource URI of an Azure resource (Storage Account, Key Vault, Cosmos DB, etc.)
- To query Metrics, the resource URI of an Azure resource (Storage Account, Key Vault, CosmosDB, etc.) that you plan to monitor
Install the azquery
and azidentity
modules with go get
:
go get github.com/Azure/azure-sdk-for-go/sdk/monitor/azquery
go get github.com/Azure/azure-sdk-for-go/sdk/azidentity
The azidentity module is used for Azure Active Directory authentication during client construction.
An authenticated client object is required to execute a query. The examples demonstrate using azidentity.NewDefaultAzureCredential to authenticate; however, the client accepts any azidentity credential. See the azidentity documentation for more information about other credential types.
The clients default to the Azure public cloud. For other cloud configurations, see the cloud package documentation.
Example logs client
Example metrics client
Example metrics batch client
It's best practice to always query with a timespan (type TimeInterval
) to prevent excessive queries of the entire logs or metrics data set. Log queries use the ISO8601 Time Interval Standard. All time should be represented in UTC. If the timespan is included in both the Kusto query string and Timespan
field, the timespan is the intersection of the two values.
Use the NewTimeInterval()
method for easy creation.
Each set of metric values is a time series with the following characteristics:
- The time the value was collected
- The resource associated with the value
- A namespace that acts like a category for the metric
- A metric name
- The value itself
- Some metrics may have multiple dimensions as described in multi-dimensional metrics. Custom metrics can have up to 10 dimensions.
A user can also query metrics from multiple resources at once using the query_batch method of MetricsBatchClient. This uses a different API than the MetricsClient and requires that a user pass in a regional endpoint when instantiating the client (for example, "https://westus3.metrics.monitor.azure.com").
Note, each resource must be in the same region as the endpoint passed in when instantiating the client, and each resource must be in the same Azure subscription. Furthermore, the metric namespace that contains the metrics to be queried must also be passed. A list of metric namespaces can be found here.
The Log Analytics service applies throttling when the request rate is too high. Limits, such as the maximum number of rows returned, are also applied on the Kusto queries. For more information, see Query API.
If you're executing a batch logs query, a throttled request will return a ErrorInfo
object. That object's code
value will be ThrottledError
.
To run the same query against multiple Log Analytics workspaces, add the additional workspace ID strings to the AdditionalWorkspaces
slice in the Body
struct.
When multiple workspaces are included in the query, the logs in the result table are not grouped according to the workspace from which they were retrieved.
The LogsQueryOptions
type is used for advanced logs options.
-
By default, your query will run for up to three minutes. To increase the default timeout, set
LogsQueryOptions.Wait
to the desired number of seconds. The maximum wait time is 10 minutes (600 seconds). -
To get logs query execution statistics, such as CPU and memory consumption, set
LogsQueryOptions.Statistics
totrue
. -
To get visualization data for logs queries, set
LogsQueryOptions.Visualization
totrue
.
azquery.LogsClientQueryWorkspaceOptions{
Options: &azquery.LogsQueryOptions{
Statistics: to.Ptr(true),
Visualization: to.Ptr(true),
Wait: to.Ptr(600),
},
}
To do the same with QueryBatch
, set the values in the BatchQueryRequest.Headers
map with a key of "prefer", or use the NewBatchQueryRequest
method.
Get started with our examples.
-
For the majority of log queries, use the
LogsClient.QueryWorkspace
or theLogsClient.QueryResource
method. Only use theLogsClient.QueryBatch
method in advanced scenerios. -
Use
MetricsClient.QueryResource
for metric queries.
See our troubleshooting guide for details on how to diagnose various failure scenarios.
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information, see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.