2014-11-12 14 views
10

è possibile con Kibana (preferibilmente la nuova brillante versione 4 beta) per eseguire join sul lato dell'applicazione?Elasticsearch/Kibana: join Application-side

So che ES/Kibana non è costruito per sostituire i database relazionali e di solito è un'idea migliore per denormalizzare i miei dati. In questo caso d'uso, tuttavia, questo non è l'approccio migliore poiché la dimensione dell'indice sta esplodendo e le prestazioni scendono:

Sto indicizzando miliardi di documenti contenenti informazioni di sessione dei flussi di rete come questo: ip sorgente, porta sorgente, IP di destinazione, porta di destinazione, marca temporale.

Ora voglio anche raccogliere informazioni aggiuntive per ogni indirizzo IP, come la geolocalizzazione, asn, reverse dns ecc. Aggiungere queste informazioni ad ogni singolo documento di sessione rende l'intero database ingestibile: ci sono milioni di documenti con lo stesso IP gli indirizzi e la ridondanza di aggiungere le stesse informazioni aggiuntive a tutti questi documenti portano a un enorme ingordigia e un'esperienza utente insensibile anche su un cluster con centinaia di gigabyte di RAM.

Invece vorrei creare un indice separato contenente solo indirizzi IP univoci e i metadati che ho raccolto per ognuno di essi.

La domanda è: Come posso analizzare ancora i miei dati utilizzando kibana? Per ogni documento restituito dalla query, kibana dovrebbe eseguire una ricerca nell'indice ip e "arricchire virtualmente" ogni indirizzo ip con queste informazioni. Qualcosa come l'aggiunta di campi virtuali in modo che la struttura sarebbe simile a questa (al volo):

IP sorgente, porta sorgente, paese fonte, ASN di origine, fonte fqdn

Sono consapevole che questo sarebbe venuto al costo di più query.

+0

Per curiosità, stai usando doc_values ​​per la cache di campo non analizzata? Personalmente, prima ancora di tentare di normalizzare i miei dati, proverei a passare a doc_values ​​per vedere se ciò è stato d'aiuto. Potresti anche voler vedere gli ordinali globali int (ad esempio https://www.elastic.co/guide/en/elasticsearch/reference/1.6/fielddata-formats.html) ma con dati di cardinalità elevati in realtà non penso che sarebbe essere un'ottima idea .... – evanv

risposta

2

Non credo che ci sia una cosa, ma forse si poteva giocare con i filtri:

  1. Si crea VISUALIZZAZIONI dati curato e semplice che filtro sul tipi diversi e visualizzare solo una semplice dati.
  2. Si inseriscono queste visualizzazioni diverse in un dashboard per visualizzare tutti i dati associati a un tipo di join.
  3. si utilizzano i filtri come chiave di aderire e utilizzare il cruscotto completo, composta da diversi pannelli, per ottenere intuizioni di specifico si uniscono chiavi (ips nel tuo caso, o sessioni)

È necessario creare 1 dashboard per ogni tipo di join che si desidera creare.

Nota che sarà necessario armonizzare i nomi e le mappature dei campi nei diversi documenti!

Ci tenga aggiornati, questo è un problema interessante, vorrei ora come risulta con così tanti documenti.