mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-11-04 09:34:05 +00:00
rcourtman
9fc72c42f8
Second slice toward per-sensor alerts (#3565): the backend half. Stacked on #3658, whose commit it contains; the diff to review is the top commit. ## What changes - A native temperature sensor raises an alert only when its own override sets a threshold: `Overrides["agent:<host>/sensor:<hex>"].Temperature`, where `<hex>` is the lower-case hex of the sensor ID's UTF-8 bytes, so IDs that differ only by case stay apart after host child IDs and metric names are lower-cased. - No default, and nothing is inherited from the host's, a linked node's or a guest's CPU temperature threshold. Fans raise nothing. - Evaluation uses the canonical metric path: metric `temperature`, resource type `agent-sensor` (added as a spec bridge type). Delays, critical escalation, quiet hours and notifications behave as for other temperatures, and `agent-sensor` delay/intent rules apply on top of the agent ones. The message names the sensor ("TB0T temperature at 47.0°C"). ## Hold versus resolve There is no completeness state in the report yet, so absence isn't evidence of removal: - **Hold** (interrupt timing, keep a firing alert): invalid reading, no value, configured sensor missing from the report, empty inventory, telemetry expiry. The existing 24-hour stale sweep still resolves an alert with no observation. - **Resolve**: override removed, disabled or zeroed; host or all-agents alerting off; host removed; confirmed offline. - **Config save**: re-judges a firing sensor alert by its own threshold, and drops pending runs whose policy the save switched off (threshold, host Disabled including inherited links, all agents, global), using the host link identity recorded with the run. `ClearActiveAlerts` and the stale-map sweep drop that identity too. - Alert history joins the machine (`historySubResourceOwner` gains `sensor`). Patrol's alert review never auto-resolves these alerts, because its snapshot carries no sensor reading. ## Known limits, recorded in the alerts contract - Operator intent (maintenance, mute) still resolves under the child ID, the same as every existing host child alert. - Overrides are keyed by the reporting host ID and aren't migrated when a host's identity is healed to a new ID. - As for every host metric, a report in flight during a save can act on the old policy until the next report. ## Not in this PR No UI writes these overrides yet. The Alerts → Thresholds section, mock inventory and browser pass are the next PR. The UI save path sends the raw override map, so overrides set through the API survive saves from the current UI. ## Testing - `operational_contract_test.go`: collision-free IDs (case, punctuation, non-ASCII), exclusive override resolution, the full gap × policy matrix (35 cases), config-save hold, pending-grace reset for five policy-off paths including `ClearActiveAlerts`, sensor delay policy. Spec validation, history ownership and the Patrol guard each have a test. - Negative controls: removing each fix (pending re-check, save resolver, Patrol guard, gap hold, removal clear, host-policy re-check, classification, clear guard) makes its test fail. - Full `internal/alerts/...`, `internal/ai/...` and `internal/unifiedresources` pass. Refs #3565
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.
The local guides below are shipped with this installation. Links labelled GitHub or online open online resources in a new tab and need network access; their current content can differ from your installed version.
Need help with a failure? Read the safe reporting guidance before sharing evidence. A second reproduction or diagnostics export is not required; keep the original evidence if another attempt could interrupt workloads or send duplicate notifications. GitHub reports and attachments are public: review them locally and keep credentials and private details out.
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
- Live demo (online) — generated sample data, not a real deployment.
Pulse Intelligence
- Assistant, Patrol, and external-agent overview
- Patrol modes and safety
- Assistant safety model
- External agent HTTP and MCP substrate
- Walkthrough: what happened overnight on my Proxmox and Docker fleet?
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 (self-serve evaluation and purchase)
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
- REST API
- Architecture
- Contributing
- Published release notes (GitHub)
- Development transparency disclosure
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.