---
okf: "0.1"
type: session-log
visibility: private
status: active
updated: 2026-06-24
links: []
---

# Sesja 2026-06-24 — fleet-prometheus etap 1: scaffold + deploy-node hostname fix

## Cel

Wdrożenie etapu 1 Prometheus-as-truth dla liveness floty: scaffold serwisu
`fleet-prometheus` pod GitOps, poprawka krytycznego buga hostname w `deploy-node.sh`,
uruchomienie kontenera na VPS.

---

## ZROBIONE

### Scaffold `services/fleet-prometheus/` pod GitOps

- `prom/prometheus:v3.5.0` — pinned (nie `latest`).
- Scrape: self + `fleet-node` (`node_exporter` VPS przez `host.docker.internal:9100`).
- Retencja: 15d / 2 GB.
- `mem_limit: 512m`, `oom_score_adj: 200` — ofiara OOM przed control-plane (`-900`);
  VPS ma 4 GB RAM + 4 GB swap.
- Healthcheck: `wget` in-container (`/bin/-/healthy`) — obraz ma `wget` i `promtool`,
  nie ma `curl`; zweryfikowane przed commitem.
- `alerting:` i `rule_files:` obecne jako puste placeholdery — osobny krok.
- Zarejestrowany w `hosts/vps/services.yaml` + `inventory/topology.yaml`.
- Ekspozycja: `tailscale-internal`.

### Bind fix — nasłuch na Tailscale IP, nie `0.0.0.0` (commit `43c47a0`)

- Port bind: `${TAILSCALE_BIND_IP}:9090:9090` zamiast `0.0.0.0`.
- `.env` z `TAILSCALE_BIND_IP=100.95.58.48` tworzony **ręcznie** na każdym hoście
  (gitignored) — `services/fleet-prometheus/.env` na VPS już utworzony.
- Defense-in-depth: nie polegamy na firewallu VPS poza repo.

### Fix krytyczny: `deploy-node.sh` — rozwiązywanie `HOST_DIR` przez `os_hostname` (commity `644f32d` + `ae739b5`)

**Root cause**: `deploy-node.sh` ustalał `HOST_DIR` przez `hosts/$(hostname | lower)`.
VPS ma OS-hostname `ubuntu-4gb-hel1-1`, a katalog to `hosts/vps` — mismatch powodował
ciche `"No services found" + exit 0` (fałszywe zielone). VPS **nigdy** nie deployował się
tą ścieżką od początku istnienia skryptu.

**Fix**:
- Dodano pole `os_hostname` do wszystkich 6 `hosts/*/host.yaml` (tylko VPS różni się:
  `os_hostname: ubuntu-4gb-hel1-1`; pozostałe = `hostname`).
- `deploy-node.sh` mapuje `HOST_DIR` przez `os_hostname == $(hostname)` z fallbackiem
  na starą logikę + twardy `exit 1` zamiast cichego skip.
- Zweryfikowane: mapowanie `ubuntu-4gb-hel1-1 → hosts/vps` działa, deploy wszedł
  w pętlę serwisów.

### SSH aliasy `vps`/`piha` na SOLARII

Dodane do `~/.ssh/config` na SOLARII (parity z SATURN) — zamknięty backlog item.

---

## NIEDOKOŃCZONE — następny krok (priorytet)

### fleet-prometheus NIE jest jeszcze uruchomiony na VPS

`deploy.sh vps --no-gate` wszedł po raz pierwszy w pętlę serwisów (hostname fix zadziałał),
ale **padł na `node-agent`**:

```
Container node-agent Recreate
Error: No such container: 1913f743ea38_node-agent
```

**Przyczyna**: rozjazd stanu Docker Compose — istniejące serwisy VPS (`node-agent`,
`control-plane`, up ~7–14 dni) zostały utworzone **inną ścieżką / project-name** niż
widzi `deploy-node.sh` (bo VPS nigdy wcześniej nie deployował się tą ścieżką).
`set -e` przerwał pętlę na `node-agent`; `fleet-prometheus` jest dalej w kolejce
— NIE powstał. `node-agent` prawdopodobnie wciąż żyje (błąd przy Recreate, nie kill).

**Plan domknięcia — Wariant A (uzgodniony)**:
Postawić `fleet-prometheus` ręcznie, z pominięciem rozjazdu stanu pozostałych serwisów:

```bash
# na VPS:
cd ~/homelab-codex-ws
docker compose \
  -f services/fleet-prometheus/docker-compose.yml \
  -f hosts/vps/runtime/fleet-prometheus/docker-compose.override.yml \
  --env-file services/fleet-prometheus/.env \
  up -d
```

**Weryfikacja po uruchomieniu**:
- `ss -tlnp | grep 9090` → musi pokazać `100.95.58.48:9090` (NIE `0.0.0.0`).
- Kontener `healthy` (`docker ps`).
- Oba targety `up`: `http://100.95.58.48:9090/api/v1/targets`.

---

## Dalsze etapy Prometheus-as-truth (osobne sesje)

1. Targety floty `100.x` (wszystkie nody przez Tailscale).
2. Reguły liveness: `up==0 for: 5m`.
3. Integracja `brain-watchdog`: odpyt `/api/v1/alerts` → Telegram.
4. Rotacja tokenu HAOS w domowym prom (plaintext).
5. Przepięcie observer / panel `agents.okit.pl` na źródło Prometheus.

---

## Nowe tech-debty (dodane do `docs/backlog.md`)

1. **Rozjazd stanu Docker Compose na VPS** — serwisy `node-agent`, `control-plane` i inne
   stworzone innym `project-name` niż `deploy-node.sh` oczekuje; Recreate pada na stale
   container ID. Dotyka żywego control-plane (~7 dni uptime) — ostrożnie, osobna sesja.
2. **Flaky testy control-plane** — `test_incident_lifecycle.py::test_run_once_quarantines_bad_event`
   i `::test_run_once_skips_observer_emitted_events` failują przez state-leak między
   przebiegami pytest (moduł-level `EVENTS_DIR`/`FAILED_EVENTS_DIR`/checkpoint, nie
   `tmp_path`). Kod observera zdrowy. Gate deploy.sh nierzetelny dopóki nie naprawione;
   musieliśmy użyć `--no-gate`.

---

## Wnioski

- **Hostname-to-directory mismatch** był cicho od zawsze: `exit 0` bez deployu wyglądał
  jak sukces. Wzorzec `os_hostname` w `host.yaml` + twardy `exit 1` eliminuje cichą
  kategorię błędów dla całej floty.
- **Rozjazd state Compose** to dług z epoki przed GitOps-deployment na VPS — teraz
  widoczny, bo po raz pierwszy realna pętla serwisów na VPS. Dotykać ostrożnie (live
  control-plane).
- **`--no-gate` jako sygnał**: gate deploy.sh jest zawodny przez flaky testy —
  każde ominięcie gate'u powinno być odnotowane i gonione naprawą testu.
- Fleet-prometheus wchodzi nowym serwisem (zero state do rozjazdu) → ręczny
  `docker compose up -d` jest bezpieczny i wystarczający do domknięcia etapu 1.
