Quando è sicuro tenere sotto controllo un avviso di Immich e quando è il caso di fermarsi?
Un avviso di Immich è sicuro da monitorare quando è circoscritto, l’operazione interessata viene comunque completata, il lavoro utile prosegue e non ci sono prove di problemi al database, al filesystem, al punto di mount o alla memoria. Interrompi le nuove scritture quando lo stesso avviso si ripete insieme a operazioni non riuscite, spazio di archiviazione che scompare, terminazioni per OOM, errori di ripristino del database o un rapido peggioramento della pressione sulle risorse.
La parola “avviso” non è il criterio decisionale. Un messaggio di nuovo tentativo innocuo e un messaggio “spazio esaurito sul dispositivo” possono comparire entrambi durante un’importazione intensa, ma implicano rischi molto diversi. Registra il primo timestamp, l’operazione esatta, l’asset o il job interessato e lo stato dell’archiviazione e dei container prima di riavviare qualsiasi cosa.
Classifica l’avviso in base all’operazione che può interrompere
Inizia da un’azione concreta dell’utente: carica una foto di prova, apri un vecchio asset, esegui una ricerca o osserva il job in background che ha prodotto il messaggio. Confronta il timestamp dell’avviso con i log del server Immich, del servizio di machine learning, di PostgreSQL, del reverse proxy e dell’archiviazione. La domanda è se l’avviso appartenga a una richiesta completata correttamente, a una richiesta ritentata o a una scrittura non riuscita.
Una guida ai livelli di log è un buon punto di partenza: WARN indica comunemente una condizione imprevista che l’applicazione può comunque gestire, mentre ERROR segnala un’operazione non riuscita. La risoluzione dei problemi di Immich deve comunque associare quell’etichetta alla richiesta, al percorso di scrittura o alla dipendenza interessata prima di decidere se sia sicuro continuare a utilizzare il sistema.
Se la stessa azione riesce ripetutamente e il numero di avvisi smette di aumentare, classificalo come un caso da monitorare finché non emergono nuove prove. Registra la frequenza e il contesto normali, così potrai capire se una versione futura, una modifica a una libreria o un problema di capacità rende il messaggio più frequente. Un singolo messaggio isolato senza conseguenze visibili per l’utente non è un motivo sufficiente per ricostruire lo stack.
Il framework decisionale di ZimaSpace per riparare o ricostruire Immich applica lo stesso principio: conserva lo stato e diagnostica un problema localizzato prima di sostituire una distribuzione funzionante. Un avviso diventa più importante quando si estende oltre una singola operazione o ricompare dopo la riparazione della causa individuata.
Continua a monitorare finché l’avanzamento e lo stato restano normali
Un avviso da monitorare soltanto ha un comportamento stabile. La coda continua a ridursi dopo l’arresto dei nuovi arrivi, i nuovi tentativi alla fine riescono, le query al database restano normali, lo spazio libero rimane sopra la soglia operativa, i mount restano presenti e i container non accumulano riavvii. Il flusso di lavoro visibile all’utente dovrebbe rimanere entro i normali intervalli di latenza e di errore.
Verifica questo limite invece di darlo per scontato. Ripeti la stessa azione cinque volte, includendo un asset più vecchio e uno appena caricato, e confronta il numero di avvisi prima e dopo. Se un avviso compare una sola volta durante il caricamento del modello o un nuovo tentativo temporaneo di una dipendenza, ma i tentativi successivi vanno a buon fine, documentalo indicando la versione esatta e continua a osservarlo. Non disattivare o filtrare l’avviso finché non sai cosa significa. Silenziare una riga di log rumorosa elimina il tuo riferimento di base e può nascondere il passaggio da nuovi tentativi innocui a scritture non riuscite. Monitora durata, frequenza, errori correlati dei job e la risorsa indicata dal messaggio: queste dimensioni sono più utili dei soli livelli di gravità.
Interrompi le nuove scritture quando l’avviso raggiunge una soglia di sicurezza dei dati
Interrompi i caricamenti e i job in background quando gli avvisi indicano un filesystem pieno o in sola lettura, un mount previsto assente, errori ripetuti di ripristino o scrittura di PostgreSQL, terminazioni dei container per OOM o un servizio che si riavvia ripetutamente prima del completamento delle transazioni. Conserva i log e i percorsi dei dati attuali prima di liberare spazio o modificare la proprietà.
Un messaggio del database “spazio esaurito sul dispositivo” non è semplice rumore nei log. Una discussione su un problema di Immich ha associato un comportamento difettoso della timeline a errori di spazio di PostgreSQL durante una distribuzione problematica.
Il caso non stabilisce un’unica causa principale universale; mostra perché gli avvisi del database relativi all’archiviazione richiedano controlli immediati dell’ambito prima di accettare altre scritture.
Applica la stessa regola di arresto se l’host inizia a usare la memoria virtuale in modo incontrollato, se i file compaiono sotto un mount vuoto imprevisto o se i nuovi caricamenti finiscono nel layer scrivibile di un container perché l’archiviazione prevista non è stata montata. Continuare a scrivere può trasformare un problema di configurazione recuperabile in un problema di riconciliazione più ampio.
Applica una sola correzione reversibile e riproduci il fattore scatenante originale
Correggi soltanto la causa confermata: ripristina il mount previsto, aggiungi spazio libero in modo sicuro, riduci la concorrenza di un singolo job, correggi una dipendenza non funzionante o sistema un limite di autorizzazione. Non svuotare tutte le code, eliminare i file del database, rimuovere volumi Docker sconosciuti e aggiornare le versioni contemporaneamente: distruggeresti le prove necessarie per valutare il risultato.
Riavvia solo il servizio interessato, se necessario, quindi ripeti esattamente il fattore scatenante che ha prodotto l’avviso. Il test è superato quando l’azione dell’utente riesce, l’avviso scompare o torna alla frequenza innocua documentata, le code si svuotano, lo spazio di archiviazione e la memoria restano in condizioni normali e un secondo riavvio non ricrea il problema. Esci dalla fase di esperimenti e chiedi assistenza quando il messaggio persiste durante una riproduzione pulita, l’integrità del database è incerta, i file richiesti scompaiono o la prima riparazione sicura non ripristina il normale avanzamento. Fornisci le versioni esatte di Immich e PostgreSQL, i log con timestamp, lo stato del filesystem, lo stato dei riavvii e degli OOM dei container e una riproduzione minima, così il passaggio successivo potrà concentrarsi sul livello che presenta il problema.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
