510fe0b600
Session logi zostaja w docs/sessions/ (decyzja z etapu 1). Dodany wylacznie blok frontmattera: type: session-log, visibility: private, status: active, updated = data ostatniego commita pliku. Tresc nietknieta — kazdy plik to +9/-0 linii. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
112 lines
4.9 KiB
Markdown
112 lines
4.9 KiB
Markdown
---
|
|
okf: "0.1"
|
|
type: session-log
|
|
visibility: private
|
|
status: active
|
|
updated: 2026-06-26
|
|
links: []
|
|
---
|
|
|
|
# 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.
|