Historical storage + threshold alerting + optional InfluxDB/Prometheus export for SNMP metrics

[msporik]

Currently SNMP monitoring (CPU, memory, uptime, temperature, voltage) is display-only and live — there's no persisted history, so values aren't retained beyond the current 60s poll, and there's no way to review trends over time.
Requests (could be split into separate issues if easier to prioritize):

Local historical storage — persist SNMP metric samples (e.g. to SQLite, similar to how syslog retention already works) with a configurable retention window (e.g. SNMP_METRICS_RETENTION_DAYS, default 30). Show a basic history graph per metric on the device detail page (1h / 24h / 7d / 30d).
Threshold-based alerting — configurable threshold per metric (CPU load %, memory usage %, temperature °C), globally or per device. Fires a webhook (same pattern as the existing cve-alert webhook) when crossed, and optionally on recovery.
Optional export to InfluxDB / Prometheus — for users who already run Grafana/InfluxDB/Prometheus elsewhere and want long-term retention and richer visualization than mikr's own UI, e.g. an InfluxDB line-protocol writer or a /metrics Prometheus scrape endpoint (env-configurable, off by default).

Together these would let mikr cover both fleet management and exception-based health alerting for MikroTik devices without needing a second monitoring tool just for CPU/RAM/temperature thresholds and trend history.

[hreskiv]

Thanks for the detailed write-up — this is a solid direction and it's planned for implementation.

The three parts map cleanly onto existing infrastructure, so they'll be built as separate, prioritized pieces:

1. Local historical storage — SNMP metric samples persisted to SQLite with a configurable retention window (SNMP_METRICS_RETENTION_DAYS, default 30), reusing the same retention approach as syslog. Per-metric history graphs on the device detail page with 1h / 24h / 7d / 30d ranges. This is the foundation and will land first.

2. Threshold-based alerting — per-metric thresholds (CPU %, memory %, temperature °C), global or per device, firing a webhook on cross and optionally on recovery, using the existing webhook pattern. Builds on the storage layer above.

3. Optional InfluxDB / Prometheus export — off by default, env-configurable, for users who already run a Grafana/Influx/Prometheus stack and want long-term retention and richer dashboards. Likely a /metrics Prometheus endpoint and/or an InfluxDB line-protocol writer.

Will update this thread as each part ships.

[hreskiv]

Phase 1 has shipped in v1.53.0 (with a follow-up fix in v1.53.1 — details below).

What landed: CPU load and memory usage are now persisted and graphed per metric on the device detail page, alongside temperature, voltage, fan speed and any other sensor a model exposes. Ranges are 1h / 6h / 24h / 7d / 30d, sampled every 5 minutes.

Two notes where the implementation differs from what I described earlier in this thread:

Retention is METRICS_RETENTION_DAYS, default 90 — not SNMP_METRICS_RETENTION_DAYS default 30. The 5-minute sample store already existed (it has held /system/health sensor history since v1.42.0), with its own 90-day retention. Adding a second env var pruning the same table would have been incoherent, and defaulting it to 30 would have silently truncated existing users' sensor history on upgrade. So there is one knob for the tier, and it is now adjustable in Settings rather than only via the environment. If 90 days is more than you want, you can lower it there.

It is not SNMP-only. These metrics are read on every connection method, so the history works for SSH- and REST-polled devices as well as SNMP. Notably, SNMP-polled devices previously stored no history at all, and now do.

The graphs cost no extra device I/O: CPU and memory were already being read on every 60s poll and simply discarded, so this persists what was already on the wire rather than adding queries.

v1.53.1 fixes a bug worth flagging if you tried 1.53.0: the graphs only recorded SNMP-polled devices. /system/resource is rendered for humans over SSH (3%, 49.5MiB) but returned as bare numbers over REST/SNMP, and the new code assumed the latter. Upgrade to 1.53.1; the graphs fill in about 5 minutes after restart.

Parts 2 (threshold alerting) and 3 (InfluxDB/Prometheus export) remain planned as separate pieces, and this thread stays open for them.