Quartz 4

FIRE 75.16 PAD Analisi del log di avvio

4 min read

Analisi del Log di Avvio

Possiamo raggruppare i messaggi in quattro categorie principali:

Gruppo 1: Log di Avvio di FIRE (Il “Happy Path”)

Questi sono i nostri messaggi, formattati correttamente, che descrivono la sequenza di avvio.

10:01:51 - INFO     - (root) - Avvio di FIRE v0.10.6...
10:01:51 - INFO     - (fire.workers.initialization_worker) - Avvio del processo di inizializzazione...
10:01:51 - INFO     - (fire.workers.initialization_worker) - Caricamento Analytics Core...
... (e tutti gli altri log che iniziano con 'fire.') ...
  • Cosa Sono: Sono i log che abbiamo implementato noi stessi. Mostrano che il nostro sistema di logging (setup_logging in main.py) funziona e che l’InitializationWorker sta eseguendo correttamente i suoi passaggi: caricamento indicatori, inizializzazione del DataManager, verifica della connessione AI.
  • Diagnosi: Sano. Questi log sono informativi, ben formattati e utili.

Gruppo 2: Log di Librerie Esterne (Il “Rumore Verboso”)

Questi sono messaggi di livello DEBUG provenienti da librerie di terze parti che usiamo.

10:01:51 - DEBUG    - (openai._base_client) - Request options: {...}
10:01:51 - DEBUG    - (httpcore.connection) - connect_tcp.started host='localhost' ...
...
10:02:25 - DEBUG    - (matplotlib.font_manager) - findfont: Matching sans-serif...
... (e le centinaia di righe di matplotlib) ...
  • Cosa Sono:
    • I log di openai e httpcore mostrano i dettagli di basso livello della richiesta HTTP inviata per verificare la connessione al server AI.
    • I log di matplotlib sono generati la prima volta che la libreria viene usata in una sessione; sta scansionando il sistema alla ricerca di font disponibili.
  • Diagnosi: Rumore, ma non un errore. Questi log sono utili solo per un debugging molto specifico (es. problemi di rete o di font). Per l’avvio normale, inquinano il terminale e nascondono i messaggi importanti. La nostra configurazione di logging di default (level=logging.DEBUG) sta facendo emergere anche i loro messaggi di debug.

Gruppo 3: Messaggi non Standardizzati (Il “Technical Debt”)

Questi sono messaggi che non seguono il nostro formato standard TIMESTAMP - LEVEL - (SOURCE).

INFO: YahooFinanceConnector inizializzato con una sessione 'requests' custom.
Discovered 2 total data connectors: ['LocalCSV', 'YahooFinance']
Data connectors reloaded. Active and ordered: ['LocalCSV', 'YahooFinance']
WorkerManager initialized with a thread pool supporting up to 24 threads.
[DEBUG][PromptManager] Caricato prompt 'pine_script_converter_v1'.
  • Cosa Sono: Questi sono quasi certamente il risultato di print() sparsi nel codice o di istanze di logger configurate in modo indipendente che non usano il nostro handler centrale. Rompono la coerenza del log e sono un chiaro segno di “technical debt”.
  • Diagnosi: Code Smell / Problema di Qualità. Anche se non sono errori, vanno corretti per mantenere il nostro codebase pulito e professionale.

Gruppo 4: Warning Critici di Esecuzione (Il “Vero Problema”)

Questi sono i messaggi più preoccupanti.

D:\...\pyqtgraph\graphicsItems\GraphicsItem.py:500: RuntimeWarning: Failed to disconnect (...) from signal "sigRangeChanged(PyObject,PyObject)".
  getattr(oldView, signal).disconnect(slot)
... (e gli altri 5 warning simili da pyqtgraph) ...
  • Cosa Sono: pyqtgraph ci sta avvisando che sta tentando di disconnettere un segnale da uno slot ma non ci riesce. Questo di solito accade quando si gestisce il ciclo di vita dei componenti di un grafico (es. aggiungendo/rimuovendo linee o dati). L’oggetto potrebbe essere già stato eliminato, o la connessione non è mai esistita.
  • Diagnosi: Problema ad Alta Priorità. Anche se sono “solo” warning e non crash, i RuntimeWarning in una libreria grafica sono spesso sintomo di una gestione errata della memoria o dello stato. Possono portare a memory leak, comportamenti imprevedibili o crash futuri. È probabile che questo accada quando puliamo o aggiorniamo i nostri grafici.

Piano d’Azione Proposto

Abbiamo identificato chiaramente i problemi. Propongo di affrontarli in ordine di gravità.

  1. Priorità Alta (Azione Immediata): Investigare i RuntimeWarning di pyqtgraph. Questo è il problema più serio. Dobbiamo capire quale azione nell’UI scatena questi warning (probabilmente “Load Chart” o il completamento di un backtest) e correggere il modo in cui gestiamo il ciclo di vita dei PlotDataItem.

  2. Priorità Media (Pulizia): Eliminare i messaggi non standardizzati. Dobbiamo fare una ricerca nel codebase per trovare i print() e i logger mal configurati e sostituirli con chiamate al nostro AppState.log() o a un logger standard (logging.getLogger(__name__)).

  3. Priorità Bassa (Qualità della Vita): Silenziare i log delle librerie esterne. Modificheremo la nostra setup_logging per impostare il livello di log di librerie “rumorose” come matplotlib e openai a INFO o WARNING, in modo che i loro messaggi di DEBUG non appaiano più nel nostro terminale.

Questo piano ci permetterà di rendere il nostro log di avvio pulito, leggibile e, soprattutto, privo di warning critici.

Quale di questi problemi vuoi affrontare per primo? Suggerisco di iniziare dal più grave, i warning di pyqtgraph.

Graph View