Il log di esecuzione risponde a quasi tutte le domande, ma non alla più fastidiosa: perché uno step non ha prodotto niente. In FortiSOAR «non partito» è un insieme di casi diversi, e ciascuno si diagnostica in un posto diverso.

Completato, saltato, in attesa: leggere le icone

Nella sezione Steps del log ogni step porta un’icona di stato: spunta verde per completato, simbolo grigio per skipped, clessidra arancione per awaiting, croce rossa per failed. Uno step saltato non è uno step fallito, ed è la distinzione che risolve la maggior parte dei casi.

Uno step viene saltato quando la condizione when non è soddisfatta. La condizione, se usata senza loop, si applica a livello di step ed è la prima cosa valutata: se è falsa, lo step non viene eseguito affatto. Se invece la usi insieme a un loop for each, si applica dentro il ciclo, item per item, e il comportamento cambia completamente. La scheda Config dello step ti dice se when è presente, con valore true o false.

Un playbook in stato Awaiting non è bloccato: sta aspettando un input, un’approvazione o un task manuale, e la scheda Pending Inputs mostra cosa manca. Un playbook in Active o Incipient che non avanza è invece un problema di motore, e si guarda altrove.

⚠️ Dettaglio da ricordare per intero: i playbook fermi in Active o Incipient vengono terminati automaticamente al superamento dei limiti di tempo (CELERYD_TASK_SOFT_TIME_LIMIT e CELERYD_TASK_TIME_LIMIT in config.ini), mentre quelli in Awaiting vengono terminati dopo 7 giorni, valore regolato dal parametro WF_MAX_WAITING_DAYS. Sono due meccanismi distinti con due parametri distinti. Per i playbook terminati, il pulsante Error Details riporta la ragione della terminazione.

Quando il log dell’interfaccia non basta: i file giusti

Il log di esecuzione mostra il messaggio d’errore pulito, senza la traccia: la traccia è stata rimossa dall’interfaccia per ridurre il rumore, ma esiste ancora nei file di prodotto. Tutti i log stanno sotto /var/log/cyops, e sceglierne il file sbagliato è il modo più comune di concludere che «nei log non c’è niente».

/var/log/cyops/cyops-workflow/celeryd.log      runtime dei playbook
/var/log/cyops/cyops-workflow/sealab.log       framework dei playbook
/var/log/cyops/cyops-workflow/beat.log         scheduler
/var/log/cyops/cyops-workflow/uwsgi.log        playbook e connettori
/var/log/cyops/cyops-integrations/connectors.log    problemi dei connettori
/var/log/cyops/cyops-integrations/integrations.log  framework dei connettori
/var/log/cyops/cyops-api/prod.log              lato PHP e Content Hub
/var/log/cyops/cyops-search/falcon.log         indicizzazione e ricerca

La regola pratica: uno step di connettore che fallisce si indaga in connectors.log; un playbook che fallisce o si comporta male in celeryd.log. Sono le due destinazioni indicate esplicitamente per gli errori mostrati nel log di esecuzione.

I livelli disponibili nei file di log sono DEBUG, INFO, WARNING, ERROR e CRITICAL, e si alzano in tre punti differenti, ciascuno col proprio riavvio:

  • WORKFLOW_LOG_LEVEL in /opt/cyops-workflow/sealab/sealab/config.ini, poi riavvio di uwsgi.
  • connector_logger_level in /opt/cyops-integrations/integrations/configs/config.ini, poi riavvio di uwsgi.
  • CELERYD_LOG_LEVEL in /etc/celery/celeryd.conf, poi riavvio di celeryd.

🔴 Non confondere questi livelli con il livello INFO/DEBUG del singolo playbook: quello governa cosa finisce nel log di esecuzione visibile nell’interfaccia, questi governano i file di sistema. Sono due impostazioni indipendenti, e cambiarne una non cambia l’altra.

Stato dei servizi: chi esegue davvero il playbook

Se nessuno step parte, spesso il playbook non è mai stato preso in carico. Lo stato complessivo si chiede con csadm services --status, che colora di verde i servizi attivi e di rosso quelli fermi e mostra da quanto tempo ciascuno è attivo, informazione utilissima quando un servizio si riavvia in continuazione. Per il singolo servizio si usa systemctl status con il nome.

I servizi che contano per playbook e connettori sono pochi:

  • celeryd esegue i playbook in modo asincrono. Se è fermo, i playbook non partono e basta.
  • celerybeatd è lo scheduler: pianificazioni e ingestion programmate dipendono da lui.
  • uwsgi ospita il motore dei playbook e le integrazioni dei connettori.
  • rabbitmq-server è il broker delle code; fsr-workflow esegue il motore delle regole (fsr-workflow.log); fsr-api-consumer gestisce l’installazione dalla Content Hub.

La coda dei workflow e la priorità

Il controllo che chiude il cerchio è la profondità della coda dei workflow:

rabbitmqctl list_queues -p fsr-cluster

Il numero deve essere 0 o al massimo di due cifre. Se resta alto a lungo, il motore non sta reggendo il carico e va dimensionato o messo a punto, non riparato step per step. Ricorda infine la priorità di esecuzione: i task a priorità Low non vengono eseguiti finché ci sono task ad alta priorità in coda. Uno step che «non parte mai» in un sistema sotto ingestion massiva può essere semplicemente un playbook a bassa priorità in attesa di un worker libero.