La discussione della community IceWhale del 2023 su Uptime Kuma è più un'introduzione che una guida all'installazione. Il post afferma che il tutorial tratta l'installazione su CasaOS, mentre le risposte si concentrano sui motivi per cui gli utenti apprezzano Uptime Kuma: notifiche di interruzione, monitoraggio in produzione per servizi non critici e monitor push. Il testo del forum non conserva la configurazione dettagliata dell'installazione passo dopo passo.
Una pagina aggiornata dovrebbe quindi mantenere il contesto CasaOS e i casi d'uso della community, utilizzando però i requisiti Docker aggiornati e gestiti di Uptime Kuma per la distribuzione effettiva.
Cosa aggiunge Uptime Kuma a un server domestico
Uptime Kuma è una dashboard di monitoraggio self-hosted. Può verificare lo stato di un sito web, di un servizio TCP, di un endpoint DNS, di una destinazione ping, di un servizio correlato a Docker o di un'attività basata su push, oltre a inviare notifiche quando lo stato cambia.
Le risposte originali sottolineavano ripetutamente il valore pratico delle notifiche. Una dashboard è utile, ma il vantaggio principale è scoprire che un servizio è inattivo prima che qualcuno in casa lo segnali.
Usa il container Uptime Kuma attuale
Le istruzioni attuali per la distribuzione di Uptime Kuma utilizzano l'immagine gestita louislam/uptime-kuma:2. L'applicazione web ascolta sulla porta 3001 e salva il database persistente e la configurazione in /app/data.
Per un'applicazione personalizzata attuale in CasaOS, traduci le impostazioni Docker gestite di Uptime Kuma nel modulo dell'app CasaOS, invece di usare un vecchio tag dell'immagine tratto da un video del 2023.
Esponi la dashboard sulla porta 3001
Il servizio web all'interno del container utilizza la porta TCP 3001. Se quella porta sull'host è già occupata, associa un'altra porta dell'host alla porta 3001 del container e apri l'app CasaOS tramite la porta scelta sull'host.
La modifica della porta sull'host non richiede di cambiare la porta interna di Uptime Kuma, a meno che l'applicazione upstream non supporti esplicitamente tale modifica e non sia necessario effettuarla.
Rendi persistente /app/data
Associa una cartella dell'host CasaOS o un volume Docker a /app/data. Questo è il principale elemento da includere nei backup, perché contiene la configurazione del monitoraggio, i dati utente e il database SQLite.
Ricreare il container senza quel volume persistente farà sì che si comporti come una nuova installazione di Uptime Kuma.
Mantieni il database su un filesystem con blocchi affidabili
Le indicazioni attuali di Uptime Kuma avvertono che il database SQLite richiede un blocco affidabile dei file POSIX e mettono specificamente in guardia da filesystem come molte configurazioni NFS per la directory dei dati.
Per un server domestico, mantenere /app/data sull'archiviazione locale è la scelta più semplice. Puoi quindi eseguire il backup di quella directory su un altro disco o su una destinazione remota.
Scegli monitor adatti all'esperienza dell'utente
Un monitor ping dimostra soltanto che una macchina risponde a ICMP. Se il requisito reale è “Jellyfin deve caricarsi”, un monitor HTTP per l'endpoint di Jellyfin è più significativo.
Un insieme pratico può includere:
- controlli HTTP per le applicazioni web;
- controlli TCP per i servizi privi di un endpoint web utile;
- controlli DNS per Pi-hole o AdGuard Home;
- controlli ping per verificare la raggiungibilità di base dell'host;
- monitor push per le attività pianificate che devono segnalare il completamento.
Perché è importante il monitor push menzionato nella discussione
Un partecipante della community ha dichiarato di utilizzare spesso i monitor push. Invece di eseguire il polling di un servizio da parte di Uptime Kuma, uno script di backup o un'attività pianificata chiama un URL univoco quando viene completata correttamente. Se quel segnale non arriva entro l'intervallo previsto, Uptime Kuma contrassegna il monitor come non funzionante.
È utile per le attività in cui “il server è online” non dimostra che il processo sia stato effettivamente eseguito.
Testa le notifiche prima della prima interruzione
Configura almeno un canale di notifica e attiva deliberatamente un avviso di prova. Un sistema di monitoraggio che non riesce silenziosamente a inviare notifiche è soltanto una dashboard storica.
Per i servizi domestici, considera anche l'affaticamento da notifiche. Monitorare ogni endpoint minore con notifiche immediate può rendere più facile ignorare le vere interruzioni.
Mantieni privata la dashboard di monitoraggio, salvo accesso remoto intenzionale
Uptime Kuma può rivelare nomi host interni, nomi dei servizi, indirizzi di rete e cronologia delle interruzioni. Non esporlo direttamente su Internet semplicemente perché il monitoraggio remoto è utile. Se è necessario l'accesso remoto, utilizza una VPN, una rete overlay privata o un proxy inverso autenticato.
Non considerare la discussione CasaOS del 2023 come un riferimento di versione attuale
La discussione originale elogia un'applicazione ben gestita, ma non conserva una versione dell'immagine. Questo è un vantaggio: utilizza la versione upstream attuale invece di cercare di ricreare esattamente il container esistente a settembre 2023.
Domande frequenti su Uptime Kuma in CasaOS
Quale porta utilizza la versione attuale di Uptime Kuma?
La porta 3001 per l'interfaccia web.
Quale directory deve essere persistente?
/app/data.
Perché la directory dei dati dovrebbe rimanere nell'archiviazione locale?
Il database SQLite richiede un blocco affidabile dei file e le indicazioni upstream attuali mettono in guardia dai filesystem di rete non adatti.
A cosa attribuiva maggior valore la community originale?
Le notifiche e le funzionalità dei monitor push sono state sottolineate ripetutamente nelle risposte.
