You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If demand for this is low, I recommend that I just maintain the az command in a fork of pyrra. It is quite likely since Google Cloud Observability and Amazon CloudWatch both have managed solutions for creating and managing SLO's, Azure is frantically trying to catch up and build their own managed solution. If a managed SLO solution appears in Azure the value of ./pyrra az would likely have no reason to exist. Stating that the need may be temporary.
Example Input
apiVersion: pyrra.dev/v1alpha1kind: ServiceLevelObjectivemetadata:
name: "somedomain-sb-failures-uat"namespace: "somedomain"labels:
prometheus: k8srole: alert-rulespyrra.dev/team: somedomain # Any labels prefixed with 'pyrra.dev/' will be propagated as Prometheus labels, while stripping the prefix.spec:
# We allow failing 15 request every 100 requests (85%).target: 85.0window: 4wdescription: "SLO based on failures for all SB services in the somedomain namespace."indicator:
ratio:
errors:
metric: nservicebus_messaging_failures{kubernetes_namespace="somedomain"}total:
metric: nservicebus_messaging_total{kubernetes_namespace="somedomain"}grouping:
- app_kubernetes_io_name
- nservicebus_message_type
Without this feature, the workaround is to run ./pyrra generate and then use az-prom-rules-converter utility to convert these rules to an ARM template that can be deployed to Azure Managed Prometheus.
So, it turns out bicep is a terrible format for machines to write to and looks to be more for humans to write. No go SDK for Azure Bicep. I thought of writing to ARM and then have a step to deploy to Azure after that in my pipeline. Then I discovered there is an Azure SDK for Go. There are very few examples online for Azure SDK for Go, but I hacked together my first go code I've written into this draft PR integrating updating Azure Monitor Alerting rules for Prometheus directly from Pyrra.
This is of interest to me/my org. We are facing similar limitations around managing SLOs in azure monitor.
bbrandt
changed the title
Allow Prometheus Rules to Be Generated as A Bicep File for Azure Managed Prometheus
Allow Prometheus Rules to Publish Rules to Azure Managed Prometheus
Jun 14, 2024
I have forked the repo, reviewed CONTRIBUTING.md, and am now looking at #361 as an example.
I'd like to add a
./pyrra az
command with similar behavior to thegenerate
command, but outputs a .bicep file in a format compatible with Azure Managed Prometheus. The format would be similar to https://github.com/Azure/prometheus-collector/blob/main/AddonBicepTemplate/recommendedMetricAlerts.bicep or the example .bicep below that I generated from sloth --> az-prom-rules-converter utility -->az bicep decompile --file $FILE
.If demand for this is low, I recommend that I just maintain the
az
command in a fork of pyrra. It is quite likely since Google Cloud Observability and Amazon CloudWatch both have managed solutions for creating and managing SLO's, Azure is frantically trying to catch up and build their own managed solution. If a managed SLO solution appears in Azure the value of./pyrra az
would likely have no reason to exist. Stating that the need may be temporary.Example Input
Example Bicep Output
The text was updated successfully, but these errors were encountered: