-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Ingest Manager] Saved Object client issues after ES restart #75497
Comments
Pinging @elastic/ingest-management (Team:Ingest Management) |
Thanks for filing this issue! I know that we had seen this behavior before but didn't log it. One thing I'm curious about, is if this behavior only occurs for our SO types, or does it apply to other Kibana SOs as well? |
@elastic/kibana-platform any thoughts about how I can debug / fix? Here's the pattern we use to get the Saved Object client from a route handler and pass it to a service Are we "holding it wrong"? It feels like a flush issue which is what had me trying the Let me know if I can do anything more to help diagnose. |
@nchaulet @skh @neptunian for awareness. |
Is wiping all ES data, including |
@skh the failures / issues we're seeing aren't because
Updates not failing, but not ... updating is a challenge. |
The queries you run above are based on the SO API. I wonder if you would run the query directly on the |
My guess is that Kibana does some housekeeping on startup, including setting up its own indices and the saved object client, and makes the assumption that its indices stay where they are even if the connection to ES is intermittently lost. Restarting If I'm correct, I could well imagine that this is a scenario that is not supported, either intentionally or by oversight, hence my question. @elastic/kibana-platform is of course better qualified to answer that than I am ;-) |
@skh TL;DR: "different indexes" didn't occur to me & is looking more likely
You reminded me that I thought I saw logs from ES during the failing operations. Here's what's logged in ES during an initial or successful call to ES logs from POST /setup success (before restart)
ES logs from POST /setup after restart
I noticed there are several lines like this with
but
The "different indexes" hypothesis gets stronger 😃 I captured the logs from Kibana & ES during inital boot & restart Looking more closely at the Kibana boot logs for
That seems relevant 😃 |
Things appear to work as expected, if I start & restart ES with the local binary (like I think I misunderstood why there was no data after restarting with I think I'll close this but, either way, thanks for helping me work through this @skh |
(from https://www.elastic.co/guide/en/kibana/master/running-elasticsearch.html ) |
More info coming. This is a WIP to get started
Kibana version:
8.x
Elasticsearch version:
8.0 snapshot
Steps to reproduce:
yarn start --no-base-path
yarn es snapshot --license=trial -E xpack.security.authc.api_key.enabled=true
ingest-outputs
orepm-packages
saved objects at first:9200
Describe the feature:
After ES restarts, our SO client isn't able to read previously created saved objects. After Kibana restarts, all the expected objects are available.
Video showing flow like described above
master-fleet-setup-forceRecreate-with-ES-restart-errors-no-default-output-2048-half.m4v.zip
It affects at least two
/api/ingest_manager
routes, but didn't seem to affect the SO API (curl --user elastic:changeme -X PUT "localhost:9200/_ingest/pipeline/my-pipeline-id"
).I tried adding a
refresh: 'wait_for'
andrefresh: true
to thesoClient.create
calls but it didn't have any effectThe text was updated successfully, but these errors were encountered: