Azure monitor
Azure Monitor is a monitoring solution that collects and aggregates data for further interpretation and response.
Nobl9 integration with Azure Monitor supports collecting Azure Monitor metrics, including Application Insights. With it, Nobl9 users can retrieve metrics and build SLOs based on them.
Azure Monitor parameters and supported features in Nobl9
- General support:
- Release channel: Beta
- Connection method: Agent, Direct
- Replay and SLI Analyzer: Supported
- Event logs: Supported
- Query checker: Not supported
- Query parameters retrieval: Supported
- Timestamp cache persistence: Supported
- Query parameters:
- Query interval: 1 min
- Query delay: 5 min
- Jitter: 15 sec
- Timeout: 60 sec
- Agent details and minimum required versions for supported features:
- Environment variable:
AZURE_MONITOR_QUERY_DELAY
- Plugin name:
n9azure_monitor
- Replay and SLI Analyzer:
0.69.0-beta01
- Maximum historical data retrieval period:
30 days
- Query parameters retrieval:
0.71.0-beta
- Timestamp cache persistence:
0.69.0-beta01
- Additional notes:
- Support for Azure Monitor Metrics and Azure Monitor Logs
- Learn more
Ensure the metrics you use support a one-minute (1-minute) aggregation window (time grain).
Authenticationβ
To set up the Nobl9 direct connection,
you must provide your Azure application's client ID
and client secret
.
For this:
- Register an Azure application.
- To use Azure Monitor Logs, set up Log Analytics API permission.
- Assign your Azure application the Monitoring Reader role for the Azure resources
you want to read metrics from.
This role meets the Nobl9 requirements for metric collection. - Grant your application the
Microsoft.Resources/subscriptions/resourceGroups/read
permission.
It enables resource and metric autocompletion during SLO creation.
You can also use sloctl
.
This way, you can configure SLOs for your Azure Cloud application without the resource and metric autocompletion.
We recommend granting the Monitoring Reader role on the subscription or resource group level rather than a specific resource. A broader scope provides a more comprehensive choice of subscriptions, resource groups, resources, and metrics in the Nobl9 platform.
Adding Azure Monitor as a data sourceβ
You can add the Azure Monitor data source using the direct or agent connection methods.
Direct connection methodβ
Nobl9 Webβ
- Navigate to Integrations > Sources.
- Click .
- Click the required Source button.
- Choose Direct.
-
Enter your Azure Tenant ID.
It is an8-4-4-4-12
-character code containing digits0-9
and lettersAa-Ff
. -
Enter your Microsoft Entra Client ID and Client Secret.
To retrieve Azure application's client ID and client secret, find your required application under App Registrations within the Azure Portal.
- Select a Project.
Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, Nobl9 uses thedefault
project. - Enter a Display Name.
You can enter a user-friendly name with spaces in this field. - Enter a Name.
The name is mandatory and can only contain lowercase, alphanumeric characters, and dashes (for example,my-project-1
). Nobl9 duplicates the display name here, transforming it into the supported format, but you can edit the result. - Enter a Description.
Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it. - Specify the Query delay to set a customized delay for queries when pulling the data from the data source.
- The default value in Azure Monitor integration for Query delay is
5 minutes
.
infoChanging the Query delay may affect your SLI data. For more details, check the Query delay documentation. - The default value in Azure Monitor integration for Query delay is
- Enter a Maximum Period for Historical Data Retrieval.
- This value defines how far back in the past your data will be retrieved when replaying your SLO based on this data source.
- The maximum period value depends on the data source.
Find the maximum value for your data source. - A greater period can extend the loading time when creating an SLO.
- The value must be a positive integer.
- Enter a Default Period for Historical Data Retrieval.
- It is used by SLOs connected to this data source.
- The value must be a positive integer or
0
. - By default, this value is set to 0. When you set it to
>0
, you will create SLOs with Replay.
- Click Add Data Source
sloctlβ
The YAML for setting up a direct connection to Azure Monitor looks like this:
apiVersion: n9/v1alpha
kind: Direct
metadata:
name: azure-monitor
displayName: Azure Monitor
project: azure-monitor
spec:
description: Direct integration with Azure Monitor
sourceOf:
- Metrics
queryDelay:
unit: Minute
value: 5 # For current operation, must be a number from 5 to 1440 minutes (24 hours)
logCollectionEnabled: false # boolean, defaults to 'false'. Set to true if you'd like your source to collect logs. Available for data sources connected using the direct method only. Reach out to support@nobl9.com to activate it.
releaseChannel: beta # For Azure monitor, the only accepted value is beta
azureMonitor:
tenantID: <YOUR_AZURE_TENANT_ID>
clientID: <YOUR_AZURE_APPLICATION_CLIENT_ID>
clientSecret: <YOUR_AZURE_APPLICATION_CLIENT_SECRET>
historicalDataRetrieval:
maxDuration:
value: 30
unit: Day
defaultDuration:
value: 0
unit: Day
Field | Type | Description |
---|---|---|
queryDelay.unit mandatory | enum | Specifies the unit for the query delay. Possible values: Second | Minute . β’ Check query delay documentation for default unit of query delay for each source. |
queryDelay.value mandatory | numeric | Specifies the value for the query delay. β’ Must be a number less than 1440 minutes (24 hours). β’ Check query delay documentation for default unit of query delay for each source. |
logCollectionEnabled optional | boolean | Optional. Defaults to false . Set to true if you'd like your direct to collect event logs. Contact us to activate it. |
releaseChannel mandatory | enum | Specifies the release channel. Accepted values: beta | stable . |
Source-specific fields | ||
azureMonitor.tenantID mandatory | string, secret | The identifier of your Microsoft Entra tenant. |
azureMonitor.clientID mandatory | string | See authentication section above for more details. |
azureMonitor.clientSecret mandatory | string | See authentication section above for more details. |
Replay-related fields | ||
historicalDataRetrieval optional | n/a | Optional structure related to configuration related to Replay. β Use only with supported sources. β’ If omitted, Nobl9 uses the default values of value: 0 and unit: Day for maxDuration and defaultDuration . |
maxDuration.value optional | numeric | Specifies the maximum duration for historical data retrieval. Must be integer β₯ 0 . See Replay documentation for values of max duration per data source. |
maxDuration.unit optional | enum | Specifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
defaultDuration.value optional | numeric | Specifies the default duration for historical data retrieval. Must be integer β₯ 0 and β€ maxDuration . |
defaultDuration.unit optional | enum | Specifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
Agent connection methodβ
Nobl9 Webβ
- Navigate to Integrations > Sources.
- Click .
- Click the required Source button.
- Choose Agent.
- Enter your Azure Tenant ID.
It is an8-4-4-4-12
-character code containing digits0-9
and lettersAa-Ff
.
- Select a Project.
Specifying a project is helpful when multiple users are spread across multiple teams or projects. When the Project field is left blank, Nobl9 uses thedefault
project. - Enter a Display Name.
You can enter a user-friendly name with spaces in this field. - Enter a Name.
The name is mandatory and can only contain lowercase, alphanumeric characters, and dashes (for example,my-project-1
). Nobl9 duplicates the display name here, transforming it into the supported format, but you can edit the result. - Enter a Description.
Here you can add details such as who is responsible for the integration (team/owner) and the purpose of creating it. - Specify the Query delay to set a customized delay for queries when pulling the data from the data source.
- The default value in Azure Monitor integration for Query delay is
5 minutes
.
infoChanging the Query delay may affect your SLI data. For more details, check the Query delay documentation. - The default value in Azure Monitor integration for Query delay is
- Enter a Maximum Period for Historical Data Retrieval.
- This value defines how far back in the past your data will be retrieved when replaying your SLO based on this data source.
- The maximum period value depends on the data source.
Find the maximum value for your data source. - A greater period can extend the loading time when creating an SLO.
- The value must be a positive integer.
- Enter a Default Period for Historical Data Retrieval.
- It is used by SLOs connected to this data source.
- The value must be a positive integer or
0
. - By default, this value is set to 0. When you set it to
>0
, you will create SLOs with Replay.
- Click Add Data Source
sloctlβ
The YAML for setting up an agent connection to Azure Monitor is as follows:
apiVersion: n9/v1alpha
kind: Agent
metadata:
name: azure-monitor
displayName: Azure Monitor
project: azure-monitor
spec:
description: Azure Monitor agent
sourceOf:
- Metrics
releaseChannel: beta
queryDelay:
unit: Minute
value: 5 # numeric, must be a number from 5 to 1440 minutes (24 hours)
azureMonitor:
tenantId: <YOUR_AZURE_AD_TENANT_ID>
historicalDataRetrieval:
maxDuration:
value: 30
unit: Day
defaultDuration:
value: 0
unit: Day
Field | Type | Description |
---|---|---|
queryDelay.unit mandatory | enum | Specifies the unit for the query delay. Possible values: Second | Minute . β’ Check query delay documentation for default unit of query delay for each source. |
queryDelay.value mandatory | numeric | Specifies the value for the query delay. β’ Must be a number less than 1440 minutes (24 hours). β’ Check query delay documentation for default unit of query delay for each source. |
releaseChannel mandatory | enum | Specifies the release channel. Accepted values: beta | stable . |
Source-specific fields | ||
azureMonitor.tennantID mandatory | string, secret | It's the identifier of your Microsoft Entra tenant. |
Replay-related fields | ||
historicalDataRetrieval optional | n/a | Optional structure related to configuration related to Replay. β Use only with supported sources. β’ If omitted, Nobl9 uses the default values of value: 0 and unit: Day for maxDuration and defaultDuration . |
maxDuration.value optional | numeric | Specifies the maximum duration for historical data retrieval. Must be integer β₯ 0 . See Replay documentation for values of max duration per data source. |
maxDuration.unit optional | enum | Specifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
defaultDuration.value optional | numeric | Specifies the default duration for historical data retrieval. Must be integer β₯ 0 and β€ maxDuration . |
defaultDuration.unit optional | enum | Specifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
Agent deploymentβ
When you add the data source,
Nobl9 automatically generates a Kubernetes configuration and a Docker command line for you to use to deploy the agent.
Both of these are available in the web UI, under the Agent Configuration section.
Be sure to swap in your credentials
(e.g., replace the <YOUR_AZURE_APPLICATION_CLIENT_ID>
and <YOUR_AZURE_APPLICATION_CLIENT_SECRET>
with your client ID and client secret).
- Kubernetes
- Docker
If you use Kubernetes, you can apply the supplied YAML config file to a Kubernetes cluster to deploy the agent. The agent facilitates Nobl9 to import your service metrics.
# DISCLAIMER: This deployment description contains only the fields necessary for the purpose of this demo.
# It is not a ready-to-apply k8s deployment description, and the client_id and client_secret are only exemplary values.
apiVersion: v1
kind: Secret
metadata:
name: nobl9-agent-nobl9-azure-agent
namespace: default
type: Opaque
stringData:
azure_client_id: "<YOUR_AZURE_APPLICATION_CLIENT_ID>"
azure_client_secret: "<YOUR_AZURE_APPLICATION_CLIENT_SECRET>"
client_id: "<UNIQUE_CLIENT_ID>"
client_secret: "<UNIQUE_CLIENT_SECRET>"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nobl9-agent-nobl9-azure-agent
namespace: default
spec:
replicas: 1
selector:
matchLabels:
nobl9-agent-name: "azure-agent"
nobl9-agent-project: "default"
nobl9-agent-organization: "nobl9"
template:
metadata:
labels:
nobl9-agent-name: "azure-agent"
nobl9-agent-project: "default"
nobl9-agent-organization: "nobl9"
spec:
containers:
- name: agent-container
image: nobl9/agent:0.88.0-beta
resources:
requests:
memory: "700Mi"
cpu: "0.2"
env:
- name: N9_CLIENT_ID
valueFrom:
secretKeyRef:
key: client_id
name: nobl9-agent-nobl9-azure-agent
- name: N9_AZURE_MONITOR_CLIENT_ID
valueFrom:
secretKeyRef:
key: azure_client_id
name: nobl9-agent-nobl9-azure-agent
- name: N9_AZURE_MONITOR_CLIENT_SECRET
valueFrom:
secretKeyRef:
key: azure_client_secret
name: nobl9-agent-nobl9-azure-agent
- name: N9_CLIENT_SECRET
valueFrom:
secretKeyRef:
key: client_secret
name: nobl9-agent-nobl9-azure-agent
- name: N9_AUTH_SERVER
value: "<UNIQUE_VALUE>"
- name: N9_METRICS_PORT
value: "9090"
- name: N9_DIAGNOSTIC_QUERY_LOG_SAMPLE_INTERVAL_MINUTES
value: "10"
Important notes:
- The
N9_METRICS_PORT
is a variable specifying the port to which the/metrics
and/health
endpoints are exposed. 9090
is the default value and can be changed.- If you donβt want the metrics to be exposed, comment out or delete the
N9_METRICS_PORT
variable. N9_DIAGNOSTIC_QUERY_LOG_SAMPLE_INTERVAL_MINUTES
sets the frequency of log emission for SLI analyzer. The default value is10
. To deactivate log emission, set this value to0
.
If you use Docker, you can run the provided Docker command to deploy the agent. The agent facilitates Nobl9 to import your service metrics.
# DISCLAIMER: This Docker command contains only the fields necessary for the purpose of this demo.
# It is not a ready-to-apply command, and you will need to replace the placeholder values with your own values.
docker run -d --restart on-failure \
--name nobl9-agent-nobl9-azure-agent \
-e N9_AUTH_SERVER="authorization_server" \
-e N9_CLIENT_SECRET="<UNIQUE_CLIENT_SECRET>" \
-e N9_METRICS_PORT=9090 \
-e N9_CLIENT_ID="<UNIQUE_CLIENT_ID>" \
-e N9_AZURE_MONITOR_CLIENT_ID="<YOUR_AZURE_APPLICATION_CLIENT_ID>" \
-e N9_AZURE_MONITOR_CLIENT_SECRET="<YOUR_AZURE_APPLICATION_CLIENT_SECRET>" \
-e N9_DIAGNOSTIC_QUERY_LOG_SAMPLE_INTERVAL_MINUTES=10 \
nobl9/agent:0.88.0-beta
Important notes:
- The
N9_METRICS_PORT
is a variable specifying the port to which the/metrics
and/health
endpoints are exposed. 9090
is the default value and can be changed.- If you donβt want the metrics to be exposed, comment out or delete the
N9_METRICS_PORT
variable. N9_DIAGNOSTIC_QUERY_LOG_SAMPLE_INTERVAL_MINUTES
sets the frequency of log emission for SLI analyzer. The default value is10
. To deactivate log emission, set this value to0
.
Creating SLOs with Azure Monitorβ
Nobl9 integration with Azure Monitor supports Azure Monitor Metrics and Azure Monitor Logs data types.
For the both data types, you can create threshold metric and ratio good
or bad
over total
metrics.
These methods are available in the UI and by
applying YAML via sloctl
.
Nobl9 Webβ
Follow the instructions below to create your SLOs with Azure Monitor in the UI:
-
Navigate to Service Level Objectives.
-
Click .
-
Select a Service.
It will be the location for your SLO in Nobl9. -
Select your Azure Monitor data source.
-
Modify Period for Historical Data Retrieval, when necessary.
- This value defines how far back in the past your data will be retrieved when replaying your SLO based on Azure Monitor.
- A longer period can extend the data loading time for your SLO.
- Must be a positive whole number up to the maximum period value you've set when adding the Azure Monitor data source.
-
Select the Data Type:
- Azure Monitor Metrics
- Azure Monitor Logs
Azure Monitor Metrics to capture numeric data from your monitored resources.
- Specify the Resource you need to collect metrics for.
Set the path to your required resource using the Subscription, Resource Group, and Resource fields. Make sure your selected resource holds the metrics you need to collect. - Select Namespace in the list of available, when required.
It's a way Azure Monitor groups similar metrics together. - Configure Metric:
Select the metric type.
- A Threshold metric where a single time series is evaluated against a threshold.
A Ratio metric that allows you to enter two-time series for comparison. You can choose one of the following metric types:
- Good metric, meaning a ratio of
good
requests andtotal
requests. - Bad metric, meaning a ratio of
bad
requests andtotal
requests.
- Good metric, meaning a ratio of
- Choose the Data Count Method for your ratio metric:
- Non-incremental: counts incoming metric values one-by-one. So the resulting SLO graph is pike-shaped.
- Incremental: counts the incoming metric values incrementally, adding every next value to previous values. It results in a constantly increasing SLO graph.
- Select the Metric Name in the list of available metrics.
When you cannot find the required metric name in the list or the list displays No matching data, check if your selected resource holds the metric you need. Choose metric Aggregation to determine processing of the incoming data.
- The following aggregations are available:
- Sum: the sum of all datapoints in an aggregation window
- Average: the average of datapoints per aggregation window. Usually, it's
Sum/Count
- Maximum: the greatest datapoint value in an aggregation window
- Minimum: the lowest datapoint value in an aggregation window
- Count: the number of datapoints in an aggregation window. This type considers only how many data points are received, instead of datapoint values
- Select Dimensions if any are applied to your chosen metric in Azure.
You can select the Value in the list or enter the required one. Make sure your entered value is up to 255 characters (ASCII only)
Azure Monitor Logs to capture log and performance data from your monitored resources
- Specify the Resource you need to collect metrics for.
Set the path to your required logs workspace using the Subscription, Resource Group and Workspace. - Configure Metric:
Select the metric type.
- A Threshold metric where a single time series is evaluated against a threshold.
A Ratio metric that allows you to enter two-time series for comparison. You can choose one of the following metric types:
- Good metric, meaning a ratio of
good
requests andtotal
requests. - Bad metric, meaning a ratio of
bad
requests andtotal
requests.
- Good metric, meaning a ratio of
- Choose the Data Count Method for your ratio metric:
- Non-incremental: counts incoming metric values one-by-one. So the resulting SLO graph is pike-shaped.
- Incremental: counts the incoming metric values incrementally, adding every next value to previous values. It results in a constantly increasing SLO graph.
- Enter the Query.
The query uses the Kusto Query Language and is case-sensitive. - Include
n9_time
andn9_value
to the query. - The query must return
n9_time
andn9_value
to Nobl9. π‘ See query examples in Creating Azure Monitor SLOs with sloctl
countMetrics
), keep in mind that the values ββresulting from that query for both good and total:- Must be positive.
- While we recommend using integers, fractions are also acceptable.
- If using fractions, we recommend them to be larger than
1e-4
=0.0001
. - Shouldn't be larger than
1e+20
.
- Define the Time Window for your SLO:
- Rolling time windows constantly move forward as time passes. This type can help track the most recent events.
- Calendar-aligned time windows are usable for SLOs intended to map to business metrics measured on a calendar-aligned basis.
- Configure the Error budget calculation method and Objectives:
- Occurrences method counts good attempts against the count of total attempts.
- Time Slices method measures how many good minutes were achieved (when a system operates within defined boundaries) during a time window.
- You can define up to 12 objectives for an SLO.
Similar threshold values for objectivesTo use similar threshold values for different objectives in your SLO, we recommend differentiating them by setting varying decimal points for each objective.
For example, if you want to use threshold value1
for two objectives, set it to1.0000001
for the first objective and to1.0000002
for the second one.
Learn more about threshold value uniqueness. - Add the Display name, Name, and other settings for your SLO:
- Name identifies your SLO in Nobl9. After you save the SLO, its name becomes read-only.
Use only lowercase letters, numbers, and dashes. - Create Composite SLO: with this option selected, you create a composite SLO 1.0. Composite SLOs 1.0 are deprecated. They're fully operable; however, we encourage you to create new composite SLOs 2.0.
You can create composite SLOs 2.0 withsloctl
using the provided template. Alternatively, you can create a composite SLO 2.0 with Nobl9 Terraform provider. - Set Notifications on data. With it, Nobl9 will notify you in the cases when SLO won't be reporting data or report incomplete data for more than 15 minutes.
- Add alert policies, labels, and links, if required.
Up to 20 items of each type per SLO is allowed.
- Name identifies your SLO in Nobl9. After you save the SLO, its name becomes read-only.
- Click CREATE SLO
sloctlβ
countMetrics
), keep in mind that the values ββresulting from that query for both good and total:- Must be positive.
- While we recommend using integers, fractions are also acceptable.
- If using fractions, we recommend them to be larger than
1e-4
=0.0001
. - Shouldn't be larger than
1e+20
.
Azure Monitor Metricsβ
- rawMetric
- countMetric good over total
- countMetric bad over total
Hereβs an example of Azure Monitor managed service for Prometheus Metrics using a rawMetric
(the threshold metric):
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-slo
project: my-project
spec:
# Enum: Occurrences | Timeslices
budgetingMethod: Timeslices
description: ""
indicator:
metricSource:
# Your data source name identifier
name: azure-data-source
service: my-service
objectives:
- displayName: My objective 1
name: my-objective-1
# Enum: lte | lt | gte | gt
op: lte
rawMetric:
query:
azureMonitor:
dataType: metrics
resourceID: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/<PROVIDER_NAMESPACE>/<PROVIDER_TYPE>/<APP_NAME>
metricName: <METRIC_NAME>
# Enum: Sum, Count, Average, Min, Max
aggregation: Avg
# Number, float64
value: 1
target: 0.5
timeSliceTarget: 0.5
- displayName: My objective 2
name: my-objective-2
op: lte
rawMetric:
query:
azureMonitor:
dataType: metrics
resourceID: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/<PROVIDER_NAMESPACE>/<PROVIDER_TYPE>/<APP_NAME>
metricName: <METRIC_NAME>
aggregation: Avg
value: 0.5
target: 0.6
timeSliceTarget: 0.6
timeWindows:
# Number of units in a time window, integer
- count: 1
# Boolean: true for rolling time windows
isRolling: true
# Enum: Minute | Hour | Day for rolling time windows
unit: Hour
Hereβs an example of Azure Monitor managed service for Prometheus Metrics using a countMetric
(the good over total ratio):
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-slo
project: my-project
spec:
# Enum: Occurrences | Timeslices
budgetingMethod: Occurrences
description: ""
indicator:
metricSource:
# Your data source name identifier
name: azure-data-source
service: my-service
objectives:
# Number, float64
- target: 0.9
countMetrics:
good:
azureMonitor:
dataType: metrics
resourceID: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/<PROVIDER_NAMESPACE>/<PROVIDER_TYPE>/<APP_NAME>
metricName: <METRIC_NAME>
# Enum: Sum, Count, Average, Min, Max
aggregation: Sum
# Boolean
incremental: false
total:
azureMonitor:
dataType: metrics
resourceID: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/<PROVIDER_NAMESPACE>/<PROVIDER_TYPE>/<APP_NAME>
metricName: <METRIC_NAME>
aggregation: Sum
displayName: ""
# Number, float64
value: 1
name: my-objective
timeWindows:
# Number of units in a time window, integer
- count: 1
# Boolean: true for rolling time windows
isRolling: true
# Enum: Minute | Hour | Day for rolling time windows
unit: Hour
Hereβs an example of Azure Monitor managed service for Prometheus Metrics using a countMetric
(the bad over total ratio):
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-slo
project: my-project
spec:
# Enum: Occurrences | Timeslices
budgetingMethod: Occurrences
description: ""
indicator:
metricSource:
# Your data source name identifier
name: azure-data-source
service: my-service
objectives:
# Number, float64
- target: 0.9
countMetrics:
bad:
azureMonitor:
dataType: metrics
resourceID: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/<PROVIDER_NAMESPACE>/<PROVIDER_TYPE>/<APP_NAME>
metricName: <METRIC_NAME>
# Enum: Sum, Count, Average, Min, Max
aggregation: Sum
# Boolean
incremental: false
total:
azureMonitor:
dataType: metrics
resourceID: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/<PROVIDER_NAMESPACE>/<PROVIDER_TYPE>/<APP_NAME>
metricName: <METRIC_NAME>
aggregation: Sum
displayName: ""
# Number, float64
value: 10
name: my-objective
timeWindows:
# Number of units in a time window, integer
- count: 1
# Boolean: true for rolling time windows
isRolling: true
# Enum: Minute | Hour | Day for rolling time windows
unit: Hour
Azure Monitor Logsβ
- rawMetric
- countMetric good over total
- countMetric bad over total
Hereβs an example of Azure Monitor managed service for Prometheus Logs using a rawMetric
(the threshold metric):
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-slo
project: my-project
spec:
# Enum: Occurrences | Timeslices
budgetingMethod: Timeslices
description: ""
indicator:
metricSource:
# Your data source name identifier
name: azure-data-source
service: my-service
objectives:
- displayName: My objective 1
name: my-objective-1
# Enum: lte | lt | gte | gt
op: lte
rawMetric:
query:
azureMonitor:
dataType: logs
workspace:
subscriptionID: <SUBSCRIPTION_ID>
resourceGroup: <RESOURCE_GROUP>
workspaceID: <WORKSPACE_ID>
# Kusto Query Language: include the n9_value and n9_time variables
kqlQuery: |-
AppRequests
| where AppRoleName == "<APP_NAME>"
| summarize n9_value = avg(DurationMs) by bin(TimeGenerated, 15s)
| project n9_time = TimeGenerated, n9_value
# Number, float64
value: 1000
target: 0.5
timeSliceTarget: 0.5
- displayName: My objective 2
name: my-objective-2
op: lte
rawMetric:
query:
azureMonitor:
dataType: logs
workspace:
subscriptionID: <SUBSCRIPTION_ID>
resourceGroup: <RESOURCE_GROUP>
workspaceID: <WORKSPACE_ID>
kqlQuery: |-
AppRequests
| where AppRoleName == "<APP_NAME>"
| summarize n9_value = avg(DurationMs) by bin(TimeGenerated, 15s)
| project n9_time = TimeGenerated, n9_value
value: 500
target: 0.6
timeSliceTarget: 0.6
timeWindows:
# Number of units in a time window, integer
- count: 1
# Boolean: true for rolling time windows
isRolling: true
# Enum: Minute | Hour | Day for rolling time windows
unit: Hour
Hereβs an example of Azure Monitor managed service for Prometheus Logs using a countMetric
(the good over total ratio):
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-slo
project: my-project
spec:
# Enum: Occurrences | Timeslices
budgetingMethod: Timeslices
description: ""
indicator:
metricSource:
kind: Agent
# Your data source name identifier
name: azure-data-source
service: my-service
objectives:
# Number, float64
- target: 0.9
timeSliceTarget: 0.9
countMetrics:
good:
azureMonitor:
dataType: logs
workspace:
subscriptionID: <SUBSCRIPTION_ID>
resourceGroup: <RESOURCE_GROUP>
workspaceID: <WORKSPACE_ID>
# Kusto Query Language: include the n9_value and n9_time variables
kqlQuery: |-
AppRequests
| where AppRoleName == "<APP_NAME>"
| where toint(ResultCode) >= 200 and toint(ResultCode) < 400
| summarize n9_value = count() by bin(TimeGenerated, 15s)
| project n9_time = TimeGenerated, n9_value
# Boolean
incremental: false
total:
azureMonitor:
dataType: logs
workspace:
subscriptionID: <SUBSCRIPTION_ID>
resourceGroup: <RESOURCE_GROUP>
workspaceID: <WORKSPACE_ID>
kqlQuery: |-
AppRequests
| where AppRoleName == "<APP_NAME>"
| summarize n9_value = count() by bin(TimeGenerated, 15s)
| project n9_time = TimeGenerated, n9_value
displayName: ""
# Number, float64
value: 1
name: my-objective
timeWindows:
# Enum: Day | Week | Month | Quarter | Year for calendar-aligned time windows
- unit: Week
# Number of units in a time window, integer
count: 1
# Calendar-aligned time window
calendar:
# Date with time in 24h format
startTime: 2020-01-21 12:30:00
# Name as in IANA Time Zone Database
timeZone: America/New_York
Hereβs an example of Azure Monitor managed service for Prometheus Logs using a countMetric
(the bad over total ratio):
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: my-slo
project: my-project
spec:
# Enum: Occurrences | Timeslices
budgetingMethod: Timeslices
description: ""
indicator:
metricSource:
kind: Agent
# Your data source name identifier
name: azure-data-source
service: my-service
objectives:
# Number, float64
- target: 0.9
timeSliceTarget: 0.9
countMetrics:
bad:
azureMonitor:
dataType: logs
workspace:
subscriptionID: <SUBSCRIPTION_ID>
resourceGroup: <RESOURCE_GROUP>
workspaceID: <WORKSPACE_ID>
# Kusto Query Language: include the n9_value and n9_time variables
kqlQuery: |-
AppRequests
| where AppRoleName == "<APP_NAME>"
| where toint(ResultCode) == 0 or toint(ResultCode) >= 400
| summarize n9_value = count() by bin(TimeGenerated, 15s)
| project n9_time = TimeGenerated, n9_value
# Boolean
incremental: false
total:
azureMonitor:
dataType: logs
workspace:
subscriptionID: <SUBSCRIPTION_ID>
resourceGroup: <RESOURCE_GROUP>
workspaceID: <WORKSPACE_ID>
# Kusto Query Language: include the n9_value and n9_time variables
kqlQuery: |
AppRequests
| where AppRoleName == "<APP_NAME>"
| summarize n9_value = count() by bin(TimeGenerated, 15s)
| project n9_time = TimeGenerated, n9_value
displayName: ""
# Number, float64
value: 1
name: my-objective
timeWindows:
# Enum: Day | Week | Month | Quarter | Year for calendar-aligned time windows
- unit: Week
# Number of units in a time window, integer
count: 1
# Calendar-aligned time window
calendar:
# Date with time in 24h format
startTime: 2020-01-21 12:30:00
# Name as in IANA Time Zone Database
timeZone: America/New_York
Querying the Azure Monitor APIβ
The Nobl9 agent leverages the Azure Monitor Data Plane API to get data.