3 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	b3885c3b81	fix(host_agent): an unwired sensor no longer sets a host's temperature (#5759) ... #5759 "VDNT-Util01 reads 114 °C: its "hottest sensor" is a Super-I/O input with nothing wired to it". AUXTIN0/1 on the board's Nuvoton chip read 110-112 °C flat at every load while the CPU package moved 49-87, so temp_c_max read critical all week. The max now counts only readings that can be real: not an AUXTIN input, above 0 and below 125 °C. Each sensor keeps its own temp_c row. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-14 17:09:48 -04:00
bvandeusenandClaude Opus 5.5	c9f5c049db	feat(alerts): renames carry their alerts — monitor and host renames move rules, windows and history (#5065) ... #5065 "Renames carry their alerts". Alert rules, maintenance-window scopes and metric history key a thing by (source, name), so a rename used to leave the rules watching a name nothing reported under, and split the history. - core/renames.carry_rename moves AlertRule.resource_name, MaintenanceWindow.scope_resource, plugin_metrics and plugin_metrics_hourly to the new name in the caller's transaction. A host rename also carries its parts: host_agent "<host>:…" and docker "<host>/…" (HOST_SOURCES). Matching is exact (a prefix compare, not LIKE or a collation range). History left under the new name by something deleted is dropped first rather than merged in. - Web monitor edit, MCP update_monitor and web host edit call it; MCP answers with `carried` (it used to return a warning naming stranded rules). - A name another monitor of the same type, or another host, already has is refused on create and rename: two would share one history. - The rename is audited (monitor.updated / host.renamed) with what moved. Tests: an integration test renames a firing monitor through the web route and finds its rule still firing and cleared by a sample on the new name, its window and raw+hourly history moved and an orphan's history dropped; a host rename moves agent and container parts but not a longer-named host's or another source's; a guard that every host_agent resource is "<host>" or "<host>:…". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-06 14:02:43 -04:00
bvandeusenandClaude Opus 4.8	a9e7baee6a	feat(host_agent): collect network, disk I/O, per-core CPU, temps, memory PSI ... Extends the push agent (v1.2.0) with the Netdata-style signals the operator wants: per-core CPU, per-interface network throughput and per-disk I/O (rates derived in-agent from monotonic /proc counter deltas, with counter-reset clamping), hardware temperatures (/sys/class/hwmon), memory-pressure PSI (/proc/pressure), and cached/buffers memory breakdown. All stdlib-only. Server side needs no migration — these land as additional rows in the shared PluginMetric table via _expand_sample_to_metrics. Per-resource series use a ':' in resource_name (host:net:eth0, host:core0, host:temp:Package) so the existing fleet widget's ':' filter ignores them; host-level totals/max are emitted at the bare host resource. New sample keys are optional, so older agents keep ingesting unchanged. Unit tests for the new parsers, rate/reset logic, and the expander contract. Data foundation for the Netdata-style host view (task #867). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-16 10:11:30 -04:00