feat(monitoring): the Monitoring shell with its Overview page - #6614
Merged
Conversation
…RolesAllowed The JVM monitoring, logs, messaging-monitoring and BPM process endpoints all declare @RolesAllowed({ADMINISTRATOR, DEVELOPER, OPERATOR}), but they live under /services/ide/** and /services/bpm/**, which the URL layer gates on DEVELOPER alone - so an OPERATOR was rejected by the filter chain before method security ever ran. Add a monitoring gate covering exactly those prefixes, matched before the DEVELOPER gate; everything else under them (workspaces, git, publisher, the BPMN modeler, the LSP/debug sockets) stays DEVELOPER-only. The role gates are now one ordered declaration read by both configure() and the test that guards the matrix, so the ordering the alignment depends on cannot be changed silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"What is deployed and did it synchronize" had no Java REST endpoint - the IDE's Artefacts view reads it through a JS aggregator that fans out over an extension point issuing per-table SQL, which nothing outside that perspective can build on. GET /services/core/artefacts (ADMINISTRATOR/DEVELOPER/OPERATOR) aggregates the ArtefactService beans instead: every synchronizer already registers one, so the injected bean list is the complete inventory and a new artefact type needs no registration step. An artefact type that cannot be read is logged and skipped rather than taking down the inventory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A standalone Harmonia shell at /services/web/monitoring/ that answers the most basic operational question - "is the system healthy, and if not, what broke?" - without opening the IDE. Today that answer is spread across four IDE perspectives sitting last in the rail, behind a Workbench tile the Home launchpad deliberately demotes, and health/readiness have no screen at all. This first phase is the shell skeleton plus the Overview page: KPI tiles for health, readiness, artefacts in error, failed jobs, process incidents, database pool pressure and broker backlog, each backed by an existing platform endpoint, with the individual failures named in the lists below them. It auto-refreshes every 30 seconds (pausable) - there is no server-side history, every poll is a fresh snapshot. The shell is a view layer, not a re-implementation: it reuses the shared Harmonia runtime from application-core, adds no backend, and links to the Workbench for the deep and destructive tooling (SQL console, terminal, message purging, log levels), which stays there permanently. Registered on platform-shells (order 37) and offered on Home as a secondary destination - an operations tool, not where the working day starts. Gated to ADMINISTRATOR / OPERATOR / DEVELOPER, matching the endpoints it reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Master gained the Builder shell (#6610), which registers itself on the Home launchpad exactly where this branch registers Monitoring - so both sides added an entry to the same two constants in home.js. Resolved additively, keeping both shells. SECONDARY stays ordered least-technical-first per its own comment: the two operations tools (Admin, Monitoring) then the two building tools (Builder, Workbench). The Maven wiring in components/pom.xml and group-ui merged cleanly and was verified to carry both modules.
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
1 participant
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.
Phase 1 of the Monitoring shell plan. Stacked on #6613 (the Phase-0 backend) — it targets that branch, so review it after #6613 and it will retarget
masteron merge.What this is
A standalone Harmonia shell at
/services/web/monitoring/that answers "is the system healthy, and if not, what broke?" without opening the IDE. Today that answer spans four IDE perspectives sitting last in the rail (Jobs 450, Operations 900, Tracing 1000, Messaging 1010, Monitoring 1100), behind the Workbench tile the Home launchpad deliberately demotes — and health/readiness have no screen anywhere.components/resources/resources-monitoringfollows theresources-my/resources-adminpattern: a pure-resources module over the shared runtime at/services/web/application-core/shell/(fetch client, theme, branding, i18n, user). No new backend, no copied runtime files.The Overview page
KPI tiles, each backed by an existing platform endpoint, with the individual failures named in the lists below them:
GET /services/core/healthcheckGET /services/core/readinessGET /services/core/artefacts(#6613)GET /services/jobsGET /services/bpm/bpm-processes/instances+…/instance/{id}/jobsGET /services/ide/monitoring/countsGET /services/ide/messaging-monitoring/summaryAuto-refreshes every 30 s, pausable, with a manual refresh. There is no server-side metric history and v1 does not invent one — every poll is a fresh snapshot. A source that cannot be read (engine not enabled, 403, restart mid-poll) degrades to one marked tile instead of an empty page; the incident scan is capped at 50 active instances and says so rather than silently reporting "no incidents".
Scope discipline
The shell is a view layer. The deep and destructive tooling — SQL console, terminal, message purging, process-variable editing, log-level changes — stays in the Workbench permanently; the sidebar links there instead of cloning it.
Wiring
platform-shells(idmonitoringShell, order 37, iconactivity), a Home launchpad entry placed secondary alongside Administration and Workbench (an operations tool, not where the working day starts),monitoring.accessgating/monitoring/to ADMINISTRATOR / OPERATOR / DEVELOPER, plus the three usual Maven edits (components/pom.xmlmodule + dependencyManagement,group-ui).Verification
mvn -T 1C clean install -P quick-build— green.MonitoringShellIT(Selenide,@Tag("ui")) — green: opens the shell and asserts the sidebar entry, the page subtitle and the tiles that only exist once the store's first poll resolved. That is the only way to catch an aborted Alpine walk, which has no DOM or server-side symptom.platform-shells, and the Overview renders as intended (checked in a real browser).Next
Phase 2 (Processes + Jobs), Phase 3 (Logs + Messaging + System), Phase 4 (i18n + the full
MonitoringShellITjourney) follow as separate PRs.🤖 Generated with Claude Code