darman/homelab
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

jupiter: add VictoriaMetrics monitoring #1

Merged
darman merged 8 commits from feat/mars-victoriametrics into master 2026-08-24 04:48:46 +02:00
Conversation 18 Commits 8 Files Changed 2
+1 -1
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 082cbaff2a - Show all commits
services/monitoring/victoriametrics.nix
+1 -1
View File
@@ -10,7 +10,7 @@
{ {
services.victoriametrics = { services.victoriametrics = {
enable = true; enable = true;
retentionPeriod = "30d"; retentionPeriod = "15d";
luna marked this conversation as resolved
darman commented 2026-08-24 04:02:42 +02:00
Review
Copy Link
Copy Source

This puts the TSDB on jupiter's eMMC, which I think is the one real blocker here.

The module hardcodes -storageDataPath=/var/lib/${cfg.stateDir} and runs with DynamicUser = true, so the data actually lands in /var/lib/private/victoriametrics on the 29G OS disk. The stateDir option cannot help — it is always relative to /var/lib/.

Every other stateful service on jupiter lives on the array under /mnt/data/AppData. More to the point, services/media/prowlarr.nix:32 documents this exact trap from the last time it bit this repo:

systemd derives RequiresMountsFor from the unit's own paths, which here is only /var/lib/prowlarr on the eMMC — so without this prowlarr starts happily with the array absent and writes its state onto the 29G OS disk.

Same shape here, same DynamicUser -> /var/lib/private/ path, so the existing idiom drops straight in:

fileSystems."/var/lib/private/victoriametrics" = {
  device = "/mnt/data/AppData/victoriametrics";
  fsType = "none";
  options = [ "bind" "nofail" ];
};

Please also add the RequiresMountsFor pin that prowlarr.nix calls out — that is the half people forget, and without it this silently falls back to the eMMC whenever the array is not assembled.

This matters more than usual right now: 6 targets at a 5s interval is a continuous small-write workload aimed at the box's wear-limited disk, which was at 85% full earlier today.

This puts the TSDB on jupiter's eMMC, which I think is the one real blocker here. The module hardcodes `-storageDataPath=/var/lib/${cfg.stateDir}` and runs with `DynamicUser = true`, so the data actually lands in `/var/lib/private/victoriametrics` on the 29G OS disk. The `stateDir` option cannot help — it is always relative to `/var/lib/`. Every other stateful service on jupiter lives on the array under `/mnt/data/AppData`. More to the point, `services/media/prowlarr.nix:32` documents this exact trap from the last time it bit this repo: > systemd derives RequiresMountsFor from the unit's own paths, which here is only `/var/lib/prowlarr` on the eMMC — so without this prowlarr starts happily with the array absent and writes its state onto the 29G OS disk. Same shape here, same `DynamicUser` -> `/var/lib/private/` path, so the existing idiom drops straight in: ```nix fileSystems."/var/lib/private/victoriametrics" = { device = "/mnt/data/AppData/victoriametrics"; fsType = "none"; options = [ "bind" "nofail" ]; }; ``` Please also add the `RequiresMountsFor` pin that prowlarr.nix calls out — that is the half people forget, and without it this silently falls back to the eMMC whenever the array is not assembled. This matters more than usual right now: 6 targets at a 5s interval is a continuous small-write workload aimed at the box's wear-limited disk, which was at 85% full earlier today.
listenAddress = ":8428"; listenAddress = ":8428";
prometheusConfig = { prometheusConfig = {
4