Approccio alla progettazione dell'architettura per la raccolta metrica

Naviga le tue risposte
-2

Vogliamo attirare le metriche dell'applicazione e dell'azienda dall'applicazione web di origine per tenere traccia della fatturazione, dell'utilizzo e delle prestazioni dell'applicazione. Queste metriche devono essere archiviate in un database diverso (Oracle) per ulteriori elaborazioni e analisi. Creeremo dashboard analitici su questi parametri che verrebbero presentati a diversi stakeholder, inclusi i clienti. Di seguito sono riportati i punti che dovrebbero essere annotati

  1. La raccolta delle metriche dovrebbe avere un overhead delle prestazioni molto basso (CPU, memoria, archiviazione) sul server di applicazioni Web di origine (basato su java ee)
  2. Non dovrebbe introdurre nuovi componenti nell'infrastruttura di sistema dato che raccoglieremo 100-200 metriche dall'applicazione di origine. Potrebbe non valere lo sforzo di manutenzione (implementazione / operazioni / spese generali).
  3. Alcune metriche sono basate su eventi. Ad es. dimensione della richiesta del servizio Web, dimensione del file caricato dall'utente, data di accesso utente e data / ora di logout. Inoltre, non tutte le metriche sono di tipo numerico. Ad es. indirizzo IP, timestamp.
  4. La raccolta delle metriche deve essere eseguita da circa 50-100 distribuzioni (multi-tenant e single-tenant) dell'applicazione.

Mi piacerebbe capire i diversi approcci di architettura che possiamo prendere in considerazione per la raccolta di queste metriche in un database diverso. Fornisci dettagli sufficienti per avere un'idea di come sarebbe l'implementazione.

    
posta Andy Dufresne 14.02.2018 - 07:54
fonte

1 risposta

1

Hai requisiti in conflitto.

Una metrica è di solito un calcolo aggregato, vale a dire "quante volte al secondo è stato colpito il mio sito web?"

I database di solito non sono adatti per la raccolta di metriche, o si inserisce una nuova riga per singolo evento e quindi si esegue una query sql aggregata, che utilizza molto spazio su disco e cpu, oppure si aggiorna continuamente una riga di stile dell'istogramma, che tende essere lento a causa del blocco.

Qualcosa come statsd aggira questo problema con un database personalizzato che fa l'aggregazione per te e UDP attiva e dimentica le connessioni.

Il lato negativo è che è possibile perdere singoli record o registrarli in modo errato in caso di problemi di rete o esaurimento della capacità del server.

Se hai un evento di controllo, che deve essere registrato, allora un database è una buona soluzione, dato che puoi fare cose come confermare la scrittura del record, eseguire il rollback delle transazioni quando accadono errori ecc. Ma tutto ciò a costo di velocità.

Se si desidera eseguire report aggregati sui record di controllo, ad esempio, ad esempio, i report finanziari. Una buona soluzione è scaricare il lavoro di reporting in un data warehouse esportando le transazioni su di esso.

Questo tende a coinvolgere un compito programmato di "trasferimento dati", quindi non è così buono per le cose in cui si desidera un riscontro immediato, ad es. "web server 6 sta per esplodere !!!"

    
risposta data 15.02.2018 - 11:11
fonte

Leggi altre domande sui tag

Qual è l'approccio migliore per trovare elementi nella collezione che soddisfano lo scenario I PW generati dagli utenti sono un ricordo del passato per la maggior parte delle app?