-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide support for scraping multiple resource groups #294
Comments
That's a fair ask, but I have limited bandwidth so won't be able to deliver it quickly. I agree on your suggestion, but would still keep it in the Does that make sense to you? |
As a workaround you can deploy an instance per resource group and configure different scraping paths per RG - https://promitor.io/configuration/#scraping |
Agreed with work around and suggested enhancement approach. Thanks |
Actually I was giving this another thought and it feels like the current scraping boundaries are good in terms of one instance is one resource group.
What is your concern about running multiple instances or is it just because of convenience?
Imagine that you could scrape from multiple RGs, who will deploy Promitor and build the config? Wouldn't it make more sense to deploy an instance along with your app and only limited to that RG?
Building on top of that, will the services be part of same kubernetes namespace?
Just interested in the scenario here.
|
So my current pipelines are: Dev My plan is a 2 Prometheus instances, 1 for the Dev\QA\Performance\Stage running preferably off single Promitor instance. I dynamically build the metrics yaml within the pipelines, so was hoping to have a single Promitor instance for the development environments. We will also be running a separate management AKS cluster for monitoring and management activities away from the live clusters which will monitor all production queues again spread across multiple resource groups. I personally wouldn't agree that using Resource Groups are a suitable boundary and technically you can use them for multiple different containment reasons within Azure.
Within our deployment the Kubernetes namespace is ultimately irrelevant and doesn't align to any back end azure resource group. |
Well it's best practice to scope them to your unit of deployment but that is not important here, you run your platform how you want! I'm going to provide this, but it will only be as part of v1.0 which can take a little longer. It will probably look like: azureMetadata:
tenantId: c8819874-9e56-4e3f-b1a8-1c0325138f27
subscriptionId: 0f9d7fea-99e8-4768-8672-06a28514f77e
resourceGroup: RG_1
aggregation:
interval: 00:05:00
metrics:
- name: demo_generic_queue_size_rg1
description: "Amount of active messages of the 'myqueue' queue (determined with Generic provider)"
resourceType: Generic
resourceUri: Microsoft.ServiceBus/namespaces/promitor-messaging
filter: EntityName eq 'orders'
azureMetricConfiguration:
metricName: ActiveMessages
aggregation:
type: Total
- name: demo_generic_queue_size_rg2
description: "Amount of active messages of the 'myqueue' queue (determined with Generic provider)"
resourceType: Generic
resourceGroupName: RG_2
resourceUri: Microsoft.ServiceBus/namespaces/promitor-messaging
filter: EntityName eq 'orders'
azureMetricConfiguration:
metricName: ActiveMessages
aggregation:
type: Total You can define a general resource group but still override it on the metric itself. However, this brings me to subscriptions. Are you using the same subscription or not? |
Last chance for feedback @datadot |
Override is good idea, keeps existing configuration support. |
Great to hear, thanks for the feedback @datadot! I'll make the changes in next coming week(s) |
dibs |
Currently the metrics configuration is as follows:
This works for the scenario of monitoring a single set of metrics within one resource group, however best practices dictates that not all resources are located within a single resource group within a subscription. Moving the resourceGroupName to the metrics configuration would provide support for metrics from multiple resource groups within Azure.
Example configuration:
The text was updated successfully, but these errors were encountered: