La migliore strategia di comunicazione per il dashboard di monitoraggio

Questa risposta rientrerà nella categoria di "suggerire una strategia migliore".

La raccolta di statistiche sui beni infrastrutturali (non solo sui server) è ciò che sto facendo attualmente per vivere in un leader globale dei servizi finanziari. Sto cercando di capire perché si dovrebbe evitare l'uso di un database per contenere i bit che vengono raccolti. Se il costo è un problema, ci sono soluzioni open source fantastiche. Se la dimensione dell'app è un problema, utilizzare un DB leggero o incorporato. Mentre quello che descrivi può essere fatto senza un DB, richiederà la ricreazione di molte ruote. Anche se lo giustifica e lo fai, e rilasci il tuo prodotto non ci vorrà molto perché i tuoi clienti desiderino vedere le statistiche in un contesto storico, o vogliono rendere queste statistiche disponibili per il consumo con altri mezzi / app. Se non si è in grado di farlo, limiterà gravemente l'utilità aziendale di ciò che si sta creando.

In termini di architettura client / server per trasferire le statistiche dal collector al tuo ricevitore, codificando che usando il TCP nativo (usando i socket che presumo) al minimo dovrai escogitare un protocollo per l'impostazione e il trasferimento della sessione i dati e dovrai codificare un gestore connessioni che ascolta le connessioni in entrata e avvia un thread di gestione (in modo che la tua app possa supportare connessioni simultanee dai client di raccolta).

Tutto ciò viene gestito sfruttando un contenitore webapp come tomcat o wildfly. Creando una webapp su un contenitore puoi anche sfruttare framework / librerie in modo che ciò che sviluppi sia fornito con un'API SOAP senza un sacco di ulteriore lavoro di sviluppo da parte tua.

Se si tratta di un esercizio accademico, l'approccio dell'uso della programmazione TCP di basso livello ha senso.

Vorrei utilizzare uno dei nostri progetti di successo come esempio. Sentilo

Sentilo è (in fondo) un concentratore di dati che memorizza milioni di voci da qualsiasi tipo di sensore, gadget o client. Memorizza i dati in noSql db e il modo per farlo è tramite webservices riposanti e senza stato. Che accetta json come rappresentazione dei dati.

Quindi offre anche servizi web per servire questi dati.

Che cosa hai in comune con Sentilo?

Sei connesso a tutti quei server che devi monitorare. Buono. Il tuo server sarà il gadget . Hai anche creato uno script di shell che eseguirà il compito di ottenere i dati.

Ecco la nuova parte.

Al posto delle chiamate remote, pianifica queste chiamate. Ogni 2,5,10 secondi. Script riceverà la risposta e la reindirizzerà a un URL vía curl.

Questo URL sarà il tuo concentratore . Concentrator è abbastanza facile da costruire con NodeJs e MongoDB (o Redis). Questo concentratore ha anche un URL per servire tutte queste informazioni. Ma serve i dati da db non i dati grezzi dallo script.

Con NodeJs analizzare i dati grezzi degli script sarà anche facile.

Infine i tuoi attuali servizi web Java consumano dati dal concentratore (o direttamente dal noSql db).

Andrò anche oltre. Elimina il tuo server web Java e lascia che Angular consumi i dati dal tuo concentratore. La disponibilità di NodeJs è decisamente superiore rispetto ai server di app Java. E più veloce. E supporta più richieste e concorrenza rispetto a qualsiasi app server Java.

Se non ti piacciono gli script di shell. Da NodeJs puoi eseguire comandi di shell, fare ping, richieste http / s, connessioni socket, client di servizi web di sapone, connessioni ssh, ecc ...

Questo sarebbe il mio approccio. Ecco alcuni link che possono aiutare a investigare

1. NodeJs : il nocciolo del mio approccio
2. Restify : modulo NodeJs per impostare server Web e URI di riposo
3. MongoDb : repository dati noSql
4. NPM : Repository di moduli NodeJs e altre librerie Javascript. È per NodeJs ciò che Nexus è per Java
5. Bower : gestore delle dipendenze di Javascript.
. È per qualsiasi progetto Javascript ciò che Maven è per Java

Alcuni moduli che ti interessano:

• socket.io
• node-schedule

Onestamente, questo suona molto simile a un aggregatore di registri, di cui esistono molte opzioni esistenti. Probabilmente la migliore versione open source è lo stack ELK (Elastic Search - Logstash - Kibana), che ti offre l'intera gamma di visualizzazioni di raccolta, indicizzazione e alta qualità (che puoi personalizzare).

Nel tuo caso, sarebbe una soluzione piuttosto facile. Entrambi i server che stai monitorando mettono tutti i loro dati di stato nei loro registri normali (con logrotate configurato, ecc.) E poi usano Filebeat per inviarlo periodicamente allo stack ELK, o trovare un connettore personalizzato per spingere i dati nell'infrastruttura ELK, a tua scelta.

In ogni caso, tutto ciò che hai descritto può essere fatto praticamente senza codice, solo configurazione e configurazione. Nel peggiore dei casi, potresti scrivere la tua app Java + Angular per estrarre le informazioni da ElasticSearch e fare tutto ciò che vuoi, se scopri che Kibana non è in grado di fornire la dashboard desiderata.