mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-11-04 20:02:07 +00:00
docs(web): fix Monitor drift found in docs audit
This commit is contained in:
Manuel Escalante
@@ -165,13 +165,13 @@ export default async function MonitorArchitecturePage({
|
||||
<CopyableCode
|
||||
code={`[Unit]
|
||||
Description=ProxMenux Monitor - Web Dashboard
|
||||
After=network.target
|
||||
After=network.target pve-cluster.service
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
User=root
|
||||
WorkingDirectory=/opt/proxmenux-monitor
|
||||
ExecStart=/opt/proxmenux-monitor/ProxMenux-Monitor.AppImage
|
||||
WorkingDirectory=/usr/local/share/proxmenux
|
||||
ExecStart=/usr/local/share/proxmenux/monitor-app/AppRun
|
||||
Restart=on-failure
|
||||
RestartSec=10
|
||||
Environment="PORT=8008"
|
||||
|
||||
@@ -556,7 +556,8 @@ proxmenux_token_header: "Bearer <your_actual_api_token_here>"`}
|
||||
- name: "ProxMenux Monitor Update"
|
||||
unique_id: proxmenux_monitor_update
|
||||
value_template: >
|
||||
{{ 'update available' if (value_json.stable or value_json.beta) else 'up to date' }}
|
||||
{{ 'update available' if (value_json.update_available.stable or value_json.update_available.beta) else 'up to date' }}
|
||||
json_attributes_path: "$.update_available"
|
||||
json_attributes:
|
||||
- stable
|
||||
- stable_version
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
},
|
||||
"reaching": {
|
||||
"heading": "Reaching the dashboard",
|
||||
"intro": "ProxMenux Monitor binds to <code>0.0.0.0:8008</code>. There are three common ways to reach it:",
|
||||
"intro": "ProxMenux Monitor listens on TCP 8008 on all interfaces (<code>::</code>, IPv4 and IPv6). There are three common ways to reach it:",
|
||||
"outro": "Direct access matches the default systemd unit. Reverse-proxy and Secure Gateway access are described below. Trust for client IPs in <code>X-Forwarded-For</code> requires PROXMENUX_TRUST_PROXY=1 and a proxy you control. The presence of <code>X-Forwarded-Proto</code> or <code>X-Forwarded-Host</code> alone does not enable proxy trust. On ports 80/443 the frontend uses relative <code>/api/*</code> URLs; on any other port it calls port 8008 on the same host name."
|
||||
},
|
||||
"firstLaunch": {
|
||||
@@ -158,7 +158,7 @@
|
||||
"authJsonTitle": "auth.json — what it contains and how it's protected",
|
||||
"authJsonBody": "Everything ProxMenux Monitor needs to authenticate you lives in a single file: <code>/root/.config/proxmenux-monitor/auth.json</code>, mode <code>0600</code>, owner <code>root</code>. The file holds <em>hashes</em> (PBKDF2) and <em>signing material</em> (<code>jwt_secret</code>, <code>totp_secret</code>) — never a plaintext password. Treat it like any other root-only secret: if you back up or replicate the host, encrypt the destination, and never commit it to version control.",
|
||||
"rotateTitle": "Rotating jwt_secret invalidates all existing JWTs",
|
||||
"rotateBody": "If <code>auth.json</code> is regenerated (manual delete, reinstall, restore from a backup with a different secret) the <code>jwt_secret</code> changes and every previously-issued JWT — both interactive sessions and long-lived API tokens — fails verification with \"Invalid or expired token\". The UI flags affected API tokens with an <strong>Invalid — regenerate</strong> badge so the user knows to revoke and re-mint them; Home Assistant / scripts / any external client needs a fresh token after that.",
|
||||
"rotateBody": "If <code>auth.json</code> is regenerated (manual delete, reinstall, restore from a backup with a different secret) the <code>jwt_secret</code> changes and every previously-issued JWT — both interactive sessions and long-lived API tokens — fails verification with \"Invalid or expired token\". The UI marks affected API tokens in red, with a badge telling you to revoke them and generate new ones; Home Assistant / scripts / any external client needs a fresh token after that.",
|
||||
"recoverTitle": "Recovering a lost password",
|
||||
"recoverIntro": "There is no online \"forgot password\" flow — by design, since the dashboard runs on the user's own host and the recovery path is shell access to that host. ProxMenux ships a guided reset inside the configuration menu so you don't have to hand-edit <code>auth.json</code>:",
|
||||
"survivesTitle": "What survives the reset",
|
||||
@@ -288,10 +288,10 @@
|
||||
"generateTitle": "Generate a token",
|
||||
"generateIntro": "From the dashboard:",
|
||||
"generateSteps": [
|
||||
"Navigate to <strong>the Security tab → API Access Tokens</strong> section.",
|
||||
"Navigate to <strong>the Security tab → API Tokens</strong> section.",
|
||||
"Type a descriptive name (<em>e.g. \"Home Assistant\"</em>).",
|
||||
"Re-enter your password. If 2FA is on, also the current 6-digit code.",
|
||||
"Click <strong>Generate Token</strong>. The token appears <strong>once</strong> — copy it immediately."
|
||||
"Click <strong>Generate new token</strong>, then <strong>Generate token</strong>. The token appears <strong>once</strong> — copy it immediately."
|
||||
],
|
||||
"generateCli": "From the command line:",
|
||||
"useTitle": "Use a token",
|
||||
|
||||
@@ -118,7 +118,7 @@
|
||||
"imageCaption": "The in-app modal — six cards, one per provider, with the same descriptions documented below.",
|
||||
"groq": {
|
||||
"heading": "Groq",
|
||||
"tagline": "Very fast, generous free tier (30 req/min). Ideal to start.",
|
||||
"tagline": "Very fast, with a generous free tier. A good place to start.",
|
||||
"items": [
|
||||
"API key: <a>console.groq.com/keys</a>",
|
||||
"Examples from the bundled model list: <code>allam-2-7b</code>, <code>qwen/qwen3.8-27b</code>, <code>openai/gpt-oss-20b</code>, <code>openai/gpt-oss-120b</code>.",
|
||||
@@ -165,7 +165,7 @@
|
||||
},
|
||||
"ollama": {
|
||||
"heading": "Ollama (Local)",
|
||||
"tagline": "Uses models exposed by your configured Ollama server. Local models execute there; Ollama cloud models forward requests to a cloud provider. Local execution avoids a hosted API charge but still uses your hardware and electricity.",
|
||||
"tagline": "Uses models on your Ollama server. Fully local, private and free to run.",
|
||||
"items": [
|
||||
"No API key. Set the <em>Ollama URL</em> field to your server (default <code>http://localhost:11434</code> or whatever host runs your Ollama instance).",
|
||||
"Models: <strong>not filtered.</strong> The Monitor reads whichever models you have pulled on the Ollama side via <code>ollama pull <model></code>. The dropdown is populated from <code>GET /api/tags</code> on your Ollama server.",
|
||||
@@ -234,7 +234,7 @@
|
||||
},
|
||||
"detailLevel": {
|
||||
"heading": "Detail level per channel",
|
||||
"intro": "Each of the four channels (Telegram, Discord, Gotify, Email) has its own detail-level dropdown. Three values are available, mapped to specific output token caps and to specific instructions in the default prompt:",
|
||||
"intro": "Each of the six channels (Telegram, Discord, Gotify, Email, Pushover, Apprise) has its own detail-level dropdown. Three values are available, mapped to specific output token caps and to specific instructions in the default prompt:",
|
||||
"headerLevel": "Level",
|
||||
"headerLabel": "UI label",
|
||||
"headerCap": "Output cap",
|
||||
@@ -261,7 +261,7 @@
|
||||
],
|
||||
"defaultsIntro": "Defaults the Monitor applies on first install:",
|
||||
"defaults": [
|
||||
"<strong>Telegram, Discord, Gotify</strong> — <code>standard</code>.",
|
||||
"<strong>Telegram, Discord, Gotify, Pushover, Apprise</strong> — <code>standard</code>.",
|
||||
"<strong>Email</strong> — <code>detailed</code>. Email is the channel where you typically want the full picture for archival."
|
||||
],
|
||||
"emailTitle": "Email detail level appends the original",
|
||||
|
||||
@@ -76,7 +76,7 @@
|
||||
{
|
||||
"endpoint": "/api/system-info",
|
||||
"method": "GET",
|
||||
"use": "Extended system snapshot used by the dashboard header (overall metrics + boot time)."
|
||||
"use": "Lightweight header info: hostname, uptime and cached health status. Public, no token needed."
|
||||
},
|
||||
{
|
||||
"endpoint": "/api/hardware",
|
||||
@@ -401,7 +401,7 @@
|
||||
{
|
||||
"endpoint": "/api/logs",
|
||||
"method": "GET",
|
||||
"use": "Filtered journal entries. Query: <code>?level=&service=&limit=</code>."
|
||||
"use": "Filtered journal entries. Query: <code>?priority=&service=&limit=&since_days=</code> (<code>priority</code> 0-7, <code>since_days</code> up to 90)."
|
||||
},
|
||||
{
|
||||
"endpoint": "/api/logs/download",
|
||||
@@ -411,7 +411,7 @@
|
||||
{
|
||||
"endpoint": "/api/events",
|
||||
"method": "GET",
|
||||
"use": "Internal event stream — the same one that feeds notifications."
|
||||
"use": "Recent Proxmox cluster tasks and events from <code>pvesh get /cluster/tasks</code>. Query: <code>?limit=</code> (default 50)."
|
||||
},
|
||||
{
|
||||
"endpoint": "/api/task-log/<upid>",
|
||||
@@ -462,7 +462,7 @@
|
||||
{
|
||||
"endpoint": "/api/notifications/send",
|
||||
"method": "POST",
|
||||
"use": "Emit a custom event. Body: <code>'{'\"event_type\":\"custom\",\"severity\":\"WARNING\",\"title\":\"...\",\"body\":\"...\",\"data\":'{''}''}'</code>."
|
||||
"use": "Emit a custom event. Body: <code>'{'\"event_type\":\"custom\",\"severity\":\"WARNING\",\"title\":\"...\",\"message\":\"...\",\"data\":'{''}''}'</code>."
|
||||
},
|
||||
{
|
||||
"endpoint": "/api/notifications/test-ai",
|
||||
|
||||
@@ -64,7 +64,7 @@
|
||||
"items": [
|
||||
"<strong><code>User=root</code></strong> — the supported service runs with root privileges for host operations such as SMART access, <code>pvesh</code> and ZFS management. Its web-terminal processes inherit those privileges.",
|
||||
"<strong><code>Restart=on-failure</code></strong> with a 10-second back-off — non-zero exits relaunch automatically.",
|
||||
"<strong><code>After=network.target</code></strong> — orders startup after that target; it does not guarantee an assigned IP, DNS or external connectivity."
|
||||
"<strong><code>After=network.target pve-cluster.service</code></strong>: orders startup after the network target and the Proxmox cluster filesystem; it does not guarantee an assigned IP, DNS or external connectivity."
|
||||
],
|
||||
"inspectTitle": "Inspect the live unit"
|
||||
},
|
||||
|
||||
@@ -168,7 +168,7 @@
|
||||
"ups": {
|
||||
"heading": "UPS Status",
|
||||
"subHeading": "(conditional)",
|
||||
"body": "Renders when a NUT (Network UPS Tools) server is configured and reachable. Shows: state (online / on battery / charging / low battery), battery charge percentage, runtime estimate, load percentage, input voltage, model and firmware. The same data feeds the <em>Security & Certificates</em> category of the Health Monitor — a UPS that goes on-battery surfaces immediately."
|
||||
"body": "Renders when a NUT (Network UPS Tools) server is configured and reachable. Shows: state (online / on battery / charging / low battery), battery charge percentage, runtime estimate, load percentage, input voltage, model and firmware."
|
||||
},
|
||||
"dataCollected": {
|
||||
"heading": "How the data is collected",
|
||||
|
||||
@@ -50,7 +50,7 @@
|
||||
},
|
||||
{
|
||||
"name": "Terminal",
|
||||
"owns": "Browser shell to host or to any VM/CT, powered by <code>xterm.js</code> over WebSockets."
|
||||
"owns": "Browser shell on the Proxmox host, powered by <code>xterm.js</code> over WebSockets. LXC consoles open from the VMs & LXCs tab."
|
||||
},
|
||||
{
|
||||
"name": "Security",
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
"heading": "Network Units",
|
||||
"imageAlt": "Network Units card with Network Unit Display dropdown set to Bytes",
|
||||
"imageCaption": "Choose between bits per second and bytes per second for every network rate displayed in the dashboard.",
|
||||
"body": "Choose how network throughput is displayed across the dashboard: <strong>bits per second</strong> (Mbps / Gbps) or <strong>bytes per second</strong> (MB/s / GB/s). Bits is the default because it's what NIC vendors and ISPs label their products with; bytes is what most file-transfer tools report. The setting affects every chart, badge and tooltip that shows network rate — applied immediately, no reload needed."
|
||||
"body": "Choose how network throughput is displayed across the dashboard: <strong>bits per second</strong> (Mbps / Gbps) or <strong>bytes per second</strong> (MB/s / GB/s). Bytes is the default, as most file-transfer tools report; bits is what NIC vendors and ISPs label their products with. The choice is stored in the browser, so each browser keeps its own. The setting affects every chart, badge and tooltip that shows network rate — applied immediately, no reload needed."
|
||||
},
|
||||
"health": {
|
||||
"heading": "Health Monitor",
|
||||
@@ -203,7 +203,7 @@
|
||||
"heading": "LXC Update Detection",
|
||||
"imageAlt": "LXC Update Detection card with a single switch — when enabled, the Monitor periodically scans running Debian/Ubuntu/Alpine LXC containers for pending package updates.",
|
||||
"imageCaption": "The toggle for the periodic <code>apt list --upgradable</code> / <code>apk list -u</code> scan across every running CT. Default is ON. The matching notification toggle in Notifications → Services only appears while detection is enabled.",
|
||||
"intro": "A dedicated toggle for the LXC update scan, sitting between the Health Monitor Thresholds and the Notifications card. When ON, ProxMenux walks every running CT on the host and queries the in-container package manager for pending updates; results land in the Hardware tab badge counts and feed the <code>lxc_updates_available</code> notification. When OFF, the scan stops entirely (no <code>pct exec</code> calls) and any existing LXC entries in <code>managed_installs.json</code> are purged immediately, so the dashboard and the <code>/api/managed-installs</code> endpoint stop reporting LXC update state without waiting for the next 24h cycle.",
|
||||
"intro": "A dedicated toggle for the LXC update scan, sitting between the Health Monitor Thresholds and the Notifications card. When ON, ProxMenux walks every running CT on the host and queries the in-container package manager for pending updates; results land in the VMs & LXCs tab badge counts and feed the <code>lxc_updates_available</code> notification. When OFF, the scan stops entirely (no <code>pct exec</code> calls) and any existing LXC entries in <code>managed_installs.json</code> are purged immediately, so the dashboard and the <code>/api/managed-installs</code> endpoint stop reporting LXC update state without waiting for the next 24h cycle.",
|
||||
"whatRunsTitle": "What the scan actually runs",
|
||||
"whatRunsIntro": "For each CT in <code>running</code> state with a supported package manager:",
|
||||
"whatRunsItems": [
|
||||
@@ -249,7 +249,7 @@
|
||||
"body1": "This section of the Settings tab is where ProxMenux Monitor notifications and the AI rewriter are turned on. Pressing <em>Enable Notifications</em> starts the dispatch background thread, registers a Proxmox VE webhook target on the host so PVE-emitted events flow into the same pipeline, and unfolds the channel form so you can connect Telegram, Discord, Email, Gotify and the rest. The AI rewriter sits inside the same panel as a collapsible advanced section.",
|
||||
"body2": "Both surfaces have a lot of moving parts — channels, per-event toggles, Rich messages, the Display Name, the dispatch pipeline (dedup, cooldown, aggregation, quiet hours), the PVE webhook integration, AI providers, prompt modes — and live on their own dedicated pages rather than being repeated here:",
|
||||
"items": [
|
||||
"<notifLink>Notifications</notifLink> — channel walk-throughs (Telegram, Discord, Gotify, Email + Gmail / Microsoft app passwords, ntfy, Slack, Teams, generic webhook), per-event categories, Rich messages, Display Name, dispatch pipeline, PVE webhook integration, history and API.",
|
||||
"<notifLink>Notifications</notifLink> — channel walk-throughs (Telegram, Discord, Gotify, Email + Gmail / Microsoft app passwords, Pushover, and Apprise for ntfy, Slack, Teams and other services), per-event categories, Rich messages, Display Name, dispatch pipeline, PVE webhook integration, history and API.",
|
||||
"<aiLink>AI Assistant</aiLink> — providers (OpenAI, Anthropic, Gemini, Groq, OpenRouter, Ollama), model selection, prompt modes (default / custom), output language, per-channel detail levels and AI suggestions."
|
||||
]
|
||||
},
|
||||
@@ -294,8 +294,8 @@
|
||||
},
|
||||
{
|
||||
"card": "Network Units",
|
||||
"endpoint": "/api/settings",
|
||||
"source": "Persisted in the dashboard's SQLite settings table."
|
||||
"endpoint": "localStorage",
|
||||
"source": "Browser preference <code>proxmenux-network-unit</code>."
|
||||
},
|
||||
{
|
||||
"card": "Health Monitor durations",
|
||||
|
||||
@@ -10,7 +10,7 @@
|
||||
},
|
||||
"intro": {
|
||||
"title": "Backed by three sources",
|
||||
"body": "Proxmox storages come from <code>pvesm status</code>; ZFS state from <code>zpool status</code>; physical disks from <code>lsblk</code> + <code>smartctl</code> (and <code>nvme</code> for NVMe-specific fields). The tab refreshes every ~60 seconds; the per-disk drill-in triggers a fresh SMART read on demand."
|
||||
"body": "Proxmox storages come from <code>pvesm status</code>; ZFS state from <code>zpool status</code>; physical disks from <code>lsblk</code> + <code>smartctl</code> (and <code>nvme</code> for NVMe-specific fields). The tab refreshes every ~30 seconds; the per-disk drill-in triggers a fresh SMART read on demand."
|
||||
},
|
||||
"thresholds": {
|
||||
"title": "Status colours and thresholds applied here",
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
"<strong>Total Entries</strong> — number of log records inside the active filter window.",
|
||||
"<strong>Errors</strong> — count of severity ≤ 3 (<code>err</code> / <code>crit</code> / <code>alert</code> / <code>emerg</code>).",
|
||||
"<strong>Warnings</strong> — count of severity 4 (<code>warning</code>).",
|
||||
"<strong>Backups</strong> — count of vzdump / PBS task entries in the same window."
|
||||
"<strong>Backups</strong>: number of backup archives on the configured backup storages."
|
||||
]
|
||||
},
|
||||
"subtabs": {
|
||||
@@ -26,10 +26,10 @@
|
||||
"logsTitle": "Logs",
|
||||
"logsIntro": "The system journal, served by <code>journalctl</code> on the backend. Filters available in the toolbar:",
|
||||
"logsFilters": [
|
||||
"<strong>Severity</strong> — emerg / alert / crit / err / warning / notice / info / debug, or any combination.",
|
||||
"<strong>Time range</strong> — last 5 min / 15 min / 1 h / 6 h / 24 h / 7 d / custom.",
|
||||
"<strong>Free-text search</strong> — substring or regex (<code>journalctl --grep</code>).",
|
||||
"<strong>Unit filter</strong> — restrict to a specific systemd unit (<code>pveproxy.service</code>, <code>nginx.service</code>, …)."
|
||||
"<strong>Level</strong>: all, error, warning or info.",
|
||||
"<strong>Time range</strong>: 1 day / 3 days / 1 week / 2 weeks / 1 month, or a custom number of days (up to 90).",
|
||||
"<strong>Free-text search</strong>: case-insensitive substring over message, service, PID, hostname and unit, applied in the browser.",
|
||||
"<strong>Service filter</strong>: restrict to one service (the journal <code>SYSLOG_IDENTIFIER</code>)."
|
||||
],
|
||||
"logsRowsAfter": "Each row shows timestamp, severity badge, source unit and the message. Long messages collapse with a \"show more\" toggle. The <strong>Download</strong> action bundles the current filter into a single <code>.txt</code> file via <code>GET /api/logs/download</code> — useful when you want to share a slice of journal with someone.",
|
||||
"logDetailsModalTitle": "Log Details modal",
|
||||
@@ -50,10 +50,10 @@
|
||||
"maxLevelStoreTitle": "Journald MaxLevelStore",
|
||||
"maxLevelStoreBody": "On a fresh Proxmox install, journald defaults to <code>MaxLevelStore=warning</code>, which silently drops info-level messages. The Monitor detects this on startup and adds a drop-in (<code>/etc/systemd/journald.conf.d/proxmenux-loglevel.conf</code>) raising the threshold to <code>info</code> so informational and more severe messages are stored. This does not include debug messages.",
|
||||
"backupsTitle": "Backups",
|
||||
"backupsBody": "Proxmox task history filtered to backup-related entries. One row per task (<code>vzdump</code>, PBS transfers, Garbage Collect, Verify) with the status (OK / WARNINGS / ERROR), guest involved, source storage, duration and the UPID. Click a row to load the full task log via <code>GET /api/task-log/<upid></code> — the same data Proxmox exposes through <em>Datacenter → Tasks</em>, scoped to backups.",
|
||||
"backupsBody": "The backup archives on every backup-capable storage (dir, NFS, CIFS, PBS), read with <code>pvesh get /nodes/localhost/storage/<id>/content</code>. Cards at the top show the VM and LXC counts and the total size; below, one row per archive with type, storage, size and date. Restore lives in the Proxmox web UI.",
|
||||
"notificationsTitle": "Notifications",
|
||||
"notificationsBody1": "Every notification dispatched by the Monitor — Telegram, Discord, Email, Gotify, ntfy, Slack, Teams, webhook. Each row: timestamp, channel, event type, severity, the rendered title, the rendered body, and (if AI is enabled) a toggle to view the AI rewrite next to the original.",
|
||||
"notificationsBody2": "Use this tab to verify a channel is actually delivering and to compare what the AI rewrite produced vs the template baseline. Channel configuration lives in the <link>Notifications</link> deep page."
|
||||
"notificationsBody1": "Proxmox notification activity: journal lines from Proxmox services that mention notifications, email, webhooks or alerts, the targets in /etc/pve/notifications.cfg, and backup tasks from the cluster task list. Backup task rows can download the full task log. The history of what the Monitor itself dispatched lives in Settings → Notifications → Notification history.",
|
||||
"notificationsBody2": "Use this tab to check what Proxmox's own notification system is doing. Monitor channel configuration lives in the <link>Notifications</link> deep page."
|
||||
},
|
||||
"dataCollected": {
|
||||
"heading": "How the data is collected",
|
||||
@@ -64,7 +64,7 @@
|
||||
{
|
||||
"subtab": "Logs (live filter)",
|
||||
"endpoint": "/api/logs",
|
||||
"source": "<code>journalctl --output json --since <range></code> with severity / unit / search filters applied server-side."
|
||||
"source": "<code>journalctl</code> with priority, service and day-range filters applied server-side; text search runs in the browser."
|
||||
},
|
||||
{
|
||||
"subtab": "Download",
|
||||
@@ -74,17 +74,17 @@
|
||||
{
|
||||
"subtab": "Backups",
|
||||
"endpoint": "/api/backups",
|
||||
"source": "PVE task history filtered by <code>vzdump</code>, PBS transfers, Garbage Collect, Verify."
|
||||
"source": "Backup archives listed from each backup storage with <code>pvesh get /nodes/localhost/storage/<id>/content</code>."
|
||||
},
|
||||
{
|
||||
"subtab": "Backup task drill-in",
|
||||
"subtab": "Backup task log (Notifications)",
|
||||
"endpoint": "/api/task-log/<upid>",
|
||||
"source": "Plain-text full task log read from <code>/var/log/pve/tasks/<index>/<upid></code>."
|
||||
},
|
||||
{
|
||||
"subtab": "Notifications history",
|
||||
"endpoint": "/api/notifications/history",
|
||||
"source": "SQLite <code>notification_history</code> table fed by the dispatch loop."
|
||||
"subtab": "Notifications",
|
||||
"endpoint": "/api/notifications",
|
||||
"source": "<code>journalctl --grep</code> over Proxmox units, <code>/etc/pve/notifications.cfg</code> and backup tasks from <code>pvesh get /cluster/tasks</code>."
|
||||
}
|
||||
],
|
||||
"apiIntro": "Both the live filter and the downloads are also reachable via the API:",
|
||||
|
||||
@@ -46,7 +46,7 @@
|
||||
"thresholdsIntro": "Every ring, bar, and sparkline on the four metric cards follows the same classification — <green/> <strong>green</strong> below Warning, <amber/> <strong>amber</strong> from Warning to Critical, <red/> <strong>red</strong> at Critical and above. Recommended defaults shipped with ProxMenux:",
|
||||
"thresholdsItems": [
|
||||
"<strong>CPU usage</strong> — Warning 85 %, Critical 95 %.",
|
||||
"<strong>Memory</strong> — Warning 85 %, Critical 95 % (Swap also fires Critical at 5 % used — a healthy Proxmox host should rarely touch swap).",
|
||||
"<strong>Memory</strong>: Warning 85 %, Critical 95 %. Swap fires Critical only when swap use is above 80 % and available RAM is below 15 %.",
|
||||
"<strong>CPU temperature</strong> — Warning 80 °C, Critical 90 °C."
|
||||
],
|
||||
"thresholdsOutro": "Every value is configurable per host — <link>Settings → Health Monitor Thresholds</link> is the single source of truth and explains how to tune them.",
|
||||
@@ -58,7 +58,7 @@
|
||||
"intro": "The CPU Usage and Memory cards on the Overview tab are clickable. Clicking either opens a sortable list of the top 25 processes — ordered by CPU usage when opened from the CPU card, by resident memory when opened from the Memory card.",
|
||||
"listTitle": "The list dialog",
|
||||
"listItems": [
|
||||
"<strong>Auto-refresh</strong> — the list updates every 5 seconds while the dialog is open and stops polling as soon as it closes.",
|
||||
"<strong>Auto-refresh</strong> — the list updates every 3 seconds while the dialog is open and stops polling as soon as it closes.",
|
||||
"<strong>Filter</strong> — the search box narrows the list by command, user or PID.",
|
||||
"<strong>Inline bar</strong> — the primary metric column draws a small bar scaled to the highest value in the filtered list, so ranking stays visible even when no process is near 100 %.",
|
||||
"<strong>Mobile layout</strong> — under 640 px the PID and User columns hide so Command, CPU % and Memory still fit on a phone screen without horizontal scroll."
|
||||
@@ -79,7 +79,7 @@
|
||||
},
|
||||
"middle": {
|
||||
"heading": "Middle: node metrics charts",
|
||||
"body1": "Below the top row sits the <code>NodeMetricsCharts</code> component — historical CPU, memory and disk-I/O graphs sourced from Proxmox's own RRD store via <code>/api/node/metrics</code>. A timeframe selector switches between <em>1 hour / 24 hours / 7 days / 30 days / 1 year</em>; data resolution drops as the window grows so the chart stays smooth.",
|
||||
"body1": "Below the top row sits the <code>NodeMetricsCharts</code> component — historical CPU, memory and disk-I/O graphs sourced from Proxmox's own RRD store via <code>/api/node/metrics</code>. A timeframe selector switches between <em>1 hour / 24 hours / 7 days / 30 days</em>; data resolution drops as the window grows so the chart stays smooth.",
|
||||
"body2": "These are the same graphs that the Proxmox web UI renders for a node, just consolidated into the Monitor's dark theme and aligned with the other panels."
|
||||
},
|
||||
"bottom": {
|
||||
|
||||
@@ -117,7 +117,7 @@
|
||||
"<strong>Destination tag</strong> — the storage where it lives (PBS-Cloud, PBS-Local, NFS-Backup, …) coloured by status.",
|
||||
"<strong>Size</strong> — final on-disk size of the backup."
|
||||
],
|
||||
"backupsOutro": "The <strong>+ Create Backup</strong> button at the top right kicks off a new run on the storage marked as \"Backup target\" in the Proxmox storage config. Restore lives in the Proxmox web UI — the Monitor exposes the \"is this guest backed up recently?\" view, not the recovery flow.",
|
||||
"backupsOutro": "The <strong>+ Create Backup</strong> button at the top right opens a dialog to choose the storage, mode (snapshot / suspend / stop), protection and notes before starting a vzdump. Restore lives in the Proxmox web UI — the Monitor exposes the \"is this guest backed up recently?\" view, not the recovery flow.",
|
||||
"firewallTitle": "Tab 7 — Firewall",
|
||||
"firewallIntro": "Reads the per-guest Proxmox firewall log straight from the host (no extra service, no polling). The tab is always present in the navigation strip; the panel decides what to render depending on whether the firewall is enabled for that guest and whether any rule is actually logging:",
|
||||
"firewallItems": [
|
||||
|
||||
@@ -153,8 +153,8 @@
|
||||
"pillTitle": "The pill mirrors the worst category",
|
||||
"pillBody": "The dashboard header colour is the highest severity across the ten categories: any CRITICAL → red, else any WARNING → yellow, else any INFO → blue, else green. The same logic drives the favicon dot and the PWA badge.",
|
||||
"updateNowTitle": "Update Now button in the Overview header",
|
||||
"updateNowBody1": "When the <em>System Updates</em> category reports one or more pending updates, the Overview header renders an <strong>Update Now</strong> button next to the health pill. The button opens a modal that runs the same host-side flow as <em>ProxMenux → Settings post-install Proxmox → Proxmox System Update</em>: repo hygiene, <code>apt full-upgrade</code> via the safe worker <code>update-pve-safe.sh</code>, automatic DKMS rebuild of ProxMenux-managed drivers when a new kernel lands, autoremove / autoclean and a reboot prompt if the kernel changed. Progress lines stream in the modal as the worker prints them.",
|
||||
"updateNowBody2": "When the run finishes, closing the modal calls <code>GET /api/health/details?refresh=1</code>, which invalidates the health-endpoint cache before serving. The pending-updates row and the pill severity are recomputed from the new package state on the spot, so the badge disappears without waiting for the next five-minute cycle. When the host is already up to date, the button is hidden — no visual noise on a healthy system."
|
||||
"updateNowBody1": "When the <em>System Updates</em> category reports one or more pending updates, the Overview header renders an <strong>Update Now</strong> button next to the health pill. The button opens a modal that runs the same host-side flow as <em>ProxMenux → Utilities and Tools → Proxmox System Update</em>: repo hygiene, <code>apt full-upgrade</code> via the safe worker <code>update-pve-safe.sh</code>, automatic DKMS rebuild of ProxMenux-managed drivers when a new kernel lands, autoremove / autoclean and a reboot prompt if the kernel changed. Progress lines stream in the modal as the worker prints them.",
|
||||
"updateNowBody2": "When the run finishes, closing the modal calls <code>GET /api/health/full?refresh=1</code>, which invalidates the health-endpoint cache before serving. The pending-updates row and the pill severity are recomputed from the new package state on the spot, so the badge disappears without waiting for the next five-minute cycle. When the host is already up to date, the button is hidden — no visual noise on a healthy system."
|
||||
},
|
||||
"dismiss": {
|
||||
"heading": "Dismissing alerts and the Suppression Duration",
|
||||
|
||||
@@ -119,7 +119,7 @@
|
||||
},
|
||||
"serviceControl": {
|
||||
"heading": "Service control",
|
||||
"intro": "Day-to-day, the Monitor is managed exactly like any other systemd service. It is also exposed as two entries inside the ProxMenux TUI under <em>Settings</em>:",
|
||||
"intro": "Day-to-day, the Monitor is managed exactly like any other systemd service. It is also exposed as three entries inside the ProxMenux TUI under <em>Settings</em>:",
|
||||
"codeComment": "# Manual control",
|
||||
"footer": "See <link>Settings → ProxMenux Monitor</link> for the in-menu toggle and status verification flow."
|
||||
},
|
||||
|
||||
Reference in New Issue
Block a user