-
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
[Fleet] Support Fleet server system indices #89372
[Fleet] Support Fleet server system indices #89372
Conversation
f41c0bc
to
599fe99
Compare
599fe99
to
9e777e5
Compare
331435f
to
71b1942
Compare
…-server-agent-routes
…-server-agent-routes
Pinging @elastic/ingest-management (Team:Ingest Management) |
…-server-agent-routes
…-server-agent-routes
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.
@nchaulet Did you get a chance to review my notes in this comment? The ES errors still occur: #89372 (comment) If this is just a known limitation right now that Fleet server needs to be started after Fleet setup is done, then that's fine, but let's make sure we confirm that.
I'm now seeing this Kibana error being logged when Fleet server is enabled, this is preventing the agent list from appearing:
server log [17:35:09.610] [error][fleet][plugins] TypeError: kuery.replace is not a function
at removeSOAttributes (/Users/jen/Projects/kibana/x-pack/plugins/fleet/server/services/agents/crud_fleet_server.ts:35:16)
at Object.listAgents (/Users/jen/Projects/kibana/x-pack/plugins/fleet/server/services/agents/crud_fleet_server.ts:61:18)
at listAgents (/Users/jen/Projects/kibana/x-pack/plugins/fleet/server/services/agents/crud.ts:29:30)
at concurrency (/Users/jen/Projects/kibana/x-pack/plugins/fleet/server/services/agents/status.ts:67:7)
at /Users/jen/Projects/kibana/node_modules/p-map/index.js:57:28
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
server error [17:35:09.583] Error: Internal Server Error
at HapiResponseAdapter.toError (/Users/jen/Projects/kibana/src/core/server/http/router/response_adapter.ts:122:19)
at HapiResponseAdapter.toHapiResponse (/Users/jen/Projects/kibana/src/core/server/http/router/response_adapter.ts:72:19)
at HapiResponseAdapter.handle (/Users/jen/Projects/kibana/src/core/server/http/router/response_adapter.ts:67:17)
at Router.handle (/Users/jen/Projects/kibana/src/core/server/http/router/router.ts:273:34)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at handler (/Users/jen/Projects/kibana/src/core/server/http/router/router.ts:227:11)
at exports.Manager.execute (/Users/jen/Projects/kibana/node_modules/@hapi/hapi/lib/toolkit.js:60:28)
at Object.internals.handler (/Users/jen/Projects/kibana/node_modules/@hapi/hapi/lib/handler.js:46:20)
at exports.execute (/Users/jen/Projects/kibana/node_modules/@hapi/hapi/lib/handler.js:31:20)
at Request._lifecycle (/Users/jen/Projects/kibana/node_modules/@hapi/hapi/lib/request.js:370:32)
at Request._execute (/Users/jen/Projects/kibana/node_modules/@hapi/hapi/lib/request.js:279:9)
I did some testing on when Fleet server is not enabled, and things look good. I know we don't expect Fleet server integration to be perfect yet, but the above error is blocking for me for this PR. I'm happy to give a 👍🏻 once that's resolved and I get another round of successful non-Fleet server testing.
@@ -78,6 +80,7 @@ async function createAction( | |||
) { | |||
const body: FleetServerAgentAction = { | |||
'@timestamp': new Date().toISOString(), | |||
expiration: new Date(Date.now() + ONE_MONTH_IN_MS).toISOString(), |
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.
wow that's a long expiration! 😄 what does tell fleet server to do?
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.
It's mandatory for Fleet server actions to have an expiration, it just say if the agent connect after more than 1 month to fleet server the agent will not get the action.
@jen-huang thanks for testing this again and again. I missed the For the error in the logs, the way Fleet server check for the indice to be present, is by trying to search this indices so the error in the logs is "okay" and should not affect how Fleet Server works we could probably improve that by checking if the index is present and ready. |
@kevinlog I would love a review from endpoint on that one, I tested with the flagged turn off and nothing looks broken on your end. |
…-server-agent-routes
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.
Tested locally again today and am not seeing any issues when feature flag is disabled. I tested with feature flag enabled too (which also did a light test of the SO->indices migrations) and found that the kuery
error is resolved and I didn't see any major issues apart from known ones while we continue to work on supporting Fleet server.
Thanks for iterating on this with my testing @nchaulet and great work!!
@nchaulet my testing steps:
The above worked with the feature flag both ON and OFF. Other than that, looks good! |
@@ -54,7 +54,11 @@ export function registerDownloadExceptionListRoute( | |||
// The ApiKey must be associated with an enrolled Fleet agent | |||
try { | |||
scopedSOClient = endpointContext.service.getScopedSavedObjectsClient(req); | |||
await authenticateAgentWithAccessToken(scopedSOClient, req); | |||
await authenticateAgentWithAccessToken( |
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.
@paul-tavares FYI
with the feature flag OFF artifacts were still being downloaded
I've found one more issue I think, I've had a case where my agents were assigned to the policy that was removed and when I tried to reassign agents to the new policy I was getting an error that I've had to wrap this line into try/catch block to make sure that saved object error is not being thrown
|
@elasticmachine merge upstream |
@patrykkopycinski I think the bug existed before that PR, I am wondering how did you remove the policy? normally we cannot delete a policy with active agents, maybe there is a bug here. I will merge that PR as it is to avoid more conflict, but we should still iterate on that |
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
* master: (55 commits) [APM-UI][E2E] use githubNotify step (elastic#90514) [APM] Export ProcessorEvent type (elastic#90540) [Lens] Retain column config (elastic#90048) [Data Table] Add unit tests (elastic#90173) Migrate most plugins to synchronous lifecycle (elastic#89562) skip flaky suite (elastic#90555) skip flaky suite (elastic#64473) [actions] improve email action doc (elastic#90020) [Fleet] Support Fleet server system indices (elastic#89372) skip flaky suite (elastic#90552) Bump immer dependencies (elastic#90267) Unrevert "Migrations v2: don't auto-create indices + FTR/esArchiver support (elastic#85778)" (elastic#89992) [Search Sessions] Use sync config (elastic#90138) chore(NA): add safe guard to remove bazelisk from yarn global at bootstrap (elastic#90538) [test] Await retry.waitFor (elastic#90456) chore(NA): integrate build buddy with our bazel setup and remote cache for ci (elastic#90116) Skip failing suite (elastic#90526) [Fleet] Fix incorrect conversion of string to numeric values in agent YAML (elastic#90371) [Docs] Update reporting troubleshooting for arm rhel/centos (elastic#90385) chore(NA): build bazel projects all at once in the distributable build process (elastic#90328) ...
Thanks for reporting @patrykkopycinski, agree with @nchaulet that this is existing behavior. I've opened an issue for that #90625. To be honest I am surprised at the behavior, I thought we had some conditions to not be able to delete a policy if active agents are enrolled into it, but maybe not 🤔 |
Summary
Related to #87372
Follow #86179
To support Fleet Server we need to use
.fleet*
system indices instead of saved object for agents enrollment keys and agents, this PR add this.What to expect/test
with the feature flag
xpack.fleet.agents.fleetServerEnabled: false
Kibana should use the SO and all the features should work as expected, you should be able to enroll an agent through Kibana, endpoint should work.
with the feature flag
xpack.fleet.agents.fleetServerEnabled: true
without Fleet ServerKibana should use the
.fleet
indices and all the features should work as expected, you should be able to enroll an agent through Kibana, endpoint should work.with the feature flag
xpack.fleet.agents.fleetServerEnabled: true
and Fleet ServerKibana should use the
.fleet
indices and all the features should work as expected,What is not yet working