-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
add_cloud_metadata asynchronous initialization #8845
add_cloud_metadata asynchronous initialization #8845
Conversation
Now that the add_cloud_metadata is enabled by default in all beats, we are losing 3 precious seconds every time a Beat is started outside a supported cloud environment. This patch makes the cloud detection an asynchronous task so the Beat can start and only block if initialisation is not completed at the time of the first enrichment. Running in debug mode bypasses this parallelism as the processor needs to be initialised when its String() method is called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM 😄 . Needs a changelog.
Do you have any idea of what causes the full 3 sec timeout to be reached? IIRC it would fail quickly in the normal case because each request would result in a fast "no route to host" when connecting the link-local metadata IP address. Or perhaps we added new providers that connect to different addresses.
In my case it sits waiting on an ARP response for 169.254.169.254, which is used by most cloud providers as metadata service. Maybe a misconfiguration on my network? |
I'm not sure. But I see that the Tencent provider requires a DNS lookup so at any point it could be one of several causes so I think this is a great addition. |
Love the change Adrian I’ve run into same slowdown here
On Wed, Oct 31, 2018 at 8:09 PM Andrew Kroh ***@***.***> wrote:
I'm not sure. But I see that the Tencent provider requires a DNS lookup so
at any point it could be one of several causes so I think this is a great
addition.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8845 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAACgJZ0yLxNhSyWuW0gtr3VyRGzkFUeks5uqjuigaJpZM4YEDW8>
.
--
ph
|
jenkins, test this |
Any plans to backport this? 🙏 |
@andrewkroh @exekias care to have a final look at my last update? |
Now that the add_cloud_metadata is enabled by default in all beats, we are losing 3 precious seconds every time a Beat is started outside a supported cloud environment. This patch makes the cloud detection an asynchronous task so the Beat can start and only block if initialization is not completed at the time of the first enrichment. Running in debug mode bypasses this parallelism as the processor needs to be initialized when its String() method is called. (cherry picked from commit 737a0b9)
Now that the add_cloud_metadata is enabled by default in all beats, we are losing 3 precious seconds every time a Beat is started outside a supported cloud environment. This patch makes the cloud detection an asynchronous task so the Beat can start and only block if initialization is not completed at the time of the first enrichment. Running in debug mode bypasses this parallelism as the processor needs to be initialized when its String() method is called. (cherry picked from commit 737a0b9)
Now that the add_cloud_metadata is enabled by default in all beats, we are losing 3 precious seconds every time a Beat is started outside a supported cloud environment.
This patch makes the cloud detection an asynchronous task so the Beat can start and only block if initialization is not completed at the time of the first enrichment.
Running in debug mode bypasses this parallelism as the processor needs to be initialized when its String() method is called.