Лучшая практика для обновления колонки всех документов в Elasticsearch

Question

Я занимаюсь разработкой системы анализа журналов.Входными данными являются файлы журнала.У меня есть внешняя программа Python, которая читает файлы журнала и решает, является ли запись (строка) или файлы журнала "нормальной" или "вредоносной".Я хочу использовать Elasticsearch Update API , чтобы добавить результат моей программы на Python («обычный» или «вредоносный») в Elasticsearch, добавив новый столбец с именем result.Таким образом, я ясно вижу результат моей программы через пользовательский интерфейс Kibana.

Проще говоря, мой код Python и Elasticsearch оба используют файлы журнала в качестве входных данных соответственно.Теперь я хочу обновить результат из кода Python до Elasticsearch.Какой лучший способ сделать это?

Я могу придумать несколько способов:

1. Elasticsearch автоматически присваивает документу идентификатор (_id).Если я могу узнать, как Elasticsearch вычисляет _id, тогда мой код Python может вычислить его сам, а затем обновить соответствующий документ Elasticsearch с помощью _id.Но вопрос в том, что в официальной документации Elasticsearch не говорится о том, какой алгоритм он использует для генерации _id.

2. Добавление идентификатора (например, номера строки) в файлы журнала самостоятельно.И моя программа, и Elasticsearch будут знать этот идентификатор.Моя программа может использовать этот идентификатор для обновления.Однако недостатком является то, что моя программа должна искать этот идентификатор каждый раз, потому что это только обычное поле вместо встроенного _id.Производительность будет очень плохой.

3. Мой код Python получает журналы от Elasticsearch вместо непосредственного чтения файлов журналов.Но это делает систему хрупкой, так как Elasticsearch становится критической точкой.Я только хочу, чтобы Elasticsearch в настоящее время просматривал журнал.

Так что первое решение будет идеальным в текущем представлении.Но я не уверен, есть ли лучшие способы сделать это?

Answer 1

Если возможно, реструктурируйте свое приложение так, чтобы вместо выгрузки простого текста в файл журнала вы непосредственно записывали структурированную информацию журнала в нечто вроде Elasticsearch.Спасибо позже.

Это не всегда возможно (например, если вы не контролируете источник журнала).У меня есть несколько мнений о ваших решениях.

1. Это кажется супер хрупким .Elasticsearch не основывается _id на свойствах конкретного документа.Он выбран на основе существующих _id полей, которые он сохранил (и я думаю, что также от случайного начального числа).Даже если это может сработать, использование недокументированного свойства - это хороший способ выстрелить себе в ногу при работе с командой, которая вносит серьезные изменения даже в свой документированный код так же часто, как Elasticsearch.
2. Этот на самом деле не так уж и плохо .Elasticsearch поддерживает ручной выбор идентификатора документа.Даже если это не так, он работает довольно хорошо для запросов с массовыми терминами и не будет таким узким местом, как вы думаете.Если у вас действительно так много данных, что это может сломать ваше приложение, то Elasticsearch, возможно, не лучший инструмент.

3. Это решение великолепно .Он очень расширяемый и не зависит от сложной зависимости от того, как построен файл журнала, как вы решили индексировать этот журнал в Elasticsearch и как вы решили читать его с помощью Python.Скорее вы просто получаете документ, и если вам нужно обновить его, вы делаете это обновление.

   Elasticsearch на самом деле не является худшей точкой отказа здесь, чем раньше (если ES выходит из строя, ваше приложение выходит из строя влюбое из этих решений) - вы просто делаете вдвое больше запросов (чтение и запись).Если ваше приложение убивает фактор 2, вам нужно либо лучшее решение проблемы (т.е. избегать Elasticsearch), либо вам нужно больше оборудования.ES поддерживает все виды конфигураций сегментирования, и вы можете сделать надежный сервер по доступной цене.

Один вопрос, почему у вас есть журналы в Elasticsearch, которые необходимо обновить именно с этимнормальное / вредоносное свойство?Если вы тот, кто помещает их в ES, просто пометьте их соответствующим образом, прежде чем хранить их, чтобы предотвратить лишнее чтение, которое вас беспокоит.Если это не вариант, то вы все равно, вероятно, захотите прочитать ES напрямую, чтобы в любом случае перетащить журналы в Python, чтобы избежать огромных затрат на повторный анализ исходного файла журнала.

Если это однократныйИсправьте существующие ES-данные, пока вы работаете с обычным или вредоносным ПО, тогда не беспокойтесь об увеличении скорости в 2 раза.Просто дросселируйте запрос, если вы беспокоитесь о сбое кластера.Исправление будет выполнено в конце концов, и, вероятно, быстрее, чем если бы мы продолжали обдумывать лучший вариант.