homelab-codex-ws/docs/sessions/2026-06-26.md

Sesja 2026-06-26 — fleet-prometheus etap 2: targety floty + zamknięcie buga deploy.sh vps

Cel

Kontynuacja "Prometheus jako źródło prawdy liveness floty" (krok 2 z planu w backlogu): dodać targety node_exporter floty 100.x do fleet-prometheus. Przy okazji domknięty najgroźniejszy bug z 2026-06-25 — deploy.sh vps rozkładający control-plane.

---

ZROBIONE

fix(deploy): guard pętli deploy-node — control-plane pomijany (commit 3b71707)

Bug (🔴 KRYTYCZNY, backlog A z 2026-06-24/25): deploy.sh vps deployował control-plane przez pętlę deploy-node.sh z COMPOSE_PROJECT_NAME wywiedzionym z REPO_PATH — innym niż deploy-local.sh (cwd=services/control-plane). Niezgodność project-name → Recreate → No such container: <hash>_control-plane-observer → set -e przerywa pętlę → mózg (observer/supervisor/executor/ui) znika. Potwierdzone w produkcji 2026-06-25.

Fix: guard w deploy-node.sh — serwisy z własnym services/<svc>/deploy-local.sh są pomijane w destrukcyjnej pętli. control-plane ZOSTAJE w hosts/vps/services.yaml (gate pytest+build nadal go testuje), pomijany jest tylko deploy pętlą; ma własną ścieżkę deploy-local.sh z poprawnym COMPOSE_PROJECT_NAME.

Potwierdzone w boju: deploy.sh vps wypisał Skipping control-plane: ma własną ścieżkę deployu, mózg nietknięty — observer/supervisor/executor/ui Up 25h healthy. Najgroźniejszy bug wczorajszej sesji — zamknięty.

---

feat(fleet-prometheus): targety node_exporter floty (commit 7d4014e)

Dodano do prometheus.yml targety floty, każdy z labelką node::

node	target	status (recon z VPS)
piha	100.108.208.3:9100	UP
solaria	100.100.231.104:9100	UP (intermittent)
lustro	100.99.85.73:9100	UP (off nocą — case anomaly detection)
vps	host.docker.internal (node:vps)	zachowany z etapu 1

Pominięte świadomie:

• saturn — laptop/workstation, nie serwer floty.
• chelsty + chelsty-infra — node_exporter DOWN z VPS (LTE edge). Do zbadania osobno (backlog).

Zero labelek availability/godzin — polityka "kiedy alarmować" celowo NIE trafia do configu Prometheusa. Pójdzie do anomaly detection (mózg uczy się wzorca dobowego z historii metryk). Na teraz: tylko scrape + label node:, Prometheus gromadzi historię.

---

docs(backlog): pomysł anomaly-detection liveness (commit 1529911)

Zapisano ideę: zamiast statycznych okien czasowych w regułach alertowych, mózg czyta historię z Prometheus i SAM wykrywa wzorzec dobowy per node. up==0 zgodne z nauczonym wzorcem offline = nie alarmuj; odbiegające = realna awaria. Wymaga tygodni historii → realne za ~2-4 tyg.

---

DEPLOY

deploy.sh vps przeszedł: DEPLOY OK, verify=green, 24 kontenery healthy. Fix A potwierdzony (control-plane pominięty w pętli). Prometheus zrecreate'owany przez ręczny docker compose ... up -d --force-recreate; config z 4 targetami widoczny w kontenerze.

---

PENDING (NIE potwierdzone — nie zakładać sukcesu)

• Health targetów piha/solaria/lustro w /api/v1/targets NIE zweryfikowany po finalnym recreate. Config je zawiera, ale czy scrape zwraca up — do sprawdzenia przy powrocie.
  • lustro może być down jeśli noc/off → to NIE błąd, to case dla anomaly detection.
  • solaria intermittent — podobnie.

---

Wnioski

• Najgroźniejszy bug zamknięty świadomym guardem, nie usuwaniem z manifestu: control-plane zostaje w services.yaml (gate go testuje), pomijana jest tylko destrukcyjna pętla deployu. Rozdzielono "co testować" od "jak deployować".

• Cicha rozbieżność deploy↔config (nowy tech-debt): deploy-node.sh po zmianie prometheus.yml NIE reloaduje/recreate'uje kontenera — Compose widzi ten sam obraz, zostawia Running, config się nie podmienia. Deploy mówi "green", a Prometheus trzyma stary config w pamięci. Dziś wymagało ręcznego --force-recreate. Dotyczy KAŻDEGO serwisu config-driven bez zmiany obrazu. → backlog.

• Potrójny rozjazd mastera przez równoległą sesję KB: w trakcie pracy CC na wątku Prometheusa równoległa sesja commitowała na master (bulk import Gmail). Rebase ratował, ale to anty-wzorzec. Lekcja: nie commitować na master równolegle, gdy CC pracuje na branchu/wątku — albo izolować pracę w worktree, albo serializować commity na master.

• Etap "targety floty" prawie domknięty: config wdrożony, health-verify pending. Następne etapy (osobne taski): reguły liveness (up==0 for: 5m), wpięcie firing→brain-watchdog (/api/v1/alerts→Telegram, bez Alertmanagera), potem cutover ze starej rury eventowej. Plus: zbadać czemu chelsty node_exporter down; anomaly detection gdy uzbiera się historia.