Nel mondo del broadcast la continuità del servizio è tutto. Tra software di automazione (nel nostro caso RCS Zetta), flussi di streaming multimediali, protocolli di sincronizzazione oraria (PTP) e link di rete ridondati, i punti di blocco e potenziale fallimento sono innumerevoli.
Spesso le soluzioni di monitoraggio commerciali o open-source generiche (come Zabbix o Nagios) faticano ad integrarsi nativamente con le API specifiche dei software di automazione radiofonica o richiedono uno sforzo enorme di configurazione. Per questo motivo, ho deciso di sviluppare un sistema di monitoraggio radio tailor-made, cucito su misura per le esigenze infrastrutturali della nostra emittente.
In questo articolo vi racconto com’è strutturata questa architettura interna e quali problemi specifici del mondo broadcast va a risolvere.
L’architettura globale del sistema
Il sistema si basa su una combinazione snella ma robusta di Python per il backend e il recupero dati, SQLite come base dati leggera e performante, e PHP/JavaScript per l’interfaccia di controllo (Dashboard) e le API interne.
Ecco i tre macro-componenti dell’infrastruttura:
- I demoni di data gathering (Python): Script paralleli che girano in loop continuo per interrogare le macchine, i server di automazione e gli apparati di rete.
- Il cuore dati (SQLite & API PHP): Una base dati centralizzata che mantiene lo stato in tempo reale di ogni singola stazione, esposta verso l’esterno tramite un’API JSON (
api.php). - L’interfaccia di controllo e notifica: Una dashboard web interattiva per i tecnici e un Bot Telegram aziendale per l’allarmistica push istantanea.
1. Monitoraggio dei Playout e Automazione (RCS Zetta via SOAP)
Il cuore dello script statusfeed.py interroga costantemente le istanze del software di playout attraverso chiamate SOAP API dirette. Questo ci permette di estrarre metriche quali ad esempio:
- Stato del Playout: Capire se la stazione è in modalità Auto, Manual, LiveAssist o se è caduta in uno stato critico come PlayerOffline, Offline o ContentStoreOffline (mancanza di accesso all’archivio audio).
- Verifica del Sequencer e dei Sistemi “Ghost”: Nelle regie ridondate, il sistema rileva istantaneamente se il sequencer attivo è quello principale o se è subentrato il server “Ghost” di backup, notificando immediatamente il team tecnico del cambio di stato.
- Metadata Real-time: Estrazione del titolo e dell’artista in onda per validare che l’automazione stia effettivamente avanzando e non sia bloccata sullo stesso elemento.
2. Il flusso dei segnali e dello streaming
Non basta sapere che il software di playout stia girando; è fondamentale accertarsi che l’audio stia effettivamente raggiungendo i server di streaming.
L’API interna controlla i volumi dei flussi di streaming (Master e Split regionali). Se il volume di uno streaming scende sotto una soglia critica (es. -50 dB), il sistema fa scattare immediatamente un allarme di “silenzio” o “low audio”, differenziando un problema di rete da un problema di generazione del contenuto.
3. Monitoraggio infrastrutturale e PTP
Nelle architetture AoIP la sincronizzazione dei clock è fondamentale. Lo script montone.py si occupa di interrogare via HTTP/Statistic gli apparati di rete e di trasporto audio (DirectOut Montone).
- Sincronizzazione PTP (Precision Time Protocol): Controlla lo stato del PTP. Se un apparato perde lo stato di Slave (valore
8) o si sposta in modalità Faulty o Initializing, l’allarme scatta prima ancora che l’audio inizi a presentare click, pop o sganciamenti. - Monitoraggio del Traffico di Rete (NIC1 e NIC2): Analizza i flussi in bit/s sulle schede di rete ridondate. Sotto i 10.000 bit/s significa che una delle linee principali o di backup ha smesso di ricevere il flusso multicast AoIP.
4. Allarmistica intelligente e notifiche Telegram
La reattività in radio è tutto. Il sistema implementa un bot Telegram (bot.py) associato a un canale a cui è iscritto tutto l’ufficio tecnico.
- Notifiche push istantanee: Quando una stazione va in Ghost, perde il PTP, o sperimenta un low-volume sullo streaming, il sistema invia un alert formattato in HTML.
- Rientro allarmi automatico: Evita lo “spam” da allarmistica. Quando i parametri tornano nominali, viene inviato un messaggio di spunta verde (✅ Allarmi Rientrati).
- Interattività via chat: I tecnici possono interrogare il bot in qualsiasi momento usando comandi dedicati:
/listper vedere le stazioni monitorate./info [ID]per avere un report dettagliato dello stato operativo e del brano attualmente in onda su una specifica emittente./alarmsper un riepilogo al volo di tutte le anomalie attive sull’intera rete.
5. Dashboard web e storico log
Il sistema offre una dashboard web (index.php) responsive ottimizzata sia per i monitor di controllo del laboratorio sia per la visualizzazione su tablet o smartphone.
La pagina si aggiorna in tempo reale consumando i dati dell’API interna e mostra barre di progressione visive sull’avanzamento dei brani, badge colorati (Verde/Rosso) basati sulla severità degli allarmi e lo stato dei link di rete.
Ogni cambio di stato, anomalia o intervento viene inoltre storicizzato in file di log giornalieri in formato CSV, consentendo l’analisi post-evento per individuare guasti intermittenti o degradazioni ricorrenti delle linee.
Conclusioni: perché il custom vince nel broadcast
Questo progetto è la dimostrazione di come, a volte, investire del tempo nello sviluppo interno di piccoli script mirati sia infinitamente più efficiente rispetto all’adattamento forzato di mega-piattaforme di monitoraggio Enterprise.
Con poche centinaia di righe di codice Python e PHP, ho ottenuto un sistema che parla la lingua della nostra radio, conosce l’architettura dei nostri playout e intercetta le anomalie tipiche del broadcast prima ancora che abbiano un impatto sugli ascoltatori.