Cherry-pick #19181 to 7.x: Cache error responses for cloudfoundry apps metadata #19638
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cache error responses when requesting Cloud Foundry apps metadata to avoid hitting continuously the API when there are missing applications. (cherry picked from commit 9c0b63d)
jsoriano
added
[zube]: In Review
backport
Team:Platforms
|
Pinging @elastic/integrations-platforms (Team:Platforms) |
botelastic
bot
added
needs_team
❕ Build Aborted
Expand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of PR #19181 to 7.x branch. Original message:
What does this PR do?
Cache error responses when requesting Cloud Foundry apps metadata to
avoid hitting continuously the API when there are failures.
The original motivation for this change was to handle
AppNotFounderrors,but the truth is that continuously retrying on any error is not very good, so
this change effectively introduces a delay between retries on any error from
the API. It looks safer by now. We can reconsider this in the future if we see
that some other error should be handled in a different way.
An specific flag
cache_retry_delayis also added to configure how long Beatsshould wait before retrying again in case of error.
Why is it important?
Sometimes events are received for apps that cannot be found on the API, on
these cases Beats continuously hit the API to try to get the metadata. This
provokes unnecessary load on API servers of big deployments.
Checklist
I have made corresponding change to the default configuration filesCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.