Monitoraggio

Rediacc fornisce comandi di monitoraggio per la salute della macchina, i container in esecuzione, i servizi, lo stato dei repository e le diagnostiche di sistema.

Salute della Macchina

Ottieni un report sanitario completo di una macchina:

rdc machine health --name server-1

Questo riporta:

• Sistema: uptime, utilizzo del disco, utilizzo del datastore
• Container: conteggi in esecuzione, sani, non sani
• Archiviazione: stato SMART della salute
• Problemi: problemi identificati

Usa --output json per un output leggibile dalla macchina.

Elenco dei Container

Visualizza tutti i container in esecuzione su tutti i repository di una macchina:

rdc machine containers --name server-1

Colonna	Descrizione
Name	Nome del container
Status	Uptime o motivo di uscita
State	In esecuzione, uscito, ecc.
Health	Sano, non sano, nessuno
CPU	Percentuale di utilizzo CPU
Memory	Utilizzo della memoria / limite
Repository	Quale repository possiede il container

Opzioni:

• --health-check, Esegui controlli attivi della salute sui container
• --output json, Output JSON leggibile dalla macchina

L’output JSON include i dettagli completi del container (labels, port_mappings, image, id) più repository (nome risolto), repository_guid (GUID originale), domain e autoRoute.

Elenco dei Servizi

Visualizza i servizi systemd relativi a Rediacc su una macchina:

rdc machine services --name server-1

Colonna	Descrizione
Name	Nome del servizio
State	Attivo, inattivo, fallito
Sub-state	In esecuzione, morto, ecc.
Restarts	Conteggio riavvii
Memory	Utilizzo della memoria del servizio
Repository	Repository associato

Opzioni:

• --stability-check, Segnala i servizi instabili (falliti, >3 riavvii, auto-riavvio)
• --output json, Output JSON leggibile dalla macchina

L’output JSON include i dettagli completi del servizio con repository (nome risolto) e repository_guid (GUID originale).

Elenco dei Repository

Visualizza i repository su una macchina con statistiche dettagliate:

rdc machine repos --name server-1

Colonna	Descrizione
Name	Nome del repository
Size	Dimensione dell’immagine disco
Mount	Montato o smontato
Docker	Daemon Docker in esecuzione o fermato
Containers	Conteggio dei container
Disk Usage	Utilizzo effettivo del disco nel repository
Modified	Ora dell’ultima modifica

Opzioni:

• --search <text>, Filtra per nome o percorso di mount
• --output json, Output JSON leggibile dalla macchina

L’output JSON include name (risolto) e guid (GUID originale), e annida i containers di ogni repository (con domain, autoRoute, repository/repository_guid) e gli array services.

Salute dell’Archiviazione

Ispeziona la frammentazione BTRFS e la condivisione tramite reflink su tutti i repository di una macchina:

rdc machine query --name server-1 --storage-health

Colonna	Descrizione
Quota	La dimensione massima del repository (il suo tetto di crescita, impostato alla creazione o tramite resize/auto-grow)
Allocated	Quanto l’immagine sparsa occupa effettivamente nel pool in questo momento
Unique	Dati unici effettivi posseduti solo da questo repository
Shared	Blocchi di dati riutilizzati tra repository tramite reflink BTRFS (copie gratuite)
Reclaimable	Il divario allocato-vs-usato che repo trim può restituire al pool. Mostra - per i repository smontati
Discards	Se il volume cifrato propaga i discard (on per qualsiasi repository montato da una versione corrente)
Divergence	Percentuale dell’immagine unica in questo repository rispetto a quella condivisa (più alta significa più reclaimable se eliminato)
Frag	Estensioni per GB nell’immagine copy-on-write (solo informativo)

Quota e allocazione sono numeri diversi per design: un repository con una quota di 20 GB che memorizza 6 GB di dati costa al pool solo quanto ha allocato. Il pool può quindi promettere una quota totale superiore a quella fisicamente disponibile, e la colonna Reclaimable mostra quanta parte dell’allocazione di ciascun repository non è più utilizzata e può essere recuperata con il trim.

Al di sotto della tabella, un riepilogo del pool riporta il livello di riempimento del datastore e quanto spazio gli snapshot di backup stanno bloccando:

Pool: 265.4 GB used, 95.2 GB free (73.6% full)
Backup snapshots pin 2.1 GB (1 active, 0 stale; stale ones are removed by 'rdc machine prune')

Mentre un backup è in esecuzione, il suo snapshot continua a fare riferimento a ogni blocco che condivide con i repository attivi: eliminazioni e trim liberano meno spazio nel pool finché quel ciclo di backup non termina e lo snapshot viene eliminato. Gli snapshot obsoleti di backup interrotti vengono rimossi automaticamente dal gestore dello storage entro pochi minuti.

Il riepilogo mostra i risparmi totali dai reflink BTRFS:

14 repos, 224.3 GB virtual size
Unique data: 323.7 MB | Shared: 224.0 GB | Efficiency: 99.9%

• La dimensione virtuale è la somma di tutte le dimensioni delle immagini dei repository. È come appaiono i repository, ma conta due volte i blocchi condivisi tramite reflink.
• I dati unici sono l’archiviazione effettiva consumata dai dati del repository che esistono in un solo repository. Questo è ciò che libereresti eliminando un repository.
• Shared è la quantità di dati riutilizzati tra repository tramite reflink BTRFS. Il fork di un repository crea copie tramite reflink che condividono blocchi finché uno dei due lati non scrive nuovi dati, a quel punto i blocchi divergono.
• Efficiency è la percentuale di dati riutilizzati tramite reflink. Maggiore è meglio. Una macchina con molti fork dallo stesso genitore mostrerà un’efficienza vicina al 100%.

La colonna Frag è informativa. Conta le estensioni del file immagine copy-on-write, non i file che la tua applicazione legge al suo interno, quindi risulta alta sotto normali carichi di lavoro con scritture casuali (database, layer container) e non predice le prestazioni di lettura su archiviazione con supporto SSD. Rediacc non offre deliberatamente un comando di deframmentazione: btrfs filesystem defragment rimuove la condivisione tramite reflink di fork e snapshot, il che su un pool quasi pieno può aumentare drasticamente l’utilizzo dello spazio mentre i benchmark non mostrano alcun guadagno misurabile in lettura. Per le misurazioni complete e il ragionamento, vedi Il Tuo Indice di Frammentazione Sembra Terrificante. Ho Misurato Quanto Costa..

La scansione viene eseguita in parallelo e richiede 5-15 secondi a seconda del numero e della dimensione dei repository. Quando --storage-health non è specificato, dopo l’output della query appare un suggerimento di una riga come promemoria.

Scrub BTRFS

Rediacc pianifica automaticamente uno scrub BTRFS settimanale su ogni macchina. Lo scrub legge ogni blocco di dati nel datastore, verifica i checksum e segnala eventuali corruzioni. Questo rileva la corruzione silente dei dati (bitrot) prima che si propaghi ai backup e ai fork.

Lo scrub viene eseguito ogni domenica alle 02:00 ora locale (fuso orario della macchina) con un ritardo casuale fino a 1 ora. Viene eseguito alla priorità I/O più bassa (ionice idle, nice 19) in modo da non interferire con i servizi in esecuzione. Sulle macchine con SSD, aspetta circa 8 minuti per 100 GB di datastore.

Il timer dello scrub viene installato automaticamente al primo avvio del daemon dopo un aggiornamento di renet. Quando la politica di scrub cambia in una futura versione di renet, si aggiorna da sola al prossimo avvio del daemon senza alcuna azione da parte dell’utente.

Stato dello Scrub

Il risultato dell’ultimo scrub viene salvato fuori dal volume BTRFS (in /var/lib/rediacc/scrub-last-result.json) in modo che rimanga leggibile anche se il volume ha problemi. L’output di rdc machine query --system include un campo scrub_status:

"scrub_status": {
  "last_run_human": "3 days ago",
  "status": "ok",
  "total_errors": 0,
  "uncorrectable": 0,
  "duration_seconds": 312
}

Stato	Significato
ok	L’ultimo scrub è completato senza errori
never_run	Lo scrub non è ancora stato eseguito (il timer è stato appena installato)
overdue	L’ultimo scrub è stato eseguito più di 14 giorni fa
errors_found	Lo scrub ha trovato mancate corrispondenze di checksum (controlla i conteggi total_errors e uncorrectable)
failed	Il processo di scrub è uscito con un codice non zero

Se uncorrectable è maggiore di zero, i blocchi interessati non possono essere riparati automaticamente (BTRFS su disco singolo non ha copie ridondanti). Ripristina il repository interessato dal backup più recente.

Scrub Manuale

Per eseguire uno scrub immediatamente (ad esempio dopo un’interruzione di corrente o una migrazione del disco):

rdc term connect -m server-1 -c "sudo renet maintenance scrub --datastore /mnt/rediacc"

Il risultato viene salvato nello stesso file JSON ed è immediatamente visibile nel successivo rdc machine query --system.

Stato del Vault

Ottieni una panoramica completa di una macchina incluse le informazioni di deployment:

rdc machine vault-status --name server-1

Questo fornisce:

• Hostname e uptime
• Utilizzo di memoria, disco e datastore
• Totale repository, conteggio montati, conteggio Docker in esecuzione
• Informazioni dettagliate per repository

Usa --output json per un output leggibile dalla macchina.

Test della Connessione

Solo adapter cloud. Con l’adapter locale, usa rdc term connect -m server-1 -c "hostname" per verificare la connettività.

Verifica la connettività SSH a una macchina:

rdc machine test-connection --ip 203.0.113.50 --user deploy

Riporta:

• Stato della connessione (successo/fallito)
• Metodo di autenticazione utilizzato
• Configurazione della chiave SSH
• Stato del deployment della chiave pubblica
• Voce known hosts

Opzioni:

• --port <number>, Porta SSH (predefinito: 22)
• --save -m server-1, Salva la chiave host verificata nella configurazione della macchina

Diagnostiche (doctor)

Esegui un controllo diagnostico completo dell’ambiente Rediacc:

rdc doctor

Categoria	Controlli
Ambiente	Versione Node.js, versione CLI, modalità SEA, installazione Go, disponibilità Docker
Renet	Posizione del binario, versione, CRIU, rsync, asset embedded SEA
Configurazione	Configurazione attiva, adapter, macchine, chiave SSH
Virtualizzazione	Verifica se il tuo sistema può eseguire macchine virtuali locali (rdc ops)

Ogni controllo riporta OK, Avviso o Errore. Usalo come primo passo nella risoluzione di qualsiasi problema.

Codici di uscita: 0 = tutto superato, 1 = avvisi, 2 = errori.

Verifica della disponibilità dei servizi

Durante repo up, renet attende che i servizi HTTP accettino connessioni prima di dichiararli pronti. L’attesa tiene conto dei health check:

• I container che Docker segnala come sani vengono considerati pronti immediatamente, senza alcuna sonda TCP.
• I container ancora nel start_period del health check generano una nota informativa, non un avviso; il proxy continua a riprovare finché non si mettono in ascolto.
• I servizi Compose privi di container in esecuzione (ad esempio perché associati a un profilo inattivo) vengono saltati.
• Tutto il resto viene sondato via TCP per un massimo di 15 secondi (modifica questo valore impostando REDIACC_READINESS_TIMEOUT, in secondi).

Definire un Docker health check sui servizi a avvio lento fornisce a renet un segnale di disponibilità autorevole ed elimina il rumore delle sonde dall’output del deploy.