[receiver/azuremonitorreceiver] feat: multi subscriptions support and automatic discovery #36612
Assignees
Labels
Comments
celian-garcia
added
enhancement
|
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This was referenced Dec 17, 2024
This was referenced Jan 13, 2025
|
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
|
Not stale, the PR is still needing review. |
This was referenced Feb 11, 2025
Fiery-Fenix
pushed a commit
to Fiery-Fenix/opentelemetry-collector-contrib
that referenced
this issue
Apr 24, 2025
… automatic discovery (open-telemetry#37167) Recreated from a diffferent fork. Context: open-telemetry#36467 > <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. > Ex. Adding a feature - Explain what this achieves.--> > #### Description > > This PR allows to discover and scrape all the subscriptions located in the tenant. > I'm adding also at the same time the ability to give multiple subscriptions as it's free and can also be desired. > > This is a part of this PR: open-telemetry#29593 that has been split for readability. > Indeed in a next PR, I'll propose the usage of the getBatch of metrics Azure API. Because if your tenant contains a lot of subscription, you can face rate limitations. > > > It contains also a little refactor of the tests and the "backdoor" used to mock the API. Now the tests are using the way provided by Azure: the fake API. https://github.com/Azure/azure-sdk-for-go/tree/main/sdk/samples/fakes > The "backdoor" is now only the client options. So no weird interfaces nor weird constructor for the Azure clients inside the ``scraper.go`` file. > > <!-- Issue number (e.g. open-telemetry#1234) or full URL to issue, if applicable. --> > #### Link to tracking issue > Fixes open-telemetry#36612 > > <!--Describe what testing was performed and which tests were added.--> > #### Testing > > <!--Describe the documentation added.--> > #### Documentation > > <!--Please delete paragraphs that you did not use before submitting.--> Thanks to the tests refactoring, closes open-telemetry#31264 (at best it fixes it, at worst this makes it obsolete), relates also open-telemetry#38639 Signed-off-by: Célian Garcia <[email protected]> Co-authored-by: Joshua MacDonald <[email protected]> Co-authored-by: Antoine Toulme <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Component(s)
receiver/azuremonitor
Is your feature request related to a problem? Please describe.
When a tenant contains multiple subscriptions, if a new one is created you have to create a new receiver.
Describe the solution you'd like
I want to be able to say "take all the subscriptions of the tenant"
Describe alternatives you've considered
Maintaining a config but too painful.
Additional context
For an additional context, I'd like to create a new PR after that to revive the topic of the batch api usage. #29593
The idea is that if you have many subscription with many resources, you can be rate limited by Azure with the current get of Resource metrics. Using the batch API, you don't have anymore the problems of rate limitation. We're using already it from a fork in Amadeus for 1 year and it's promising.
The text was updated successfully, but these errors were encountered: