[9.4] [Synthetics] Fix monitor health API for monitors in non-default spaces (#270540)#270605
Open
shahzad31 wants to merge 3 commits into
Open
[9.4] [Synthetics] Fix monitor health API for monitors in non-default spaces (#270540)#270605shahzad31 wants to merge 3 commits into
shahzad31 wants to merge 3 commits into
Conversation
elastic#270540) When using Kibana Spaces, the Synthetics monitor health endpoint could incorrectly report monitors as unhealthy — showing errors such as "missing location", "missing agent policy", or "missing package policy" — even when everything was properly configured. This happened because the health check was only looking for monitors, private locations, and Fleet policies in the current space, missing resources that existed in other spaces. These issues are now fixed: the health check correctly resolves monitors, private locations, package policies, and agent policies across all relevant spaces, giving an accurate health status regardless of how resources are distributed across your Kibana Spaces. Closes elastic#270477. `POST /internal/synthetics/monitors/_health` returned wrong results when monitors lived outside the request's space — `missing_package_policy` errors when called from the monitor's space, and 404s when called from `default`. Two independent space-scoping bugs: 1. **Package policy lookup ignored space.** `getExistingPackagePoliciesMap` called Fleet's `packagePolicyService.getByIDs` with `createInternalRepository()`, which is scoped to the default namespace. Package policies created for monitors in another space were therefore invisible. 2. **Monitor saved-object lookup was space-scoped.** `MonitorConfigRepository.get` used the request-scoped saved-objects client, restricted to the request's space. Calling `_health` from `default` for a monitor that lives elsewhere returned a 404. - **`PackagePolicyService.getByIds`** — accepts a new optional `additionalSpaceIds`, so the wrapper's per-space scoped-client fan-out can broaden beyond `[spaceId, default]`. Existing callers keep their old behavior. - **`MonitorConfigRepository.getAcrossSpaces(id, namespaces, soClient?)`** — new method that resolves a monitor across an arbitrary list of spaces. Uses the multi-space type's per-object `namespaces` array in one bulkGet entry, plus one entry per namespace for the `namespaceType: 'single'` legacy type. Accepts an injected `soClient` so the health API can pass `createInternalRepository()` and bypass the request's space restriction. - **`MonitorIntegrationHealthApi`**: - Computes `allSpaces = { requestSpace, ...allSpacesWithMonitors }` once, up-front. - `fetchMonitors` calls `monitorConfigRepository.getAcrossSpaces` with the internal repository → fixes bug #2. - `getExistingPackagePoliciesMap` uses the `PackagePolicyService` wrapper with `additionalSpaceIds` → fixes bug #1. - [x] `node scripts/jest` on the three affected suites — **77/77 passing** (includes new cross-space coverage and a new `getAcrossSpaces` test block). - [x] `node scripts/type_check --project x-pack/solutions/observability/plugins/synthetics/tsconfig.json` — clean. - [x] `node scripts/eslint` on the changed files — clean. - [ ] Manual: create a monitor with a private location in a non-default space, then call `POST /internal/synthetics/monitors/_health` both from that space and from `default`. Verify each call reports the monitor accurately instead of `missing_package_policy` / 404. - elastic#270137 — related health API fix (project monitor policy ID + infinite polling). Made with [Cursor](https://cursor.com) --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Miguel Martín <miguel.martin@elastic.co> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 4e2f2e6)
shahzad31
added
backport
github-actions
Bot
added
the
author:actionable-obs
|
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
miguelmartin-elastic
approved these changes
May 25, 2026
PR elastic#270540's monitor_integration_health_api.{ts,test.ts} import getPrivateLocationsForNamespaces, which was added on main by PR elastic#260642 but does not exist on 9.4 yet — causing 5 type errors in CI. Port the symbol verbatim from main: add the multi-namespace export and rewrite getPrivateLocations as a one-line wrapper. The public signature of getPrivateLocations is preserved, so all existing 9.4 callers are unaffected. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
💔 Build Failed
Failed CI StepsTest Failures
Metrics [docs]
History
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport
This is an automatic backport to
9.4of:Conflict resolution
The auto-backport failed because of two-file conflicts in
monitor_integration_health_api.{ts,test.ts}caused by the agent-status feature (#261367) that lives only onmain. Resolved by:getAcrossSpaces,additionalSpaceIds,PackagePolicyServicewrapper, cross-spacegetExistingAgentPoliciesMap/getExistingPackagePoliciesMap).agentStatusMap/getAgentStatusMap/MissingAgents/UnhealthyAgentcode paths and corresponding tests, sincePrivateLocationHealthStatusValue.MissingAgentsandgetAgentStatusForAgentPolicyplumbing do not exist on 9.4.Notes for reviewer
MonitorConfigRepository.getAcrossSpaces,PackagePolicyService.getByIds({ additionalSpaceIds }), and the cross-space agent/package-policy lookups are preserved verbatim from [Synthetics] Fix monitor health API for monitors in non-default spaces #270540.missing agents,unhealthy agent) only covered the agent-status feature that is not present in 9.4.Made with Cursor