mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-23 20:25:56 +00:00
rcourtman
91dbc94b5f
The `pulse-relaxed` Proxmox tag lifts a guest's CPU, memory and disk alert triggers to a 95/92/95 floor (applied in `effectiveAlertPolicyNoLock` since #2705), but the browser coloured bars from the configured thresholds alone. A relaxed guest at 88% memory showed a red bar while the alert engine stayed silent until 92%, and the Alerts thresholds row kept showing 80/85/90 with no sign the tag raised them. That is the gap a user described on #863 (comment of 2026-01-16): the tags override the UI settings "but there's no visible indication in the UI". ## What changes - **Bars follow the tag.** `resolveMetricDisplayThresholds` takes the tags the engine reads for a guest and applies the backend's `applyRelaxedGuestThresholds` step before mapping to display thresholds: unset gets the floor, a lower trigger is raised and keeps its clear point (a missing clear is filled five below, as `ensureHysteresisThreshold` does) unless the raised trigger reaches it, and Off stays Off. A relaxed guest now turns red where its alert fires. - **Only Proxmox guests.** `getWorkloadAlertPolicyTags` and `useThresholdsGuestData` pass tags only for Proxmox VMs and LXCs, the only guests whose tags reach alert policy. vSphere and TrueNAS VMs (also `type: vm`) and containers keep their thresholds whatever they are tagged. - **The thresholds row says what is in effect.** A relaxed guest's Alerts → Thresholds row (table and card) adds one line, "Proxmox tag pulse-relaxed: alerts at CPU 95% · Memory 92% · Disk 95%", listing only the thresholds the tag actually raises. It follows unsaved edits. The cells keep the configured values the editor changes. ## Why the row and not the drawer or table Following the user-lens procedure: the job is "I tagged this noisy VM pulse-relaxed: is Pulse honouring it, and when will it alert?". Before this change the bar answered it wrongly at zero clicks, and the only surface that states thresholds (Alerts → Thresholds → Proxmox → VMs & Containers, then search) stated the wrong numbers. No user doc describes the tag, and GitHub comments give conflicting values (95/95/98 in #323, 95/92/95 in #863), so the row has to state the numbers. A badge in the guest drawer or table row would fail the actionability test: once the bar colour is right, the user has nothing to do there, and the place to act is the thresholds row (or the tag in Proxmox). ## Verification - Private mock stack from this branch with a dev-only overlay tagging two demo profiles `pulse-relaxed` (68 VMs). Before the change: relaxed `ci-runner-117` at 88% memory was red. After: every running relaxed row matches the relaxed band (`analytics-batch-70` at 87% reads warning), while untagged guests at 86–92% stay red, at desktop and 375px. The thresholds row line was checked in the card layout, in the table layout (full-width mode at 2560px), at 375px, and through an unsaved edit (Memory 96 drops it from the line). Receipt: `frontend-modern/browser-verification/1f9dcc1c17da6345.json`. - Proof files: `metricThresholds.test.ts` (relaxed resolution, Off, unset, clear filling at margins 5 and 10, scope gating), `workloadTopology.test.ts` (Proxmox-only tags, legacy tag strings), `ResourceTable.test.tsx` (desktop and mobile line, omitted metrics, edits, disabled and untagged rows). `GuestRow.test.tsx` gets the new export in its topology mock. - On pulse-dev: tsc, `npm run lint` and the Alerts, Workloads, utils, stores, platformPage, shared and `src/__tests__` suites. The broad run's only failures were missing repo-root files from a partial sync and 5s timeouts at load ~65; all 15 affected files pass when rerun with the full tree. ## Known limits (existing, not widened here) - The display resolver does not read filter-driven custom rules, which the engine folds in before the override, so a guest a custom rule matches can colour by thresholds the engine does not use. Custom rules have no UI today. The alerts contract now says so. - The Alerts page's guest list memo compares only id and name, so adding or removing the tag in Proxmox shows on that page after a reload. Workloads rows update live. - The thresholds page reads an unset global default as Off (`getTriggerValue`), so the line omits the floor the engine would give a genuinely unset default. A save from the Alerts page always writes these defaults. - `pulse-no-alerts` and `pulse-monitor-only` still have no indication on the row. They are tracked with the rest of the #863 comment in the demand ledger.
Pulse documentation
Start here for installation, platform setup, security, operations, and Pulse Intelligence. Commands, configuration keys, image names, API fields, and product identifiers remain untranslated in localized guides.
Start here
- Install Pulse — signed Proxmox/Linux installation, Docker, Docker Compose, Kubernetes, and first-run setup.
- Production deployment and security — least-privilege Proxmox setup, root-agent boundaries, discovery, supply-chain verification, plan limits, scale evidence, and a rollout checklist.
- Upgrade from Pulse v5 — migration prerequisites, rollback, agent continuity, and post-upgrade checks.
- Releases and update channels: choosing Stable or Preview, beta and RC expectations, and how releases are tested and promoted.
- Configure Pulse — authentication, notifications, discovery, retention, and system settings.
- Deployment models — data locations, lifecycle, and differences between supported deployment paths.
- Troubleshooting and FAQ — common failures, diagnostics, and operator questions.
Localized getting started guides: Deutsch · Español
Platforms and agents
- Proxmox Backup Server
- Proxmox Mail Gateway
- Docker and Podman
- Kubernetes and Helm
- TrueNAS SCALE and CORE
- Unified Agent
- Agent security
- VM disk monitoring
- ZFS monitoring
- Temperature monitoring
VMware vSphere support is early access. Current builds expose dedicated vSphere inventory and recovery context, but operators should validate the integration against their own vCenter before production use.
Monitoring and operations
- Metrics history
- Recovery data
- Webhooks
- Automatic updates
- Centralized agent management (Pro)
- Operational trust model
- Current product screenshots
Pulse Intelligence
- Assistant, Patrol, and external-agent overview
- Patrol modes and safety
- Assistant safety model
- External agent HTTP and MCP substrate
Patrol watch-only analysis is available on Community with a local model or the operator's own provider. Investigation and governed fixes require the relevant Pulse Pro capabilities.
Security, privacy, and access
- Production deployment and security
- Security review scope
- Authentication and credential storage review packet
- Security guide
- Privacy and telemetry disclosure
- OIDC and SSO
- Proxy authentication
- Role-based access control (Pro)
- Audit logging (Pro)
- Reverse proxy configuration
- Code-signing policy
Plans and managed access
- Community, Relay, and Pro capabilities
- Relay and Pulse Mobile handoff
- Multi-tenant organizations (Enterprise/custom)
- Provider-hosted MSP operations (request-assisted)
Pulse Cloud is not generally available. Ordinary self-hosted Pulse remains the primary installation path; MSP and Enterprise access are explicit commercial paths rather than defaults in self-hosted setup.
Development and reference
Detailed design notes and dated migration specifications may remain in this directory for maintainers, but they are not operator setup guides unless they are linked from the sections above.
Previous versions and migrations
- Upgrade from v4 to v5
- Retired unified-navigation migration — historical context only; current Pulse uses platform-shaped navigation.
- Move a Pulse installation
Found a bug? Use the issue forms. For setup questions, use GitHub Discussions.