т е у тебя нивкаком виде. не создается индекс на елк так? файл который ты читаешь есть в наличии? в нем новые логи появляются?

Какой файл?

кхм...ну если ты используешь filebeat

для сбора логов с линукса

то явно ты читаешь откудато жти логи

из файла

прописан в конфиге в секции path:

Я на сервере в логстеш смотрю

вот тут. у тебя указано какой файл читать. и из него отправлять в логстеш

Аа да

И?

Просто не могу понять что делать то

в нем новые логи есть?)

Ааа

Всем привет. Подскажите какой из двух вариантов хранения документов предпочтительнее:
1)

"_source": {
    "group": "фрукт",
    "name": "яблоко"
  }

"_source": {
    "group": "фрукт",
    "name": "персик"
  }
  
"_source": {
    "group": "фрукт",
    "name": "груша"
  }
  
"_source": {
    "group": "овощ",
    "name": "картошка"
  }

"_source": {
    "group": "овощ",
    "name": "капуста"
  }

 

2)

"_source": {
    "group": "фрукт",
    "name": "яблоко, персик, груша"
  }

"_source": {
    "group": "овощ",
    "name": "картошка, капуста"
  }
  

 
 Суть в том что поисковые запросы будут по полю name, а ответ меня интересует поле group. То есть делаю запрос по слову "яблоко"  и получаю ответ что это фрукт.
 
 Естественно пример приведен простой, по факту разных group у меня  в индексе десяток, а разных name несколько сотен.

смотря подо что хочешь оптимизацию. под скорость поиска - первый, под место на диске - второй

А что насчет качества поиска, в случае если вполне name будут не простые слова, а целые фразы или даже предложения?

под скорость поиска - первый, под место на диске - второй (с) в моем случае видимо разницу я не почутсвую если документы весят не более 5кБ, а общее их количесвто  пару сотен

в первом случае можно искать по полному совпадению - операция простая. во втором - либо полнотекстовый поиск, либо по keyword