Reindex, cron e code: la manutenzione che tiene su un Adobe Commerce

Nel corso degli anni, gestendo installazioni Adobe Commerce di dimensioni molto diverse, mi sono accorto di una cosa: quasi nessuno racconta la manutenzione ordinaria. Si parla di feature, di checkout, di headless, di roadmap. Poi arriva il picco di traffico e il negozio si inginocchia perché un consumer era fermo da tre giorni e nessuno se n’era accorto. La verità è che un Adobe Commerce non “va da solo”: va tenuto. E la parte che lo tiene in piedi è fatta di indexer, cron job, message queue, log e disco. Roba invisibile finché non si rompe.

Voglio raccontare cosa guardo davvero, con che frequenza, e perché. Niente teoria: il mestiere di chi manda avanti la piattaforma dopo il go-live.

Gli indexer: update on schedule è la scelta giusta, ma va sorvegliata

Il primo pezzo che controllo sono sempre gli indexer. Su Adobe Commerce la modalità che uso di default in produzione è update on schedule: gli indici non si ricostruiscono al salvataggio, ma vengono aggiornati in modo incrementale dai mview via cron. È la scelta corretta per un catalogo che cambia spesso, perché evita che un import di prezzi mandi in “reindex required” tutto il negozio nel momento sbagliato.

Il problema è che update on schedule funziona solo se il cron gira e se le changelog table non si intasano. Ho visto più di una volta un indexer bloccato in stato invalid perché una tabella _cl era cresciuta a milioni di righe: qualcuno aveva fatto un update massivo via SQL bypassando il modello, i trigger non erano allineati, e da lì in poi le modifiche a catalogo non si vedevano più sul front-end. Nessun errore a schermo. Solo prezzi vecchi in vetrina.

Cosa faccio, in concreto: controllo lo stato con bin/magento indexer:status, tengo d’occhio la dimensione delle changelog table, e quando vedo un indexer che resta invalid troppo a lungo non mi limito a un reindex — vado a capire perché. Un reindex a mano è un cerotto, non una diagnosi.

Il cron è il cuore: se muore, muore tutto in silenzio

Se dovessi indicare l’unico componente che genera più incidenti “misteriosi” su Adobe Commerce, direi senza esitazione il cron. Reindex incrementale, invio email, generazione sitemap, pulizia sessioni, scheduling dei prezzi, consumer delle code: passa quasi tutto da lì. Quando il cron si ferma, il negozio continua a servire pagine — sembra sano — ma sotto non aggiorna più niente.

La mia regola è netta: il crontab di Magento deve contenere una sola riga di sistema che invoca bin/magento cron:run, e da lì il resto è gestito internamente dai gruppi. Doppie configurazioni, cron duplicati su più nodi senza lock, o peggio il cron lanciato come utente sbagliato che poi scrive file di cache come root: sono tre classici che mi capita ancora di ripulire su installazioni ereditate.

Controllo settimanalmente due cose. La prima: la tabella cron_schedule, per vedere se i job passano da pending a success o restano appesi. Se trovo una colonna piena di missed, il cron non gira abbastanza spesso o va troppo lento. La seconda: che non ci siano job accavallati per mancanza di lock. Un cron:run che parte prima che il precedente abbia finito, su un catalogo grosso, è la ricetta perfetta per il degrado progressivo.

Message queue e consumer: la parte che quasi nessuno monitora

Da quando Adobe Commerce ha spostato sempre più lavoro su message queue — asynchronous bulk operations, aggiornamenti async degli indici, export, integrazioni — i consumer sono diventati un punto critico che troppi team non guardano proprio.

Il concetto è semplice: i consumer sono processi che pescano i messaggi dalla coda (RabbitMQ o la queue su MySQL) e li elaborano. Se un consumer è fermo, i messaggi si accumulano e non succede nulla di visibile finché la coda non esplode. Mi è capitato di trovare centinaia di migliaia di messaggi in attesa perché un consumers_runner non veniva più rilanciato dal cron dopo un deploy fatto male.

La mia posizione, maturata sul campo, è che in produzione i consumer vanno gestiti da un supervisor (systemd o Supervisor), non lasciati al solo consumers_runner del cron. Con --max-messages impostato, un processo che muore viene fatto ripartire subito, e non ti ritrovi la coda in overflow il venerdì sera. Settimanalmente controllo la profondità delle code: se un numero cresce e non torna mai giù, ho un consumer morto o un messaggio “avvelenato” che va isolato.

Log e disco: il killer più stupido e più frequente

Lo dico senza giri di parole: la causa più banale e più frequente di down su Adobe Commerce che ho visto è il disco pieno. Non un bug esotico. Il disco pieno.

Adobe Commerce scrive parecchio: var/log, i report in var/report, la cache, le sessioni se sono su file, e soprattutto debug.log lasciato acceso in produzione. Aggiungi tabelle di log a database che non vengono mai svuotate — la report_event, le *_log dei visitor, la session se sta su MySQL — e nel giro di qualche mese hai un database gonfio e un filesystem che si riempie.

Le cose che verifico con regolarità: che debug.log sia spento in production, che la log rotation sia configurata a livello di sistema (non lasciata a Magento), e che i job di log cleaning del database siano attivi. Guardo la crescita di var/ e delle tabelle di log come si guarda la febbre: non il valore assoluto, la tendenza. Un disco che passa dal 60% al 75% in una settimana mi dice più di qualsiasi alert a soglia fissa.

Cache warming: utile, ma non è un sostituto della salute della cache

Sul cache warming ho un’opinione un po’ controcorrente. È utile — soprattutto dopo un deploy, quando la full page cache è vuota e le prime richieste “reali” pagherebbero il prezzo pieno di rigenerare le pagine. Un crawler che scalda le pagine più visitate prima di aprire il traffico ha senso.

Ma il cache warming non deve diventare la stampella che nasconde una cache mal configurata. Se ti serve scaldare tutto il catalogo di continuo per stare in piedi, il problema vero è altrove: Varnish non è configurato bene, ci sono blocchi non cacheable che bucano la full page cache, oppure Redis è sottodimensionato e sta facendo eviction. Il warming lo uso come rifinitura dopo il deploy, non come terapia intensiva permanente. Prima sistemo l’hit ratio, poi eventualmente scaldo.

La mia checklist settimanale

Ridotta all’osso, ogni settimana su un’installazione in salute guardo:

• Indexer: nessuno bloccato in invalid, changelog table sotto controllo.
• Cron: cron_schedule senza raffiche di missed, nessun job accavallato.
• Consumer / code: profondità delle code stabile, nessun accumulo che non rientra.
• Disco e log: trend di occupazione, debug.log spento, rotation attiva.
• Cache: hit ratio di Varnish e stato di Redis, warming solo dove serve.

Sono cinque controlli, dieci minuti se hai il monitoring giusto. La differenza tra chi li fa e chi non li fa non si vede il martedì mattina. Si vede il giorno del picco, quando uno arriva riposato e l’altro arriva rotto. E su Adobe Commerce, il giorno del picco, non c’è deploy dell’ultimo minuto che ti salvi: o la manutenzione ordinaria l’hai fatta prima, o la paghi in tempo reale davanti ai clienti.

Mini-FAQ

Meglio update on schedule o update on save per gli indexer?
In produzione, per un catalogo che cambia spesso, uso update on schedule: aggiorna gli indici in modo incrementale via cron ed evita reindex pesanti nei momenti sbagliati. Update on save ha senso solo su ambienti piccoli o di sviluppo.

Ogni quanto va controllato il cron di Adobe Commerce?
Almeno una volta a settimana verifico la tabella cron_schedule. Se compaiono molti job in stato missed, il cron non gira abbastanza spesso o è troppo lento e va indagato subito, prima che si accumulino ritardi su indici ed email.

Perché i consumer delle message queue sono critici?
Perché elaborano operazioni asincrone (bulk, indici async, integrazioni) senza dare segnali visibili sul front-end. Se un consumer è fermo, le code crescono in silenzio. In produzione li gestisco con un supervisor, non solo con il consumers_runner del cron.

Qual è la causa più frequente di down su Adobe Commerce?
Nella mia esperienza, il disco pieno: debug.log acceso in production, log non ruotati e tabelle di log a database mai svuotate. Banale e frequentissimo. Si previene con log rotation di sistema e job di log cleaning attivi.

Fabio Canovi — Esperto di Magento e Adobe Commerce. Tra i primi in Italia ad aver ottenuto la certificazione Adobe Commerce, progetto e gestisco piattaforme e-commerce enterprise dal 2011, quando ho iniziato a lavorare su Magento 1.