-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Alerting] event log is not "disabled" when initialization fails #68309
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
I think there's a separate question of whether the event log search should also be "disabled" somehow when the the es initialization fails. I think the answer is no. Some init failures may end up leaving a working event log index available, and in those cases, it would be nice to have access to whatever is in that log - never know, it may yield a clue as to why the init failed (but seems unlikely). |
Maybe a UI indicator as well |
resolves elastic#68309 Previously, if the initialization of the elasticsearch resources failed during initialization, the event logger would still try to write events. Which is somewhat of a catastrophic failure, as typically the logger would try writing to the alias name, but no alias exists, so a new index would be created with the name of the alias. Making it impossible to initialize successfully later until that index was deleted. The core initialization calls already returned success indicators, so this PR just responds to those and prevents the logger from writing to the index if intialization failed.
resolves #68309 Previously, if the initialization of the elasticsearch resources failed during initialization, the event logger would still try to write events. Which is somewhat of a catastrophic failure, as typically the logger would try writing to the alias name, but no alias exists, so a new index would be created with the name of the alias. Making it impossible to initialize successfully later until that index was deleted. The core initialization calls already returned success indicators, so this PR just responds to those and prevents the logger from writing to the index if initialization failed.
resolves elastic#68309 Previously, if the initialization of the elasticsearch resources failed during initialization, the event logger would still try to write events. Which is somewhat of a catastrophic failure, as typically the logger would try writing to the alias name, but no alias exists, so a new index would be created with the name of the alias. Making it impossible to initialize successfully later until that index was deleted. The core initialization calls already returned success indicators, so this PR just responds to those and prevents the logger from writing to the index if initialization failed. # Conflicts: # x-pack/plugins/event_log/server/es/context.test.ts
When the event log ES initialization fails, the event log itself should be in a "disabled" state where it won't write event documents to the index. But it appears we've only done some of the work on this.
The code below is where the documents are indexed:
kibana/x-pack/plugins/event_log/server/event_logger.ts
Lines 184 to 189 in 3602f0f
The
waitTillReady()
call actually returns aboolean
indicating whether initialized completed successfully, but we don't check it. We should check the result and not write when it returns false.The value returned by
waitTillReady()
is set here:kibana/x-pack/plugins/event_log/server/es/context.ts
Lines 58 to 84 in 3602f0f
It's only set to
false
when_initialize()
throws an error, but theinitializeEs()
call in_initialize()
(scroll down to the bottom of this snippet) can also return false when an error is detected.Not immediately clear if we should even bother with these booleans set on the inner calls, when we could just throw an error instead of returning the boolean. Probably worth looking at them a little closer to see if that would be a simplification.
The text was updated successfully, but these errors were encountered: