Я правильно понимаю, что эта команда помогает описать проект, а реализует его техническую часть уже другие команды? Как в таком случае идет добавление этих проектов в очередь этим командам? Как удается вставить внутренний проект вперед задач коммерческих.
С учетом недавних событий с изменением лицензии Elastic, продукт от Amazon будет развиваться отдельно. Именно в текущий период я бы не спешил с использование Amazon. Мне кажется надо посмотреть, как пойдет развиваться «новый» продукт.
3-я часть уже написана. Завтра будет опубликована. Если успеют проверит, может и сегодня.
Желания хоть отбавляй, а времени действительно не много сейчас.
Ставите нужное количество узлов Logstash, настраиваете одинаковый pipeline на каждом для приема данных, а на стороне Beats агента, которым собираете данные указываете эти узлы. Агенту включаете балансировку.
В отдельной статье про Logstash и Beats агенты этот вопрос будет описан.
На Windows никогда не использовал. Если не ошибаюсь, там все через установку из архива делается, сами настройки аналогичные должны быть. При указании путей надо специфику ОС учитывать.
1. Чтобы показать варианты настроек. Замечание дельное, спасибо! Наверное в первой части поправлю, сразу указав два варианта.
2. Совершенно верно, как и любая служба в единственном экземпляре — потенциальная точка отказа. На вопрос когда использовать никто не скажет точно, надо смотреть и тестировать конкретный кластер. Основная задача роли — поисковые запросы направлять на узлы, где данные лежат, потом все собрать пришедшее с узлов и отдать в Kibana. Если поисковых запросов много, то имеет смысл использовать эту роль, чтобы ES узлы не гоняли между собой трафик, если нет, то лучше еще узел с данными добавить.
На Elastic до 32 ГБ. Если «куча» будет больше, то сжатие в Java отключается и на работу с указателями начинается тратится много ресурсов, память теряется. На самом деле, если не увлекаетесь агрегацией данных, то можно под кучу и меньше выделят памяти.
По процессору, то лучше ядра.
Можно подробнее вот тут ознакомится.
Актуален для облачных провайдеров или кто использует их Elastic. Тех кто на своих ресурсах ставят Elastic, изменение не коснется.
В целом согласен, время покажет. Я лично надеюсь, что оба продукта получат толчок в развитии.
Я правильно понимаю, что эта команда помогает описать проект, а реализует его техническую часть уже другие команды? Как в таком случае идет добавление этих проектов в очередь этим командам? Как удается вставить внутренний проект вперед задач коммерческих.
Подскажите, какие задачи у специалиста саппорта?
Из каких специалистов состоит группа автоматизации?
Выше было написано:
Как контроллер второй круг использует database.SqlHandler с внешнего круга?
wazuh пока нет.
Желания хоть отбавляй, а времени действительно не много сейчас.
В отдельной статье про Logstash и Beats агенты этот вопрос будет описан.
2. Совершенно верно, как и любая служба в единственном экземпляре — потенциальная точка отказа. На вопрос когда использовать никто не скажет точно, надо смотреть и тестировать конкретный кластер. Основная задача роли — поисковые запросы направлять на узлы, где данные лежат, потом все собрать пришедшее с узлов и отдать в Kibana. Если поисковых запросов много, то имеет смысл использовать эту роль, чтобы ES узлы не гоняли между собой трафик, если нет, то лучше еще узел с данными добавить.
По процессору, то лучше ядра.
Можно подробнее вот тут ознакомится.
Вопрос безопасности обязательно рассмотрю в третей части цикла.
В целом согласен, время покажет. Я лично надеюсь, что оба продукта получат толчок в развитии.