# Parsing / Indexing strategies for BRO? **URL:** \ **Category:** Logstash\ **Created:** [August 31, 2017, 2:17pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016 "2017-08-31T14:17:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![lucasjkr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lucasjkr/32/34317_2.png) [@lucasjkr](https://discuss.elastic.co/u/lucasjkr)\ **Post date:** [August 31, 2017, 2:17pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/1 "2017-08-31T14:17:26Z")
This is part logstash, part elastic search, but since the decision is being made at the Logstash level, I thought I would ask here: What are peoples strategies for indexing incoming BRO data? It creates over a dozen logfiles which need to be parsed and indexed into ES. First, I was storing everything in a single ES index, but reflecting on RDBMS's, I thought that might be inefficient, because some logs have one set of fields, and other logs have completely different sets of fields. So in an effort to "normalize", I've begun storing each log type in its own separate index. However, sometimes we need to be alerted about events that happen ACROSS log types. So I've started working on additional logstash steps to normalize a subset of the BRO data (regardess of log type), to store in a new index (bro-combined), so we have a single index to refer to, and can go to the dedicated indexes for more information if needed. I'm wondering if you all think I'm on the right track, or if i'm going about things in completely the wrong way. It seems to make sense from a perspective on workflow, but I am worried that this strategy will double the insert transactions that ES needs to handle, while the bandwidth difference will be somewhat less extreme (probably 1.4-1.5x). Interested to hear peoples thoughts. thank! ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [September 1, 2017, 10:23am UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/2 "2017-09-01T10:23:51Z")
How are you doing the alerting? ---
**Author:** ![lucasjkr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lucasjkr/32/34317_2.png) [@lucasjkr](https://discuss.elastic.co/u/lucasjkr)\ **Post date:** [September 1, 2017, 1:01pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/3 "2017-09-01T13:01:06Z")
I'm evaluating SIEMonster, so I'm using the FourOneOne interface supplied as part of that package. > **[etsy/411](https://github.com/etsy/411)** > > 411 - An Alert Management Web Application [https://demo.fouroneone.io/](https://demo.fouroneone.io/) ---
**Author:** ![Blaxican707](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/blaxican707/32/21788_2.png) [@Blaxican707](https://discuss.elastic.co/u/Blaxican707)\ **Post date:** [September 2, 2017, 5:14pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/4 "2017-09-02T17:14:27Z")
You can run multiple IF and ELSE IF statements if you equate them to the different logs into one config file, so there really is no need for different config files. ---
**Author:** ![lucasjkr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lucasjkr/32/34317_2.png) [@lucasjkr](https://discuss.elastic.co/u/lucasjkr)\ **Post date:** [September 2, 2017, 5:42pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/5 "2017-09-02T17:42:14Z")
I like the method Kustodian chose of using separate .conf files for each log type, it's more modular, easier to keep in a VCS, can compare different filters side by side, etc. Either way, it works the same. More the question was about WHAT to do with the data after log stash, store in a single ES index, a different index for each logtype (protocol), or a combination of the two (individual indexes, with a second "insert" of a subset of each record into a combined index. I know in the regular database world, it's more efficient to normalize data, I'm not sure how that relates to Lucene/ES yet. Like, is it better to keep everything together even if each set of fields is only used by 10% of the records, or break them out to store and index separately? ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [September 2, 2017, 8:56pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/6 "2017-09-02T20:56:21Z")
Depends. Sparse data can be stored inefficiently but there's improvements coming in 6.0 in Lucene for that. However, you can read data from different indices by simply querying them at the same time. So I guess it depends on how you interact with Elasticsearch via these other tools. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 30, 2017, 8:56pm UTC](https://discuss.elastic.co/t/parsing-indexing-strategies-for-bro/99016/7 "2017-09-30T20:56:37Z")
Closed on September 30, 2017, 8:56pm UTC This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.