-
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
Can't unenroll beats #9452
Comments
After talking with @mattapperson, the API does the right thing and return a 404, The current management workflow handles all the API errors the same way and recover from the last saved pulled config. In the case of a 404 we should instead treat it as we receive an empty configuration and show a message like this:
I am not sure if we should stop the polling of the config when this happens it some circumstances� it could be transient. |
Maybe we should return JSON of “{ found: false }” to know its not a kibana routing error? And have the beat check for that, if it exists stop retrying? |
@mattapperson I think that would make sense, because if we return false, its clear that beat cannot recover unless we enroll it again and it stop the beat to make unnecessary calls. |
Exactly, and without causing the beat to stop pinging and basically un-enrolling itself if Kibana has an issue |
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: #9452 Need backport to 6.5, 6.6, 6.x
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x (cherry picked from commit 5187335)
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x (cherry picked from commit 5187335)
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x (cherry picked from commit 5187335)
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x (cherry picked from commit 5187335)
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x (cherry picked from commit 5187335)
When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x (cherry picked from commit 5187335)
Cherry-pick of PR #9729 to 6.x branch. Original message: When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: #9452 Need backport to 6.5, 6.6, 6.x
Cherry-pick of PR #9729 to 6.6 branch. Original message: When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: #9452 Need backport to 6.5, 6.6, 6.x
Cherry-pick of PR #9729 to 6.5 branch. Original message: When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: #9452 Need backport to 6.5, 6.6, 6.x
…tic#10027) Cherry-pick of PR elastic#9729 to 6.6 branch. Original message: When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x
…tic#10028) Cherry-pick of PR elastic#9729 to 6.5 branch. Original message: When a Beat is unenrolled for CM it will receive a 404. Usually Beats will threat any errors returned by CM to be transient and will use a cached version of the configuration, this commit change the logic if a 404 is returned by CM we will clean the cache and remove any running configuration. We will log this event as either the beats did not find any configuration or was unenrolled from CM. If the error is transient, the Beat will pickup the change on the next fetch, if its permanent we will log each fetch. Fixes: elastic#9452 Need backport to 6.5, 6.6, 6.x
In 6.5.1, I used the UI to "unenroll" my beat, which appeared to work from the UI, but the beat just reported:
and continued with the last downloaded configuration.
The text was updated successfully, but these errors were encountered: