Skip to content
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

[WIP] Use rate limiter with all interactions with Azure Monitoring API #38127

Closed
wants to merge 1 commit into from

Conversation

zmoog
Copy link
Contributor

@zmoog zmoog commented Feb 23, 2024

Proposed commit message

The metricset uses multiple API endpoint, so we need to double-check if the max request rate applies to all endpoints or single ones.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Author's Checklist

  • Research Azure API rate limits

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

The metricset uses multiple API endpoint, so we need to double-check
if the max request rate applies to all endpoints or single ones.
@botelastic botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Feb 23, 2024
@zmoog zmoog self-assigned this Feb 23, 2024
@zmoog zmoog changed the title Use rate limiter with all interactions with Azure Monitoring API [WIP] Use rate limiter with all interactions with Azure Monitoring API Feb 23, 2024
Copy link
Contributor

mergify bot commented Feb 23, 2024

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @zmoog? 🙏.
For such, you'll need to label your PR with:

  • The upcoming major version of the Elastic Stack
  • The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

  • backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

@zmoog zmoog added the Team:Cloud-Monitoring Label for the Cloud Monitoring team label Feb 23, 2024
@botelastic botelastic bot removed the needs_team Indicates that the issue/PR needs a Team:* label label Feb 23, 2024
@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

cc @zmoog

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

cc @zmoog

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

cc @zmoog

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

cc @zmoog

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

cc @zmoog

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

cc @zmoog

@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2024-02-23T18:32:05.783+0000

  • Duration: 57 min 30 sec

Test stats 🧪

Test Results
Failed 0
Passed 1558
Skipped 96
Total 1654

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@StephanErb
Copy link

@zmoog This looks helpful, thank you! We are seeing lot of throttling errors and I would hope your PR can reduce the pain a bit.

Beyond that, have you considered to move to the Azure Monitor batch API? It offers much higher limits and should be less affected by throttling.

https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/migrate-to-batch-api?tabs=individual-response

https://learn.microsoft.com/en-us/azure/azure-monitor/service-limits

@zmoog
Copy link
Contributor Author

zmoog commented Mar 12, 2024

@zmoog This looks helpful, thank you! We are seeing lot of throttling errors and I would hope your PR can reduce the pain a bit.

Beyond that, have you considered to move to the Azure Monitor batch API? It offers much higher limits and should be less affected by throttling.

https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/migrate-to-batch-api?tabs=individual-response

https://learn.microsoft.com/en-us/azure/azure-monitor/service-limits

@StephanErb, thanks for sharing the link to Azure Monitor Batch API! It seems a great tool for efficiently getting metrics values and reducing the number of API calls.

The Azure Monitor metricset performs other API calls to list the resources and collect the existing metrics for each resource. Then, it collects the value for each metric.

The team is working on this, and we'll look more and update the PR soon.

@zmoog
Copy link
Contributor Author

zmoog commented Mar 14, 2024

Closing this PR in favour of #38294 using a different approach.

@zmoog zmoog closed this Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Cloud-Monitoring Label for the Cloud Monitoring team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants