Monitorare l'avanzamento del programma su più server


9

Abbiamo tre server che eseguono programmi Python che eseguono attività di analisi dei dati all'interno di una tmuxsessione. Il metodo che stiamo usando al momento è quello di inserire ognuno di essi collegando la tmuxsessione e guardando l'output sulla riga di comando.

Questo metodo è noioso, quindi quello che stiamo cercando è una soluzione che automatizzi il monitoraggio dell'avanzamento del programma (output su CLI) per più server contemporaneamente. Idealmente vorremmo una soluzione di interfaccia utente Web ma una CLI sarebbe anche perfettamente adatta.

Grazie per aver letto.


Risposte:


8

Ogni volta che si eseguono comandi ad hoc di lunga durata, è necessario tornare indietro e ripensare il processo, poiché dovrebbe essere automatizzato, inclusa la gestione degli errori.

Invece di connettersi ai server per vedere lo stato, un approccio migliore è quello di estromettere tali informazioni. Puoi fare una grande varietà di cose se vuoi scrivere un sacco di codice personalizzato, ma la cosa più semplice è probabilmente iniziare a inviare l'output tramite syslog a un sistema di registrazione centralizzato (syslog stesso o ELK o qualsiasi altra cosa). In questo modo puoi monitorare tutto da una posizione centrale.

In prospettiva, se questo non è un compito unico, il monitoraggio dovrebbe essere automatizzato. Cioè, non dovresti mai solo guardare i registri per vedere se le cose stanno procedendo come dovrebbero. Invece, dovresti supporre che lo siano (e continuare con altri lavori) fino a quando il tuo avviso non si attiva . Si tratta di un investimento di tempo per ottenere avvisi affidabili e ad ampia copertura, ma man mano che i sistemi crescono in complessità, pagheranno poiché non è necessario monitorare tutto ogni volta che si cambia qualcosa .


Questa non è una cosa una tantum. Mi piace la tua idea di investire tempo nell'automazione del monitoraggio e della centralizzazione della registrazione. Hai qualche suggerimento per strumenti che sono liberi di usare e che funzionano bene con gli host Ubuntu che eseguono i programmi?
guano,

@guano Penso che Wissam abbia coperto tutti gli strumenti specifici che vorrei menzionare, oltre a usare qualcosa come Sensu per alimentare l'avviso.
Boicottaggio SE per Monica Cellio,

4

Graylog

Dato che due persone ti hanno già consigliato di ripensare il tuo processo attuale (che secondo io ti causerà notti insonni ad un certo punto;)), seguirò un altro percorso e ti consiglierò un software specifico che, a mio avviso, si adatta alla maggior parte di le tue esigenze: Graylog .

Ho implementato e usato un paio di stack ELK sia per l'aggregazione dei log che per la business intelligence e ho anche gestito / mantenuto graylog per circa due anni presso il mio attuale datore di lavoro. Raccomando graylog in quanto ha le seguenti funzionalità integrate ed è - a mio avviso - un po 'più facile da configurare e mantenere:

  • Un'interfaccia web
  • Funzionalità multiutente
  • alerting

Per quanto ho capito il tuo scenario, sembra che tu debba agire o essere avvisato su determinati eventi che compaiono nel tuo flusso di messaggi di log. Se osserviamo le funzionalità di Graylog :

Attiva azioni o ricevi notifiche quando qualcosa richiede attenzione, come tentativi di accesso non riusciti, eccezioni o degrado delle prestazioni.

Idee: invia un'e-mail o un messaggio lento al tuo team. Genera una nuova macchina per bilanciare il carico di elaborazione. Blocca automaticamente gli intervalli IP nei firewall quando viene rilevato un attacco.

Per provare graylog, consiglierei i seguenti due passaggi:

  • Configurare un host dedicato che è raggiungibile da tutti gli host dell'applicazione per eseguire graylog (e le sue dipendenze MongoDB ed ElasticSearch)
  • Invia registri dalla tua applicazione a graylog (possibilmente come messaggi GELF )

Nota: questi due passaggi hanno la capacità di riempire pagine e pagine delle migliori pratiche e dovrebbero ricevere almeno un paio di pensieri. Per non parlare del fatto che graylog non è una soluzione di monitoraggio e graylog stesso dovrebbe essere monitorato da un adeguato strumento di monitoraggio (come ad esempio Icinga, Prometheus, Nagios per citarne solo alcuni).


3

Sono d'accordo con @Xiong Chiamiov e voglio dare un'opzione più chiara. Se si desidera monitorare ogni riga della CLI, suggerirei di reindirizzare tutto l'output su un file specifico e l'errore su un altro file, quindi utilizzare logstash o filebeat per inviare entrambi questi file a Elasticsearch , quindi è possibile configurare Logtril con Kibana ti offre la visualizzazione, l'analisi, la ricerca e la registrazione degli eventi di coda da più host in tempo reale con l'interfaccia amichevole di Devops


1

centralizzata tmux

Mentre le altre risposte sono più intelligenti e più sagge a lungo termine, penso che la soluzione CLI hacky veloce meriti di essere menzionata. Esegui tmuxsu un server che può raggiungere tutti gli altri. Un buon posto per questo sarebbe una jump box o qualche altro posto in cui le persone sono comunemente registrate comunque. All'interno di questo "centrale" tmuxssh per ogni casella in un riquadro diverso e coda qualunque file di registro sia necessario. Puoi usare ctrl- b "per ottenere più riquadri in una scheda all'interno tmux. Ora tutto ciò che qualcuno deve fare per controllare le cose è allegato alla tmuxsessione "centrale" e possono vedere l'intero cluster a colpo d'occhio.

Ho trascorso molto tempo a costruire le soluzioni di interfaccia utente Web a cui stai lavorando, ma se ne hai bisogno oggi hackerando qualcosa con cui tmuxpuoi salvare la giornata.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.