Il miglior approccio per una raccolta dati di configurazione del server e una soluzione di reporting da uno script legacy?

Naviga le tue risposte
2

Ho un progetto che implica la raccolta di dati di configurazione da server Windows nel nostro (molto grande) parco server. Il mio manager desidera che raccolga oltre 150 articoli di dati in tutte le aree di configurazione, inclusi dati di configurazione della rete, dischi, valori di registro, versione del BIOS, versioni di dll. Il team di supporto del server attualmente usa un brutto script vbScript che è massiccio, disordinato e che è stato distribuito e cresciuto in modo organico nel tempo. Lo script è attualmente utilizzato per raccogliere i dati e produrre un report HTML piatto di base con una colonna per ciascuno degli oltre 150 articoli per i quali raccoglie i dati. Il mio compito è trasformarlo in una soluzione software adeguata con nuovi campanelli, un sito Web, rapporti, ecc.

L'idea è che un amministratore di sistema andrà su un sito intranet, inserirà il nome del server e preme il pulsante Vai, la soluzione raccoglie i dati e li inserisce nel DB per i rapporti successivi.

Il mio manager vuole che la soluzione raccolga i dati, alcuni dei quali fanno riferimento a valori desiderati noti (es. driver della scheda RAID per i server modello ABC è alla v1.2.5.1) per vedere se sono corretti o aggiornati, memorizzarli in un database SQL e quindi utilizzare il sito Web front-end per la produzione di report. Nei rapporti, vuole che sia in grado di confrontare due dataset; ad esempio, uno per il server ABC123 e uno per il server DEF987 in un rapporto, evidenziando eventuali differenze tra i due.

Diventa caotico molto rapidamente poiché alcuni dati verranno raccolti su alcuni server ma non su altri (i controller di dominio non avranno dati raccolti sullo stato di esecuzione dei servizi di scambio). Ci sono molti oggetti vari che non si adattano a un'area del modello di dati e non hanno una casa ... è un disastro.

Sto bene con la raccolta dei dati (usando .Net), ma non riesco a capire dove il posto migliore sia fare cose come memorizzare e cercare / confrontare gli articoli con valori noti (XML, DB ?). Dovrei farlo come parte della fase di raccolta dei dati e poi spingerlo nel DB. O dovrei sposare tutto come parte dei dati dei rapporti?

Vado con uno schema di data warehouse (de-normalizzato) per il DB. Ci saranno probabilmente circa 20 tabelle da cui i dati dovranno essere estratti, quindi non ho idea di quale sia il modo migliore per confrontare il set di dati da una raccolta di dati del server, con un altro, con un insieme così grande di campi da confrontare.

Cosa pensate che le mie migliori opzioni siano per avvicinarsi a questo progetto e all'architettura della soluzione?

    
posta Tom Pickles 03.04.2014 - 12:22
fonte

2 risposte

1

Con le informazioni che hai fornito, ti consiglio di utilizzare MS SQL Server per archiviare e confrontare i dati. Nessuna rappresentazione XML o intermedia. Raccogli, trasforma e scarica tutto direttamente nel DB. Se al momento funziona su VBscript e MS SQL Server presumo che non sia super-critico.

Le letture dallo schema de-normalizzato potrebbero essere veloci, che serviranno i report più velocemente quando richiesto. È meglio che eseguire query di join con un modello di dati complesso ma snello. Di nuovo molto dipende dall'intervallo di campionamento e dal volume dei dati. Non penso che possa crescere più di qualche milione di righe se parliamo di pochi giorni di dati con 10 secondi di campionamento per circa 100 server. Con gli indici obbligatori sul posto dovrebbe essere abbastanza veloce in MS SQL Server. Potrebbe essere necessario definire una strategia di archiviazione; o aggregare le statistiche più vecchie in una granularità più grossolana e passare ad alcune tabelle aggregate.

    
risposta data 02.08.2014 - 01:42
fonte
1

I'm ok with collecting the data (using .Net), but I'm at a loss as to where the best place is to do such things as store and lookup/compare items to good known values (XML, DB?). Should I do it as part of the data collection phase and then push it into the DB. Or should I marry it all up as part of the reporting data?

Lo raccomanderei di fare in questo modo.

Crea un servizio Collector, che verrà eseguito sui computer client e raccoglierà i dati. Dovrebbe memorizzare i dati raccolti localmente in XML, YAML, JSON o qualsiasi altra cosa (personalmente tendo ad usare JSON in questi giorni).

CollectorService interrogherà l'hardware, il software o qualsiasi altra cosa, memorizzerà i dati localmente sul computer client e quindi si collegherà alla directory centrale dei dati e invierà i dati lì. Dopo aver confermato la ricezione, i dati locali possono essere cancellati. I dati devono essere trasferiti nello stesso formato in cui sono stati raccolti (ad es. JSON).

Crea ProcessorService, che riceverà i dati dai client e li memorizzerà nel database centrale. Consiglierei Postgres per l'archiviazione (di più su questo in un momento). ProcessorService dividerà i dati ricevuti dai client in due gruppi usando la seguente regola: i dati, che probabilmente vengono interrogati, spesso vanno allo schema / tabella / colonna separati. I dati, che verranno interrogati raramente, entrano nei campi / sottocampi delle colonne JSONB.

Ora perché Postgres. La versione 9.4 di questo meraviglioso server DB può ora gestire i tipi JSON nelle colonne e per di più - può definire indici arbitrari su campi JSON di qualsiasi profondità. Quindi, non perdi molti dati di archiviazione nella colonna JSONB confrontandoli con l'archiviazione in una separata. Così ora Postgres parla anche di NoSQL;)

Ora create AnalysisService. Questo incorpora tutto sulla query di dati. Questo è ciò con cui lavorerà enduser.

    
risposta data 31.01.2015 - 20:31
fonte

Leggi altre domande sui tag

Esiste un modo per non utilizzare il pattern Observer durante la creazione di sistemi GUI? A che punto l'accesso ai dati \ la logica di manipolazione diventa logica aziendale?