TarleyNode 0.3.4

High availability

• Setting up high availability works end to end from Settings › Backups & high availability, which now shows High availability first. The card says up front that a spare address is needed, shows each step with a progress bar while the server prepares (and says plainly if a step stalls), and after Enable asks you to use the shared address from then on and point your DNS name at it. Join and witness commands install Docker when needed and show progress bars for the download and the database copy. A server or witness waiting to join can get a new command or be cancelled.
• A server that hands over or loses its lease rejoins as a standby by itself again; before, it could not find the other servers once its database had stopped.
• Readings now reach every standby reliably. The cluster agent no longer leaks a connection per message (which grew it until it ran out of memory, even when idle), each standby has its own size-capped queue, and a standby that was unreachable is caught up from the active server's history when it is back. Tested at 8,000 readings a second with a standby down for 3 minutes: nothing refused, nothing lost.
• A backup on a cluster server no longer restarts the database and the application without the cluster's settings, which stopped the standbys copying.
• A backup can be restored into a cluster, on the active server: the cluster keeps its servers, addresses and certificates, and the standbys receive the data and keys by themselves. Every restore now backs up the data it replaces first, restores next to the live data and swaps in only after its checks pass, so a failed restore leaves the server as it was. The card asks for nightly backups while they are off.
• The phone app's port moved from 8444 to 8448 on the server, as high availability needs 8444; installations that published 8444 are moved automatically.

Faster

• Sorted device lists, the audit trail, audit search and service-level reports answer far faster on large installations (a sorted page of 3,000 devices went from 0.5 s to 13 ms). The Devices page no longer hangs when sorted by address on page 2: PostgreSQL's JIT is turned off.

Fixed

• Service levels covering more than 1,000 checks counted only the first 1,000.
• A database hiccup no longer signs everyone out; the console shows it as a temporary error.
• Removing a sensor asks why, like pausing, and the reason is kept in the audit trail and service-level reports.
• Every new virtual machine and container is monitored automatically when the device has automatic discovery on, outside the 40-sensor limit. In Top 10 lists, a virtual machine, host or datastore is named first, with the hypervisor manager underneath.
• Uninstalling also removes the update check and cluster timers.

Changed

• The audit trail and the Events list (syslog and traps) show the last 3 months by default, so they open and search quickly however long the history grows. Turn on **Include older entries** to search everything; nothing is deleted. Inside the database both are now kept in monthly partitions, made ahead of time by the server; the update copies the two tables once. The API takes `older=1` for the same. The How-tos and Training manual cover it.
• Business service availability cannot be bent either. Pausing or removing a member check, or changing how the checks combine, leaves time not measured rather than counted as up, and downtime always counts. Targets change from the next month, services are archived rather than deleted, and the status history cannot be edited. Each service has a monthly report (page and PDF) listing the time not measured and the changes, and a finished month is frozen with a fingerprint.
• Service levels (SLAs) cannot be bent after the fact. A change to the target or scope applies from the next month. Checks paused or removed during a month still count, and the report lists each pause and removal with who and why. Service levels are archived, not deleted. A finished month is stored once, unchangeable even in the database, with a SHA-256 fingerprint on the page and the PDF. The How-tos and Training manual cover it.
• With two-step sign-in, once the password is accepted the sign-in page shows only the code box, saying so, instead of showing the email and password again as if sign-in had failed. Use a different account goes back.
• Uploading an SSL certificate takes all the files the certificate authority sent at once, whatever they are called: certificate, chain or CA bundle and key, in PEM or DER, or a .pfx or .p12 file with its password. TarleyNode picks out which is which, orders the chain, saves them under the names its web server expects and restarts it, as before. The How-tos cover it.
• Paired phone apps can add alert notes, run device tools, rescan devices, end maintenance early and, for administrators, rename and recategorise devices. Group members keep only what their groups allow.
• Adding a Telegram destination shows Telegram's notice that, in some countries such as South Africa, new users must buy Telegram Premium before they get an SMS sign-in code. Existing users and the bot are not affected.
• Notification destinations are listed one per row, with their type, state and quiet hours, and can be searched, rather than as large cards.
• On the Notifications page, the phone app card no longer says "Coming soon". It points to the phone app and desktop alerts in Settings › Your account. Its text, and the Installation delivery card's, now sit next to their icon instead of at the far right.

New

• A server smaller than the sizing table recommends for the sensors it monitors gets a calm note for administrators on the Overview, in Settings › Server and, per server, on the High availability card, naming what is short, such as "70 sensors need 4 CPU cores; this server has 2." It is advice only: nothing is refused and monitoring never stops. In a cluster every server reports its cores, memory and data disk with its status; a server on an older release is not judged. `GET /api/system/sizing` gives the same, and `GET /api/ha` lists each server's size. The How-tos and Training manual cover it.
• Check every, per device (Edit device): run every check on a device at one interval, such as 15 s on a core switch. Existing checks move to it and every check added later follows it (by hand, from a template, in bulk, ticked under Sensors or by automatic discovery); a timeout that no longer fits is shortened, never lengthened. Going back to each check’s own interval leaves the checks where they are. Audited, and in the API as check_interval_ms on PATCH /api/devices/{id}.
• A device’s Sensors list says how many more sensors were found than automatic discovery monitors by itself (up to 40 a device), so they can be ticked.
• Proxmox Datacenter Manager monitoring (tested against a real Datacenter Manager), through its API with a read-only token (a user and its token, both with the Auditor role on /). One check fails when Datacenter Manager cannot reach a remote and names it; others watch one remote (its nodes online), or a node, virtual machine or container, storage or Backup Server datastore of any remote, with the same CPU, memory and disk readings as Proxmox VE. Every node, guest and storage of every remote is listed under Sensors to tick, named by its remote first, such as lab/pve1. The certificate can be pinned in the login.
• Forgot password. The sign-in page's Forgot password? sends a link to the account's email through this server's own email settings (the first email destination under Notifications), with the same answer whether or not the account exists. The link works once, for 30 minutes; choosing the new password signs the account out everywhere, including paired phones and browsers, and is in the audit trail. Without email, `sudo tarleynode reset-password EMAIL` on the server prints a one-time link shown only there, and the sign-in page explains how. Administrators can change someone's sign-in email with Change email in Settings › People & sign-in. The How-tos and Training manual cover it.
• Google Chat as a notification destination, through a space's incoming webhook. Each incident's messages go in one thread. The How-tos and Training manual mention it.
• SMS through your own provider: any SMS service with an HTTPS address, sent as JSON, a form or in the address, signed in with an API key header, a bearer token or a user name and password, with {to}, {from} and {message} placed where the provider expects them. The How-tos and Training manual cover it.
• Follow IP changes, a per-site toggle on the Discovery page (on by default): when a scan finds a monitored device's MAC address at a new IP, as DHCP can do, the device and its checks move there instead of showing as down while a duplicate appears as new. The audit trail records each move. The How-tos and Training manual cover it.
• The Devices page says when devices have been offline for 7 days or more, as their address may have changed, and offers to remove them together. Review lists each with how long it has been offline and, if a scan saw the same device (by MAC address) elsewhere since, where. The How-tos and Training manual cover it.
• Groups limit viewers and operators to some devices. In Settings › People & sign-in › Groups, a group gets people and device categories. Its members then see only devices in those categories, with their sensors and alerts, on the console, the phone app and with API keys, and only the Overview, Devices and Incidents pages; nothing else is shown to them. Administrators always see everything. The How-tos and Training manual cover it.
• Desktop app and alerts, in Settings › Your account. Chrome, Brave and Edge install the console as an app in its own window, and Chrome, Brave, Edge and Firefox show alerts as desktop notifications, sent from this server straight to the browser with nothing in between. Chrome, Brave and Edge show them with every window closed while running in the background; Firefox while it is open. Each browser can hide details on shared screens and is listed to remove; alerts keep arriving after signing out and stop 90 days after its owner last signed in. Needs an https address with a trusted certificate. Phone and browser destinations can now be tested from Notifications. The How-tos and Training manual cover it.
• More platforms, all in beta. oVirt, Oracle Linux Virtualization Manager and Red Hat Virtualization through the engine's REST API: hosts, virtual machines and storage domains. Virtuozzo over SSH: virtual machines and containers. HPE Morpheus (Enterprise and VM Essentials) through its API with an access token: clusters, hypervisor hosts and instances. IBM PowerVM through the HMC REST API: managed systems, partitions and VIOS. For each of these, every object is listed under Sensors to tick. Oracle Database checks, which need no Oracle client and report sessions and the fullest tablespace. Redstor backup checks on the Windows machine running the agent, from its services and Application event log. Linux on IBM Z (zLinux) works with Linux health over SSH. The How-tos and Training manual cover each one.
• Send flows to TarleyNode, on a router, switch or firewall's page, shows the commands to export NetFlow, IPFIX or sFlow for its make (Cisco IOS and Nexus, Aruba CX, Aruba and HPE ProCurve, Juniper, MikroTik, FortiGate, pfSense, OPNsense, Palo Alto, SonicWall, Ubiquiti EdgeRouter, VMware distributed switch and others). They come already filled in with the address and port its site receives on, and the panel says when flows arrive. TarleyNode still never changes a device. Each site now reports its flow ports and address, and the installer records the server's own address for this. The How-tos and Training manual cover it.
• Firewall profiles (beta) for Palo Alto, Check Point, Cisco ASA and Firepower, SonicWall, Sophos, WatchGuard and Juniper SRX. Depending on the make, they cover sessions or connections, session table use, GlobalProtect and other VPN tunnels, CPU and memory, and high availability or policy state. A failed cluster member or an uninstalled policy alerts. Interfaces, CPU, memory and hardware sensors still come from the standard MIBs, as they do for any device. The device's Sensors list asks for a support pack if a reading looks wrong.
• The How-tos and the Training manual cover everything added since 0.3.2: pausing with a reason, sensor graphs, firewalls, Proxmox VE, XCP-ng, Nutanix, Veeam, VMware inventory, Windows performance counters, web transactions, custom reports, checks TarleyNode adds by itself, the audit trail, support packs and the API guide. Places in Settings name their new groups.

All releases · Plain text