Комментарии 15
Необходимо обращать внимание на кодировку log-файлов
Да, с кодировкой часто бывают проблемы. Спасибо. что обратили на это внимание.
Извините, какой-то набор вредных советов.
1) Зачем kafka и logstash если вы используете filebeat-агенты? Агенты могут напрямую слать в elasticsearch, и запоминают где остановились, если пропала связь с получателем.
указать целевые индексы в elasticsearch можно на уровне самих агентов.
2) правила iptables в rc-файле в 2022 году. У вас какой дистрибутив? используйте ufw или iptables-persistent
можно вообще обойтись без фаервола, а просто в настройках указать интерфейс 127.0.0.1 в параметрах (elastic|open)search, если вы потом используете nginx
С другой стороны, какой цели вы достигаете фаерволом, если сервис все равно доступен через nginx.
3) вы ставите jdk, зачем? в комплекте с софтом идет свой jdk, который и используется
4) >По умолчанию OpenSearch-Dashboards доступен по порту 5601. Можно
изменить порт в настройках OpenSearch-Dashboards, однако тогда придется
запускать сервис под учетной записью root.
неверно, только если вы захотите использовать порт меньше 1024, что явно не в этом случае. На порту 5999 будет прекрасно работать также.
5) зачем вам nginx, на котором даже не используется http-авторизация, чисто для браузерного удобства, ну может быть...
6) используйте авторизацию, либо через тот же nginx, либо встроенную в (elastic|open)search. Пароли для авторизации у агентов могут лежать в специальном шифрованном файле, выцепить его оттуда особых проблем нет, но и в конфигах в явном виде не записан.
В итоге, возможно я проглядел, но так и не понял, зачем лишние слои в виде nginx, logstash, kafka
Не отвечу за автора, но иметь Kafka перед elsatic'ом - хорошая практика, особенно на нагруженных системах (напр. централизованное горячее хранилище логов всей компании). Она выступает как высокопроизводительный надежный буфер, сглаживает пики трафика и позволяет проводить работы на хранилище без страха потерять логи.
Мне показалось много эмоций в вашем комментарии) Вероятно у вас большой опыт в этой теме) Но вы не достаточно внимательно ознакомились с текстом. В любом случае спасибо за проявленный интерес и за советы.
Зачем я использую Kafka я описал в начале статьи. Если у вас другая ситуация, то и схема естественно будет другая. И если вам не нужна Kafka, то не используйте её. В чем проблема?
Как я и писал, вариантов выполнить эту задачу много. И опять же, в начале статьи я указал какой использую дистрибутив. Если вам нравятся другие подходы/инструменты пожалуйста, используйте их.
Вот тут я с вами соглашусь. Этот шаг, так сказать, "рудиментарный". Остался от моих начальных тестов.
А по вашему 80 порт больше чем 1024? Вы снова были невнимательны. Суть в том, чтобы использовать стандартный порт "80".
Да, так и есть, я так об этом и написал "чтобы было больше порядка".
За этот совет спасибо, я этим займусь.
Да, суть вы не уловили, зачем применяются эти инструменты. Но я и не делал на этом акцент. Я настраиваю указанную схему, принимая её в большей степени как поставленную задачу. В целом logstash и kafka позволяют придать системе больше отказоустойчивости, а nginx я использую только для перенаправления порта. Конечно можно порт перенаправать и через файерволл, но мой опыт в настройке разных систем подсказывает мне этого не делать, а использовать nginx.
>Мне показалось много эмоций в вашем комментарии
Да это так, потому что в сети появился еще один мануал, в котором ставится стек ELK или аналог, который обвязывается костылями (rc.local) и копипастами (apt install jdk nginx) без подробного объяснения, почему так и зачем. И в этих нюансах, как говорится кое-кто прячется. Если бы это было описано, чуть подробнее, цены бы не было статье.)
Лучше хотя бы в скобках указать альтернативы и причины для некоторых решений, потому что новички будут делать как написано, без пониманию, что же происходит. А старперы (типа меня) начнут читать статью по диагонали, и возможно, если не будет лень, оставят хоть какой-то комментарий, или просто закроют статью.
Например, в том же пункте 2 про iptables, я вообще не вижу смысла в этом правиле, если сервис продолжает быть открытым через nginx. Возникает ощущение, что это кочующая копипаста со времен, когда не было встроенной авторизации, и ее делали средствами прокси.
Про winlogbeat, имеет смысл еще добавить специфические логи, типа TaskScheduler и службы RDP, в моей инсталляции еще была одна известная бэкапилка.
winlogbeat.event_logs:
- name: Application
ignore_older: 8760h
- name: Security
ignore_older: 8760h
- name: System
ignore_older: 8760h
- name: Veeam Agent
ignore_older: 8760h
- name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
ignore_older: 8760h
- name: Microsoft-Windows-TaskScheduler/Operational
ignore_older: 8760hВ данной копипасте фильтр стоял на прошедший год. Было забавно наблюдать как security лог выгрузился в еластик быстрее, чем всякие примеры для выгрузки в файл аудита событий скриптами на powershell.
Видимо, автор - разработчик или администратор Windows. Ряд шагов выдают слабое знакомство с системами на базе Linux:
2. Установка unzip:
apt install unzip
Мелочь, но далее по тексту идёт распаковка tar.gz архивов. Зачем ставить unzip?
3. Создание пользователя opensearch:
groupadd opensearch
useradd opensearch -g opensearch -M -s /bin/bash
Зачем отдельно создавать основную группу пользователя, если useradd и так по умолчанию обычно её создаёт? Зачем пользователю демона рабочий шелл? На мой субъективный взгляд проще всего было бы завести пользователя так: useradd -M -d /opt/opensearch -s /bin/false opensearch
2. Даем права на выполнение для архива:
chmod +x opensearch-1.2.4-linux-x64.tar.gz
2. Даем права на выполнение для архива:
chmod +x ./filebeat-7.12.1-amd64.deb
Зачем делать файл архива исполняемым? Это действие лишено всякого смысла.
3. Распаковываем архив:
tar -xf opensearch-1.2.4-linux-x64.tar.gz4. Будем устанавливать OpenSearch в каталог «/opt/opensearch», поэтому создаем рабочий каталог для OpenSearch:
mkdir /opt/opensearch6. Переносим распакованные данные в рабочий каталог:
mv ./opensearch-1.2.4/* /opt/opensearch6. Удаляем каталог, оставшийся от распаковки:
rmdir ./opensearch-1.2.4
Непонятно, зачем создавать директорию, переносить содержимое распакованного архива и удалять исходный каталог вместо одной команды mv ./opensearch-1.2.4 /opt/opensearch
9. Создаем файл демона для работы OpenSearch:
nano /lib/systemd/system/opensearch.service
Снова небольшое замечание: в /lib/systemd/system обычно лежат юниты, создаваемые при установке пакетов. Коль скоро здесь всё делается руками, созданные файлы сервисов имеет смысл класть в /etc/systemd/system
1. Запустим настроенный нами демон OpenSearch:
systemctl start opensearch2. Проверим статус запуска демона OpenSearch:
systemctl status opensearch3. Настроим автозапуск демона OpenSearch:
systemctl enable opensearch
Hint: включить автозапуск демона и одновременно его запустить можно командой systemctl enable --now opensearch
По поводу создания пользователя opensearch. Это необходимо в п.2.2.8 "Запускает установочный скрипт от имени пользователя opensearch".
По поводу того, почему "mv", а потом "rmdir". Некоторые файлы не перенесутся, а скопируются. Вместо того, чтобы править права у этих файлов я поступил таким образом, в целом этот путь короче.
В целом, спасибо за замечания. Я действительно не успел "отточить" некоторые инструкции. Статья получилась объемная.
про nginx
Не будем удалять, а сделаем резервную копию настроек Nginx по умолчанию:
cp /etc/nginx/sites-enabled/default /etc/nginx/sites-enabled/default.sav
вообще неправильно, тк там лежит не файл, а симлинк default -> /etc/nginx/sites-available/default
В случае неудачи перезагрузим Nginx:
service nginx reload
restart же, но если свалился с ошибкой reload, то в 90% случаем restart не только не поможет, а окончательно остановит сервис, который продолжал работать со старым конфигом.
Мы не придираемся, а просто хотим сделать лучше.
К слову про устаревание инструкций. Раньше в мануалах везде писали про настройки Java. Но в elasticsearch с какой-то версии теперь пишут, чтобы не трогали настройки памяти без крайней необходимости. Они выставляются автоматически в половину RAM и не более 31гб на экземпляр. В opensearch пока еще предлагают ставить значение вручную по выбору.
И что же по вашему произойдет если при копировании исходным объектом указать симлинк? Будет создана копия оригинального файла, на который ведет симлинк. Собственно бэкап и будет создан.
В целом спасибо за замечания. И, повторюсь как в комментарии выше. Я действительно не успел "отточить" некоторые инструкции. Статья получилась объемная.
Ух сколько текста, даже за это спасибо! А если где то и есть какие то недочёты, о которых не много комментариев, то это может быть у всех, но хорошо бы ещё тогда и ваши такие же хорошие статьи увидеть как автор написал.
8. Запускаем скрипт для создания новых сертификатов:
этот скрипт не для создания сертов, а для применения конфига секьюрити плагина
https://opensearch.org/docs/1.2/security-plugin/configuration/security-admin
Встретился еще с таким важным параметром для кластера "cluster.max_shards_per_node". До конца еще не разобрался, что конкретно он означает, но по достижению определенного количества индексов/объема данных в базе, новые данные перестали записываться в базу, а в логах появилась ошибка о том, что предел шардов (по умолчанию 3000) в кластере достигнут. Изменить максимальный предел шардов в кластере получилось такой командой из консоли:
curl -X PUT https://localhost:9200/_cluster/settings -H "Content-Type: application/json" -d '{ "persistent": { "cluster.max_shards_per_node": "1000000" } }' -u 'admin:yN-3L(GMmAAw' --insecure
Посмотреть что получилось можно такой командой:
curl -X GET https://localhost:9200/_cluster/settings -u 'admin:yN-3L(GMmAAw' --insecure
Установка, настройка и эксплуатация стэка OpenSearch в классической среде