Monitor64

Monitor64 monitors systems with thresholds and history: servers, NAS, hypervisors, containers, network devices, UPS and printers. You see CPU, memory, file systems, disks including SMART, network ports, temperatures, updates and services – and get a notification as soon as something crosses a threshold. Made for homelabs up to mid-sized businesses, deliberately lighter than CheckMK or Zabbix.

How it works

• The module is off by default. While it is off nothing runs, no port is open and no tables are created.
• A host is a monitored system. It has one or more access methods (e.g. the Proxmox API plus the agent for bonding and temperatures).
• Every access method delivers services (CPU, file system /, disk sda, VM 100 …). Services are discovered but never adopted automatically.
• Polling happens every minute (per host from 30 seconds to 15 minutes). The node polls – on the hosts at most the small agent runs.
• All data stays local on your node. Monitor64 does not need an ipv64.net account.

Switching it on and the first host

1. Settings → Modules: switch on Monitor64. "Monitor64" appears in the menu.
2. Add host: choose the kind (Linux with agent, Windows, Proxmox VE, NAS, SNMP device …), enter name and address.
3. The wizard shows what to do on the host (install command, token, key). Test connection shows the services it found.
4. Select services, assign group and tags, create host. The first values arrive right away.

Access methods

Credentials (API tokens, passwords, SNMP secrets) are stored encrypted in the node and are never shown again. With self-signed certificates the test shows the fingerprint; credentials are only sent after you confirmed it.

Monitor64 agent

The agent is a single program without dependencies for Linux (amd64, arm64, armv7), Windows (amd64) and FreeBSD (amd64, arm64). It was tested on FreeBSD 14; OPNsense, pfSense and TrueNAS CORE are supported but not yet widely tried – feedback is welcome. The agent only accepts requests from your node (via its key) and can only deliver values – it cannot run commands.

Monitor64 → Agent and the wizard show the ready-made command with your node's key. It looks like this:

curl -fsSL https://ipv64.net/node64/agent/install.sh | sudo sh -s -- \
  --base https://ipv64.net/node64/agent/ \
  --key "ssh-ed25519 AAAA… node64@node"

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12; & ([scriptblock]::Create((irm https://ipv64.net/node64/agent/install.ps1))) -Key "ssh-ed25519 AAAA… node64@node" -Base https://ipv64.net/node64/agent/

fetch -o /tmp/install.sh https://ipv64.net/node64/agent/install.sh && \
  sh /tmp/install.sh --base https://ipv64.net/node64/agent/ --key "ssh-ed25519 AAAA… node64@node"

• Source of the files: "Internet" (ipv64.net) or "this node" – the node keeps the signed files ready, also for hosts without internet access.
• Fingerprint: the install script shows the host's fingerprint. "Test connection" shows the same value; after that the node remembers the key.
• Port: the node polls the agent on 6465/TCP. On Windows the installation creates the firewall rule.
• Hosts behind NAT or a VPS (push mode): choose "agent connects to the node" in the wizard. The agent then opens the connection to port 6466/TCP of the node itself and needs no open port. Security stays the same: the node still checks the host's key, the agent the node's key.
• Updates: the node updates agents automatically over the existing connection (can be switched off per host, "update now"). Every file is signed; the agent only accepts files with a valid signature and never an older version. If a new version does not start, it falls back to the previous one.
• Windows: an icon in the notification area of the taskbar shows that the agent is running, its version, the last poll and whether an update is pending. Switch it off with -NoTray during installation.
• Your own scripts: programs in the agent's local.d folder deliver your own services (state, text, measurements). They must belong to the administrator and must not be writable by others.
• Removal: monitor64-agent uninstall (Linux/FreeBSD as root, Windows as administrator from the program folder).

Linux without agent (SSH)

The node logs in with its own key and runs a fixed query script. On the host you create a user for this (recommended monitor64) and add the line from the wizard to its authorized_keys. SMART optionally needs sudo smartctl.

A password is only meant as an exception for systems without key login. It is only sent after you confirmed the host's fingerprint.

Proxmox, Docker, NAS and other interfaces

• Proxmox VE / Proxmox Backup Server: an API token with read permissions (role PVEAuditor or Audit). Proxmox VE only lists pending updates with the Sys.Modify permission; without it the "Updates" service says that it is not queried. The wizard suggests further nodes of a cluster as hosts of their own.
• VMs and containers: appear as services of the hypervisor ("should run" comes from "start at boot" or the restart policy). The memory of a VM has its own rule without a default threshold, because Proxmox counts the guest's cache. One click turns a guest into a host of its own.
• Docker: local socket, TCP or SSH.
• TrueNAS, Unraid, Redfish: an API key or a user with read permissions.
• UPS via NUT: the address of the NUT server (port 3493), optionally user and TLS.
• Prometheus exporter: the address of the exporter; node_exporter and windows_exporter are mapped to the same services as the agent. Your own metrics can be added as services with a threshold.

SNMP and traps

• Versions: v1, v2c and v3. v3 with authentication and privacy is recommended; v1/v2c send the community in clear text.
• Profiles: the node recognises devices itself (Synology, QNAP, TrueNAS, MikroTik, UniFi, APC, UPS via UPS-MIB, printers) and delivers matching services. Your own OIDs can be added as services.
• Ports: utilisation in Mbit/s and percent, error rate, link down, slower than before, half duplex, LACP.
• Traps: known traps (link down, UPS on battery …) trigger an immediate poll; others appear in the "Traps" service as a warning until you acknowledge them. The receiver is only open when an access uses traps. The default is port 162/UDP – in a container a port below 1024 needs CAP_NET_BIND_SERVICE or a port mapping such as 162→1162.

Services

• New services are offered as a hint and never adopted automatically. You decide: adopt or ignore.
• Vanished services (disk pulled, container deleted) stay as a problem until you remove them.
• Services that are not suggested (individual Windows services, stopped guests) can be adopted one by one at any time.
• Every service has history, thresholds, the expected state ("should run" / "may be off") and "display only" instead of notifying.

Thresholds

Three levels, the most specific one wins, each field inherits separately: default for all → overrides per group or tag → this host (directly at the service). The default is usually enough:

• Duration: the threshold only counts if all measurements in the period are above it. Hysteresis: 2 points, so a value at the limit does not flip back and forth.
• For large volumes there is also "less than X GB free" instead of percent.
• Fixed rules without a number: SMART FAILED, bad sectors, RAID/ZFS degraded, bond member down, security updates, reboot required, guest not running, Windows service stopped, job failed, backup too old and more. Per rule you choose: critical, warning or do not notify.

Problems and maintenance

• Every problem has a timeline: when it opened, where it was sent, who acknowledged or resolved it (user, API key or system) – also as CSV.
• Acknowledging stops reminders until it gets worse.
• Maintenance for hosts, groups or tags: now, scheduled or recurring. During maintenance recording continues but nothing is sent; if something is still broken afterwards, the notification comes then.
• If a host stops answering there is one notification "unreachable" – not one per service.

Notifications

Monitor64 uses the notification channels of the node. Everything that happens on one host in one round is one notification; the all-clear goes to exactly the channels that received the problem.

• Per level (warning/critical) you choose which channels notify; overrides per group or tag.
• Reminders while a problem is open and not acknowledged (never, every 4 hours, daily).
• Quiet hours from the node's settings: afterwards one digest. Critical problems can still notify immediately.
• If a service flaps there is one notification and then silence until it has been stable for 30 minutes.

Status pages

Hosts and individual services from Monitor64 can be shown on the status pages of the health checks. Only label and state leave the node – no values, addresses or error texts. Times in which Monitor64 was not running count neither as an incident nor as observed.

Cluster

In a Node64 cluster exactly one node monitors each host. You choose a preferred node and optionally backup nodes: if the responsible node fails, a backup node takes over after about 2 minutes and hands back after 5 minutes of stable operation. If the cluster is split the majority decides, so nothing notifies twice.

• All nodes use one shared key – agents and SSH hosts need it only once.
• The overview shows all hosts with "monitored by"; the interface fetches the history from the monitoring node.
• Before you add a backup node, "check reachability" tests whether it can reach the host at all.

Data, export and resources

• History in its own file monitor64.db in the data directory: 1-minute values for 48 hours, 5-minute values for 30 days, hourly values for 1 year.
• Export and backup: Monitor64 is fully part of the node's config export and backup (credentials only with an export password).
• Prometheus: node64_monitor_host_up, node64_monitor_state and node64_monitor_value under /api/metrics – see Prometheus.
• Resources: measured, 100 hosts with 800 services need about 30 MB of additional memory and less than 1 % of a CPU core.

Ports

Security

• The agent only knows fixed requests. There is no shell and no way to run commands on the host through the node.
• Node and host identify themselves to each other with keys. If a host's key changes, monitoring does not silently continue – it is reported.
• Agent files and updates are signed with the Node64 release key.
• Passwords and tokens are only sent to a target whose fingerprint (SSH key or certificate) you confirmed.
• Credentials are stored encrypted in the node; every change is recorded with the person in the audit log.

Proxmox VE and Docker from the health checks

Monitoring Proxmox VE and Docker with measurements now belongs to Monitor64. Health checks still check whether something is reachable. The update to Healthchecks 3.0.0 deletes the existing Proxmox and Docker checks and systems including their data – also at ipv64.net and on the other nodes of the cluster. Settings and credentials are not carried over: add the systems as hosts in Monitor64 again – the wizard only needs address and token.

Questions and wishes about Monitor64 are welcome in the forum v64.tech.

Something unclear, missing, or a question about Node64? Ask in the official forum v64.tech.