Skip to content

[Fleet] Create API that queries remote kibana sync status API by output ID#217799

Merged
criamico merged 19 commits into
elastic:mainfrom
criamico:217025_remote_status_by_outputId
Apr 15, 2025
Merged

[Fleet] Create API that queries remote kibana sync status API by output ID#217799
criamico merged 19 commits into
elastic:mainfrom
criamico:217025_remote_status_by_outputId

Conversation

@criamico
Copy link
Copy Markdown
Member

@criamico criamico commented Apr 10, 2025

Part II of #217025

Summary

Create API that queries remote kibana sync status API by output ID.

From the main cluster we call the remote kibana (simply using node-fetch) and query the endpoint added in #216178; this way the main cluster can have the status of the synced integrations on the remote cluster.

Testing

Note that dev_docs now have a guide to setup locally the remote clusters: https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/dev_docs/local_setup/remote_clusters_ccr.md

  • Follow the testing steps from this PR
  • Install some integrations on cluster A (main) and wait 5 minutes to get SyncIntegrationsTask running
  • Verify that cluster B (remote) has the same integrations installed. From dev tools, run
GET kbn:/api/fleet/remote_synced_integrations/status
  • Go on dev tools on cluster A and run the new endpoint - remote_id is the id of the remote output configured on cluster A:
GET kbn:/api/fleet/remote_synced_integrations/<remote_id>/remote_status

The response should be the same as above

Screenshot

On Remote cluster (Cluster B):
Screenshot 2025-04-10 at 15 40 46

On main cluster (Cluster A):

Screenshot 2025-04-11 at 11 10 30

Checklist

@criamico criamico added Team:Fleet Team label for Observability Data Collection Fleet team release_note:skip Skip the PR/issue when compiling release notes v9.1.0 backport:skip This PR does not require backporting labels Apr 10, 2025
@criamico criamico marked this pull request as ready for review April 10, 2025 13:57
@criamico criamico requested a review from a team as a code owner April 10, 2025 13:57
@elasticmachine
Copy link
Copy Markdown
Contributor

Pinging @elastic/fleet (Team:Fleet)

…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --include-path /api/saved_objects/_import --include-path /api/saved_objects/_export --update'
authz: {
requiredPrivileges: [
FLEET_API_PRIVILEGES.SETTINGS.READ,
FLEET_API_PRIVILEGES.INTEGRATIONS.READ,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the flyout has to be adapted with the correct minimal privileges:

{
"name": "integration_sync_api_key",
"role_descriptors": {
"integration_writer": {
"cluster": [],
"indices":[],
"applications": [{
"application": "kibana-.kibana",
"privileges": ["feature_fleet.read", "feature_fleetv2.read"],
"resources": ["*"]
}]
}
}
}`}

We should test that the API works correctly with a user role having only minimal privileges

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created a role with very minimal privileges - "dev tools" it's there because I need it for testing purposes
Screenshot 2025-04-11 at 10 58 54

Logged in with an user that has that role and verified that API runs correctly.


export const REMOTE_SYNCED_INTEGRATIONS_API_ROUTES = {
STATUS_PATTERN: `${API_ROOT}/remote_synced_integrations/status`,
INFO_PATTERN: `${API_ROOT}/remote_synced_integrations/{outputId}/remote_status`,
Copy link
Copy Markdown
Member Author

@criamico criamico Apr 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the path to remote_status to clarify that is a different status than the above. We might need to fetch the global status remotely (i.e. without outputId) and in that case we could add another endpoint like this:

api/fleet/remote_synced_integrations/remote_status

…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --include-path /api/saved_objects/_import --include-path /api/saved_objects/_export --update'
Copy link
Copy Markdown
Contributor

@juliaElastic juliaElastic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@criamico
Copy link
Copy Markdown
Member Author

@elasticmachine merge upstream

@criamico
Copy link
Copy Markdown
Member Author

@elasticmachine merge upstream

@criamico
Copy link
Copy Markdown
Member Author

@elasticmachine merge upstream

@criamico
Copy link
Copy Markdown
Member Author

@elasticmachine merge upstream

@jillguyonnet
Copy link
Copy Markdown
Member

Hey @criamico I'm testing this afresh again and I'm seeing the following when running GET kbn:/api/fleet/remote_synced_integrations/status on the remote cluster:

{
  "statusCode": 500,
  "error": "Internal Server Error",
  "message": "Failed output validation: [response body.integrations.0.install_status]: definition for this key is missing"
}

This seems to be fixed by adding the install_status field here and here.


return response.ok({ body: res });
} catch (error) {
throw error;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a naive question: what is the benefit of catching and re-throwing these errors?

More generally, I was a little surprised to see thrown errors in kibana e.g. when the output doesn't exist (as opposed to a regular 404 response).

@juliaElastic
Copy link
Copy Markdown
Contributor

Hey @criamico I'm testing this afresh again and I'm seeing the following when running GET kbn:/api/fleet/remote_synced_integrations/status on the remote cluster:

{
  "statusCode": 500,
  "error": "Internal Server Error",
  "message": "Failed output validation: [response body.integrations.0.install_status]: definition for this key is missing"
}

This seems to be fixed by adding the install_status field here and here.

I think we don't need to return install_status in this API, we can just replace ... with expanding the needed fields here:

@criamico
Copy link
Copy Markdown
Member Author

@elasticmachine merge upstream

@criamico
Copy link
Copy Markdown
Member Author

@elasticmachine merge upstream

@criamico criamico enabled auto-merge (squash) April 15, 2025 08:57
@criamico criamico merged commit 89d6dab into elastic:main Apr 15, 2025
9 checks passed
@jillguyonnet
Copy link
Copy Markdown
Member

jillguyonnet commented Apr 15, 2025

Edit: a little late, sorry. Let me know your thoughts on the below.

Hmm failed queries look different now.

Example 1: incorrect remote Kibana URL

Response to GET kbn:/api/fleet/remote_synced_integrations/<outputId>/remote_status:

Request failed to get to the server (status code: 500)

Kibana logs:

[2025-04-15T11:39:01.405+02:00][INFO ][plugins.fleet] Fetching http://localhost:5701/jills/api/fleet/remote_synced_integrations/status
[2025-04-15T11:39:01.413+02:00][ERROR][plugins.fleet] FetchError: invalid json response body at http://localhost:5701/jills/api/fleet/remote_synced_integrations/status reason: Unexpected token 'N', "Not Found" is not valid JSON
[2025-04-15T11:39:01.413+02:00][ERROR][plugins.fleet] FetchError: invalid json response body at http://localhost:5701/jills/api/fleet/remote_synced_integrations/status reason: Unexpected token 'N', "Not Found" is not valid JSON
... (long stack trace)

Example 2: incorrect output id

Response to GET kbn:/api/fleet/remote_synced_integrations/foo/remote_status:

Request failed to get to the server (status code: 404)

Kibana logs:

[2025-04-15T11:45:37.939+02:00][ERROR][plugins.fleet] Error: Saved object [ingest-outputs/b84ed8ed-a7b1-502f-83f6-90132e68adef] not found

It looks like the added condition didn't work as expected? I don't want to block this PR, so I would say the previous version is more helpful. We shouldn't risk throwing 500s if the setup is incorrect.

@elasticmachine
Copy link
Copy Markdown
Contributor

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Fleet Cypress Tests #1 / View agents list Agent status filter should filter on healthy and unhealthy
  • [job] [logs] Fleet Cypress Tests #1 / View agents list Bulk actions should allow to bulk upgrade agents and cancel that upgrade

Metrics [docs]

✅ unchanged

History

cc @criamico

@criamico
Copy link
Copy Markdown
Member Author

@jillguyonnet the PR got merged, at this point this can be addressed in the next piece of work (probably the UI work at this point)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport:skip This PR does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Fleet Team label for Observability Data Collection Fleet team v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants