​​С удивлением узнал, что существует полноценная бесплатная open source SIEM-система (менеджмент информации и событий безопасности) - Wazuh. Она состоит из агентов для сбора данных под все популярные системы и серверной части с дашбордом и просмотром информации через браузер.

С помощью Wazuh можно решать следующие задачи:
◽ анализ журналов
◽ мониторинг файлов
◽ обнаружение вторжений
◽ сканирование запущенных процессов
◽ реагирование на инциденты
◽ проверка соответствия систем заданным политикам
◽ проверка уязвимостей CVE

Сама система Wazuh построена на базе Linux, но позволяет наблюдать в том числе за хостами под Windows.

Wazuh зрелый и известный проект. Имеет интеграцию с ELK, в том числе плагин для Kibana с готовыми дашбордами. Яндекс.Облако предлагает использовать Wazuh как готовую DevSecOps платформу и развернуть в несколько кликов через свой готовый образ.

Развернуть Wazuh можно на своём железе. В документации всё подробно описано. Можно использовать скрипты установки, пакеты из репозиториев, либо готовый образ виртуальной машины, docker контейнеры, готовый deployment для kubernetes.

Для тех, кто не совсем понимает, что это за система и как работает, поясню на небольших примерах. Это не антивирус, который автоматически обновляет базы и что-то делает за вас. Эта система собирает данные и предлагает вам настроить оповещения и какие-то действия на конкретные события. При этом она может получать данные и от антивирусов.

Допустим, какой-то ваш сервис брутят, пытаясь подобрать учётную запись. Вы видите это в логах. Заранее или по факту пишите какой-то скрипт, правило или что-то ещё, что управляет вашим фаерволом. Потом применяете это правило блокировки злоумышленника на основе данных из логов как реакцию на событие. Другой пример. С помощью агента вы знаете список софта и его версии. В какой-то момент появляется CVE для одной из версий. Вы видите это на основе отчёта. Далее создаёте политику на обновление уязвимых программ и распространяете её.

Сам я Wazuh никогда не использовал и даже не видел. Собрал информацию по ходу написания заметки. Если вы использовали, дайте обратную связь. На вид всё выглядит неплохо. Я даже задумался, какой смысл устанавливать и настраивать только ELK для сбора и анализа логов, если можно сразу Wazuh развернуть и получить не только обзор логов, но и всё остальное. Под капотом там тот же Elasticsearch и Kibana.

⇨ Сайт / Документация / Исходники

#security #elk #devops

Наконец-то собрался с силами и обновил статью по настройке ELK Stack. Он так часто обновляется, что материал устаревает практически полностью в течение года.

Мне регулярно приходится его настраивать, так что не только обновил статью, но и поднял свой deb репозиторий для всех пакетов, что используются в инструкции. Теперь не придётся через VPN или прокси копировать вручную пакеты. В Debian 11 можно автоматически устанавливать через менеджер пакетов, а для всех остальных deb систем можно зайти по адресу репо или просто по IP (тупит DNS, не было времени разобраться) и скачать вручную пакет.

Полный ELK Stack довольно навороченная и сложная система. Так что сделать пошаговую настройку не так просто. Надеюсь нигде сильно не ошибался. Написал по горячим следам после очередной настройки. Конфиги брал с работающих серверов, но разных, так как одновременно и Linux, и Windows логи встречаются редко. Некоторые некритичные картинки остались от 7-й версии. Отличия не сильные, не стал переделывать.

⇨ Установка и настройка ELK Stack

#elk #devops

​​Расскажу своими словами про особенности и удобство сбора логов в ELK Stack или любое подобное хранилище на его основе. Продукт сложный и многокомпонентный. Те, кто с ним не работали, зачастую не понимают, что это такое и зачем оно нужно. Ведь логи можно хранить и просматривать много где. Зачем этот тяжелющий монстр? Я поясню своими словами на простом примере.

Вои пример фрагмента лога web сервера стандартного формата:

180.163.220.100 - travvels.ru [05/Sep/2021:14:45:52 +0300] "GET /assets/galleries/26/1.png HTTP/1.1" 304 0 "https://travvels.ru/ru/glavnaya/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36"

Он состоит из отдельных частей, каждая из которых содержит какую-то информацию - ip адрес, дата, тип запроса, url, метод, код ответа, количество переданных байт, реферер, user-agent. Это стандартный формат лога Nginx или Apache.

ELK Stack не просто собирает эти логи и хранит у себя. Он распознаёт каждое значение из каждой строки и индексирует эти данные, чтобы потом можно было быстро с ними работать. Например, подсчитать количество 500-х кодов ответов, или количество запросов к какому-то урлу. Для типовых форматов данных есть готовые фильтры парсинга. Но нет проблем написать и свои, хоть и не так просто, но посильно. Я в своё время разобрался, когда надо было. В частности, Logstash использует фильтры GROK.

Чтобы было удобно работать с логами, я обычно делаю следующее. Собираю дашборд, куда вывожу в виджетах информацию о топе урлов, к которым идут запросы, о топе ip адресов, с которых идут запросы, о топе user-agent, графики кодов ответов и т.д. В общем, всё, что может быть интересно.

Когда нужно разобраться с каким-нибудь инцидентом, этот дашборд очень выручает. Если честно, я так привык к ним, что даже не представляю, как обслуживать веб сервер без подобного сбора и анализа логов. Так вот, я открываю этот дашборд и вижу, к примеру, что к какому-то урлу идёт вал запросов. В поиске тут же в дашборде делаю группировку данных на основе этого урла и дашборд со всеми виджетами перестраивается, выводя информацию только по этому урлу.

В итоге я вижу все IP адреса, которые к нему обращались, все коды ответов, все user-agents и т.д. Например, я могу увидеть, что все запросы к этому урлу идут с одного и того же IP адреса и это какой-то бот. Можно его забанить. Также, например, можно заметить, что резко выросло количество 404 ошибок. Делаю группировку по ним и вижу, что все 404 коды ответов выдаются какому-то боту с отличительным user-agent, который занимается перебором. Баним его по user-agent.

Надеюсь, понятно объяснил принцип. Видя какую-то аномалию, мы без проблем можем детально её рассмотреть со всеми подробностями. Ещё актуальный пример из практики. В веб сервере сайта на Bitrix можно добавить ID сессии пользователя в лог веб сервера. Затем подредактировать стандартный фильтр парсинга Logstash, чтобы он индексировал и это поле. После этого вы сможете делать группировку логов по этой сессии. Очень удобно, когда надо просмотреть все действия пользователя. Эту настройку я описывал в отдельной статье.

Подводя итог скажу, что ELK Stack очень полезный инструмент даже в небольшой инфраструктуре. Не обязательно собирать кластер о хранить тонны логов. Даже логи с одного сайта очень помогут в его поддержке. Админам инфраструктуры на Windows тоже советую обратить внимание на ELK. С его помощью удобно разбирать журналы Windows, которые он тоже умеет парсить и индексировать. По винде я делал отдельную статью, где описывал принцип и показывал примеры.

Если захотите изучить ELK Stack и попробовать в работе, воспользуйтесь моей статьёй. С её помощью простым копипастом можно поднять весь стек и попробовать с ним поработать. Ничего супер сложного в этом нет. Когда я задался целью, то сам с нуля всё изучил, не ходил ни на какие курсы и никто мне не помогал. Просто сел и разобрался понемногу. Было тяжело, конечно, особенно с фильтрами, но дорогу осилит идущий.

#elk

​​Постоянно приходится заниматься вопросами сбора и анализа логов веб серверов. Решил сделать подборку инструментов для этих целей от самых навороченных, типа ELK, до одиночных консольных утилит.

✅ Сам я чаще всего использую именно ELK, потому что привык к нему, умею настраивать, есть все заготовки и понимание, как собрать необходимые дашборды. Минусов у этого решения два:
◽ELK очень прожорливый.
◽Порог входа довольно высокий. Но тем не менее, ничего запредельного там нет. У меня знакомый с нуля по моей статье за несколько дней во всём разобрался. Немного позадавал мне вопросов, чтобы побыстрее вникнуть в суть. А дальше сам. В итоге всю базу освоил, логи собрал, дашборды сделал. В общем, было бы желание, можно и без дорогих курсов разобраться с основами. Сразу плюс к резюме и будущей зарплате.

Про #elk я много писал как здесь, так и на сайте есть разные статьи.

🟢 Альтернатива ELK - Loki от Grafana. Сразу скажу, что опыта с ним у меня нет. Так и не собрался, нигде его не внедрил. Всё как-то лениво. Использую привычные и знакомые инструменты. Плюсы у Loki по сравнению с ELK существенные, а конкретно:
◽кушает меньше ресурсов;
◽проще настроить и разобраться.
Из минусов — меньше гибкости и возможностей по сравнению с ELK, но во многих случаях всего этого и не надо. Если бы сейчас мне нужно было собрать логи веб сервера и я бы выбирал из незнакомых инструментов, начал бы с Loki.

🟢 Ещё один вариант — облачный сервис axiom.co. У него есть бесплатный тарифный план, куда можно очень быстро настроить отправку и хранение логов общим объёмом до 500 ГБ!!! Зачастую этого хватает за глаза. В него можно отправить распарсенные grok фильтром логи, как в ELK и настроить простенькие дашборды, которых во многих случаях хватит для простого анализа. Мне понравился этот сервис, использую его как дубль некоторых других систем. Денег же не просит, почему бы не использовать.

Далее упомяну системы попроще, для одиночных серверов. Даже не системы, а утилиты, которых иногда может оказаться достаточно.

🟡 Классная бесплатная утилита goaccess, которая умеет показывать статистику логов веб сервера в режиме онлайн в консоли. Либо генерировать статические html страницы для просмотра статистики в браузере. Устанавливается и настраивается очень легко и быстро. Подробности есть в моей заметке. Интересная программа, рекомендую. Пример html страницы.

🟡 Ещё один вариант консольной программы — lnav. Он заточен не только под веб сервер, но понимает и его формат в виде базовых настроек access логов.

Перечислю ещё несколько решений по теме для полноты картины, с которыми я сам не работал, но знаю про них: Graylog, OpenSearch.

❗️Если забыл что-то известное, удобное, подходящее, дополните в комментариях.

#logs #webserver #подборка

Забавная история случилась с моим репозиторием для ELK Stack. Специально расположил его на VPS, арендованном в USA, чтобы было удобнее скачивать новые пакеты и обновлять репозитории. И вот на днях решил в очередной раз его обновить и очень удивился, когда не смог ничего скачать по свежим ссылкам. Получал ERROR 403: Forbidden. Проверил на другом иностранном сервере, скачал без проблем. То есть мой VPS забанили. Не понятно, в рамках чего это было сделано. Кто-то стуканул или какая-то другая причина. Обновлял я в ручном режиме и запросами не спамил. IP (188.227.57.126) по всем базам сшашный.

Пришлось через другой сервер качать и обновлять репозиторий. Теперь его можно и в Россию вернуть. Один фиг качать через прокладки придётся. Я там всю структуру переделал, добавив сразу Debian 11 и 12, чтобы удобнее было. Настроил всё с помощью aptly, так что сразу кратко все команды приведу, а то постоянно забываю и приходится каждый раз в документацию лезть, когда с ним работаешь.

Ставим:
# apt install aptly

Конфиг /etc/aptly.conf:
{
 "rootDir": "/mnt/aptly",
 "downloadConcurrency": 4,
 "downloadSpeedLimit": 0,
 "architectures": [],
 "dependencyFollowSuggests": false,
 "dependencyFollowRecommends": false,
 "dependencyFollowAllVariants": false,
 "dependencyFollowSource": false,
 "dependencyVerboseResolve": false,
 "gpgDisableSign": false,
 "gpgDisableVerify": false,
 "gpgProvider": "gpg",
 "downloadSourcePackages": false,
 "skipLegacyPool": true,
 "ppaDistributorID": "elastic",
 "ppaCodename": "",
 "FileSystemPublishEndpoints": {
 "elastic": {
  "rootDir": "/mnt/aptly",
  "linkMethod": "symlink",
  "verifyMethod": "md5"
 }
 },
 "enableMetricsEndpoint": false
}

Под репы выделил каталог /mnt/aptly. Создаём 2 репозитория:
# aptly repo create -comment="Elastic repo" -component="main" \
-distribution="bullseye" -architectures="amd64" elastic-bullseye
# aptly repo create -comment="Elastic repo" -component="main" \
-distribution="bookworm" -architectures="amd64" elastic-bookworm

Добавляем туда пакеты:
# aptly repo add elastic-bullseye elasticsearch-8.9.2-amd64.deb
.......

# aptly repo add elastic-bookworm elasticsearch-8.9.2-amd64.deb
.......

Создаю gpg ключ для репозиториев:
# gpg --default-new-key-algo rsa4096 --gen-key --keyring pubring

Публикую репозитории:
# aptly publish repo elastic-bullseye
# aptly publish repo elastic-bookworm

В директории /mnt/aptly появляются две директории: db, public. Ту, что public, надо опубликовать через web сервер. Вот мой конфиг nginx:

server {
  listen 80 default_server;
  server_name elasticrepo.serveradmin.ru;
  root /mnt/aptly/public/;
  access_log /var/log/nginx/aptly-access.log main;
  error_log /var/log/nginx/aptly-error.log;

  location / {
   autoindex on;
  }
}

Осталось положить ключ в публичную директорию:
# gpg --export --armor > /mnt/repo/public/elastic.asc

На этом всё. Запускаем веб сервер и подключаем репозитории к системам:
# echo "deb http://elasticrepo.serveradmin.ru bullseye main" \
| tee /etc/apt/sources.list.d/elasticrepo.list

# echo "deb http://elasticrepo.serveradmin.ru bookworm main" \
| tee /etc/apt/sources.list.d/elasticrepo.list

Устанавливаем ключ:
# wget -qO - http://elasticrepo.serveradmin.ru/elastic.asc | apt-key add -

На Debian 12 увидите предупреждение, что apt-key is deprecated, но это не критично. Теперь можно обновлять репозитории и устанавливать из них пакеты.

Если нужно добавить пакеты, то делаем так:
# aptly repo add elastic-bullseye elasticsearch-9.0.0-amd64.deb
# aptly publish update bullseye

Если надо удалить пакет:
# aptly repo remove elastic-bullseye elasticsearch_8.5.2_amd64
# aptly publish update bullseye
# aptly db cleanup

Ещё полезные команды aptly:
# aptly repo list
# aptly package search logstash
# aptly repo show -with-packages elastic-bullseye

#debian #elk #aptly

​​Если вы никогда не работали с OpenSearch, но хочется на него посмотреть и сравнить с ELK, то можно воспользоваться playground.opensearch.org. Для регистрации достаточно учётки gmail. Но даже если не регистрироваться, то можно что-то посмотреть. Но я не совсем понял, в каком формате. Я сразу зарегистрировался.

После регистрации вы получаете чистый сервер OpenSearch, куда загружены образцы типовых логов и дальше можно делать, что душе угодно. Создавать индексы, визуализации, дашборды и т.д. В общем, всё то же самое, что и на полноценной системе.

Я с OpenSearch вообще не знаком, но неплохо знаю ELK. Использую для сбора всевозможных логов: веб серверов, виндовых серверов, файловых, в том числе под виндой, логи микротиков, почтовых серверов и т.д. В общем, всё, что можно, туда засовываю.

На первый взгляд отличия не сильно заметны. Вся структура и логика такая же. Но дальше уже заметны отличия. Интерфейс создания визуализаций другой. Я захотел, но не смог создать простенький дашборд для Nginx. Надо разбираться.

В общем, если вам интересно попробовать OpenSearch, воспользуйтесь этой бесплатной платформой. Я для себя особо смысла не вижу использовать OpenSearch. ELK с его лицензией и возможностями мои потребности полностью закрывает, так что переучиваться не вижу смысла.

Как и зачем появился OpenSearch, рассказывал в отдельной заметке. Если кто-то знает веские причины, кроме недоступности репозиториев ELK из России, по которым стоит перейти на OpenSearch, прошу поделиться в комментариях.

#elk

​​Западные блокировки в интернете добавляют лишнюю суету в повседневную работу. Я вам покажу очень простой и быстрый способ, как их обходить на примере загрузки и запуска продуктов elastic. Как известно, с территории РФ их скачать невозможно, как и воспользоваться репозиторием docker образов.

Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:

# apt install privoxy

Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.

Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.deb
HTTP request sent, awaiting response... 403 Forbidden

Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:

# ssh -L 3128:localhost:8118 root@1.2.3.4

Проверяем, что порт проброшен:

# ss -tulnp | grep 3128
tcp  LISTEN 0   128    127.0.0.1:3128    0.0.0.0:*  users:(("ssh",pid=1350,fd=5))

Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг ~/.wgetrc:

use_proxy=yes
http_proxy=127.0.0.1:3128
https_proxy=127.0.0.1:3128

И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.

Если хочется запустить elasticsearch в докере из официального образа, то подключаем прокси докеру. Для этого передаём ему переменные через systemd. Все возможные варианты настройки прокси в докере описаны в документации.

# mkdir -p /etc/systemd/system/docker.service.d
# mcedit /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:3128"
Environment="HTTPS_PROXY=http://127.0.0.1:3128"

 # systemctl daemon-reload
 # systemctl restart docker

Обращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:

# systemctl show --property=Environment docker
Environment=HTTP_PROXY=http://127.0.0.1:3128 HTTPS_PROXY=http://127.0.0.1:3128

Теперь можно забрать образ последней версии и запустить его:

# docker pull docker.elastic.co/elasticsearch/elasticsearch:8.13.2
# docker run -d -e "discovery.type=single-node" \
  -p 9200:9200 \
  -p 9300:9300 \
   docker.elastic.co/elasticsearch/elasticsearch:8.13.2

После того, как всё скачано и запущено, настройки прокси можно отключить.

Такой простой и быстрый метод с использованием своего прокси. Не надо искать сторонние репозитории или настраивать свои. Не надо подключать VPN и что-то ставить дополнительно на исходный сервер. Забрали всё с репозитория разработчиков, сделав минимум движений на сервере, куда всё устанавливали.

#elk #ssh #docker

Для того, чтобы начать собирать логи в Elasticsearch не обязательно поднимать полный ELK stack. Я сейчас кратко покажу, как быстро запустить сбор логов из Nginx в Elasticsearch помощью Vector. А в качестве веб интерфейса для работы с еластиком буду использовать легковесный Elasticvue.

Elasticsearch я запущу в Docker, отключив HTTPS и аутентификацию. То есть это будет тестовая установка. В проде отключать не надо. Там не намного сложнее настройка, просто я не смогу уместить её в одну заметку, если не отключу их. Нужно будет сделать больше настроек.

Запускаем Elasticsearch:

# docker run -d -p 9200:9200 -p 9300:9300 \
-e "http.cors.enabled=true" \
-e "http.cors.allow-origin=http://172.30.245.222:8080" \
-e "discovery.type=single-node" \
--name elastic \
elasticsearch:8.13.0

Здесь 172.30.245.222 - это IP адрес сервера, на котором будет запущен веб интерфейс Elasticvue. В моём случае это та же машина, где запускается еластик. Дожидаемся запуска контейнера и забираем из него конфиг службы:

# docker cp elastic:/usr/share/elasticsearch/config/elasticsearch.yml ~/

Всё, что касается настроек xpack.security заменяем true на false. Возвращаем изменённый конфиг:

# docker cp ~/elasticsearch.yml elastic:/usr/share/elasticsearch/config/elasticsearch.yml

Перезапускаем контейнер:

# docker restart elastic

Дожидаемся запуска и проверяем работу:

curl http://172.30.245.222:9200

Должны увидеть информацию о кластере elasticsearch. Его имя будет docker-cluster. Запускаем тут же в докере веб интерфейс:

# docker run -d -p 8080:8080 --name elasticvue cars10/elasticvue

Этот веб интерфейс может работать как приложение на десктопе или плагин браузера. Интересная штука, кто не знаком, посмотрите описание на сайте.

Идём в веб интерфейс по IP адресу сервера и порт 8080. Настраиваем подключение к кластеру. Указываем настройки:
◽️No authorization
◽️docker-cluster
◽️http://172.30.245.222:9200

Убеждаемся, что всё работает.

Теперь ставим Vector, который будет отправлять логи Nginx в кластер. Он, соответственно, должен быть установлен на веб сервере. Для Debian установка из пакетов такая:

# bash -c "$(curl -L https://setup.vector.dev)"
# apt install vector

Открываем конфиг /etc/vector/vector.yaml и приводим к такому виду:

sources:
 nginx_access_logs:
  type: file
  include:
   - /var/log/nginx/access.log
sinks:
 elastic:
  type: elasticsearch
  inputs:
   - nginx_access_logs
  endpoints:
   - http://172.30.245.222:9200

Следите за форматированием файла yaml. При копировании в пост она ломается. У вектора очень хорошая документация. Там есть все примеры использования. Можно у меня заметки на канале посмотреть. Было несколько штук с его настройкой. Очень приятная и легковесная программа. Я последнее время почти всегда вектором собираю логи.

Перезапускаем вектор:

# systemctl restart vector

По умолчанию, он пишет логи в системный syslog. Проверьте на всякий случай, что он запустился и начал отправлять логи в elastic. Идём в его веб интерфейс. Там должен появиться индекс вида vector-2024.04.22, в нём строки из лога Nginx.

Простейшие действия по управлению кластером Elasticsearch можно делать в Elasticvue. Можно обойтись и без Kibana. Вот такая простая и быстрая настройка. Если вы не отключите HTTPS и аутентификацию, то вам придётся дополнительно сделать следующее:

◽️Создать пароль для пользователя elastic через команду внутри контейнера /bin/elasticsearch-reset-password.
◽️Соответственно во всех запросах использовать basic аутентификацию с этой учёткой.
◽️Для работы Elasticvue вам нужно будет забрать сертификат Elasticsearch из /usr/share/elasticsearch/config/certs/http_ca.crt и добавить его в доверенные CA в том браузере, где вы его будете запускать. Далее нужно будет посмотреть, какие имена хоста указаны в сертификате сервера и добавить их в hosts, чтобы браузер не ругался на несоответствие имени в сертификате и адресной строке.

Я всё это настраиваю, если надо, но занимает чуть больше времени, поэтому упростил руководство.

#elk #logs

Смотрел на днях вебинар Rebrain на тему настройки ELK Stack. Дело было вечером, я доделывал свои дела и в пол уха слушал рассказ лектора. Потом переключился на вебинар и стал следить. Я, кстати, рекомендую эти вебинары. Иногда смотрю.

В какой-то момент заметил, что структура и содержание конфигов Logstash очень мне знакомы. Я для удобства разделяю параметры input, output и filter. Да и в целом всё как-то очень похоже на то, что я обычно делаю. Когда дело дошло до индексов, заметил там свои привычные шаблоны.

Лектор переместился в браузер и там я увидел вкладки со своей статьёй. Стало понятно, почему мне всё было знакомо. Статью последний раз обновлял года полтора назад. Она несильно устарела, так что ей вполне можно пользоваться.

Вчера её полностью проверил, кое-что добавил, обновил. Развернул по статье весь стек на Debian 12. Получилось в режиме copy-paste для самой свежей версии на текущий момент - 8.17.0.

Доступ к репозиториям elastic закрыт с IP адресов РФ, поэтому для того, чтобы можно было копипастом настраивать по статье, сделал свой репозиторий. Вчера же обновил его до самых свежих версий. Можно пользоваться:

⇨ Установка и настройка Elasticsearch, Logstash, Kibana (ELK Stack)
⇨ http://elasticrepo.serveradmin.ru

Если не знакомы с продуктом, то этой статьи будет достаточно, чтобы начать с ним работать. Там помимо непосредственно инструкций очень много пояснений. Возможно, они покажутся немного сумбурными. Эту статью я обновлял уже 5 раз и практически полностью переписывал 2 раза. ELK Stack очень часто обновляется и меняется. Трудно всё это увязывать в едином объёмном материале.

#elk