В предыдущей части я рассказала о своем знакомстве с программным стеком ELK (elasticsearch-logstash-kibana), подробно расписав процесс установки и базовой настройки этих сервисов с учетом разного рода непредвиденных обстоятельств и неочевидных тонкостей, от которых зависит то, будет ли у вас работать что-то или нет. По итогам этих экспериментов, мне удалось поднять собственный сервер elasticsearch с графической оболочкой, реализуемой kibana, однако, впереди оставалась не менее значительная часть работы, призванная вдохнуть в развернутую систему немного функциональности, а именно сбор системных логов с хоста.
Собственно, именно об этом и пойдет речь во второй части статьи - и на этом маршруте нас поджидает ничуть не меньше приключений.
Постановка задачи
Исходя из поставленной мной задачи, сбор системных логов должен был осуществляться посредством Fleet (дословно: "флот"), работающего в связке с elasticsearch и kibana. Последний играет роль дополнительного сервиса для управления "флотом" агентов, ответственных за сбор системных логов, и последующей передачи их в elasticsearch.
Отчасти, приятной стороной вопроса здесь является то, что изрядная доля взаимодействий с агентами производится через красивый GUI kibana, а не привычный терминал Linux, что может порадовать тех, кто еще не вполне свыкнулся с консольным интерфейсом данной ОС.
1. Знакомство с Fleet Server
Что же, заходим в kibana (напоминаю, что для этого необходимо вбить в поисковую строку URL http(s)://адрес-хоста:5601, где 5601 - порт, используемый kibana по умолчанию) с учетной записью суперпользователя и проматываем страницу в са-а-амый низ - говоря точнее, здесь нас будет интересовать одноименная вкладка Fleet.
Как я уже упоминала ранее, с технической стороны вопроса агенты Fleet "живут" на отдельном от elasticsearch (9200-й порт) и kibana (5601-ый) порту, поэтому первое, что было мне предложено по открытию данной вкладки - это поднять еще один сервер. Жму Add Fleet Server.
Здесь, программа предлагает задать адрес, по которому будет расположен Fleet Server - в моем случае оставляю localhost и 8220-ый порт, используемый по умолчанию.
Затем, происходит автоматическая генерация команд, которые только то и надо-то, что вбить в терминал:
1.2. Первые трудности
Казалось бы, что может пойти не так?.. Однако, уже на первой из предложенных команд процесс "встает":
Давайте разбираться, что, собственно, здесь происходит. В данном случае предполагается, что команда curl совершает запрос по указанному URL с намерением скачать некий архив elastic-agent-8.17.0-linux-x86_64.tar.gz, после чего файл передается на последующую распаковку архиватору. Тем не менее, gzip жалуется, что установленный файл не является архивом вовсе.
Хм... Если не архив, то что это тогда? Неужели ошибка на стороне разработчика, подсунувшего "битый" файл? Для того, чтобы разобраться с этим, пытаюсь перейти по указанному URL через обычный браузер:
В качестве ответа с сервера приходит ошибка 403 - "Отказано в доступе". И тут-то я и вспоминаю, что доступ к официальному репозиторию перекрыт.
1.3. Решение проблемы с блокировкой официального репозитория
Читатель может вспомнить, что в прошлый раз проблема обхода блокировки официального репозитория была решена посредством скачивания недостающих пакетов с "зеркала". Однако, загвоздка состояла в том, что на этот раз, в отличие от elasticsearch и kibana, нужного файла на "зеркале" не нашлось.
Ну да когда это кого-либо останавливало?
Решение проблемы с блокировкой "стандартными средствами" плохо работает в случае с виртуальной машиной, смотрящей на мир через NAT хоста, фактически играющего роль прокси-сервера: попросту говоря, какие бы локальные IP-адреса не были бы присвоены самой ВМ, улетающие в глобальную сеть пакеты все равно будут иметь source address хоста, что сводит все усилия на "нет". Ну а поскольку поднимать еще и виртуальный адаптер мне не хотелось, мною была предпринята следующая последовательность действий:
1. Перекидываю ссылку на целевой файл в систему хоста;
2. Скачиваю архив через браузер хоста со всеми необходимыми расширениями;
3. Выгружаю архив на облако;
4. На виртуальной машине Ubuntu скачиваю архив с облака;
5. Перехожу в папку со скачанным архивом и благополучно распаковываю его содержимое.
На этот раз все хорошо:
1.4. Установка Fleet Server
На следующем этапе нам предлагается перейти в разархивированную папку (cd elastic-agent-8.17.0-linux-x86_64) и запустить непосредственную установку программы с ранее сгенерированными параметрами:
Хм, пока что все хорошо... Отдельным образом хотелось бы обратить внимание на то, что Fleet был не только успешно установлен (installed) на машину, но и благополучно встроен (enroll) в систему. Но давайте посмотрим, что скажет kibana.
1.5. Если установка соединения не подтверждается
Заключительным шагом по встраиванию Fleet в ранее развернутую систему является подтверждение установки соединения со стороны kibana. Теоретически, это должно происходить автоматически сразу после запуска службы, однако, коль скоро ожидание затягивается слишком долго, мы можем "помочь" нерасторопному агенту командой elastic-agent enroll с тем же набором параметров, что и при первоначальной установке.
2. Добавление агентов
К сему моменту нам удалось развернуть "посадочную площадку" для "флота" агентов, но не создали их самих - и на данном этапе было бы неплохо определиться с тем, что же, собственно говоря, подразумевается под понятием агента.
Согласно официальной документации elasticsearch, elastic-agent является "универсальным инструментом для сбора логов, метрик, отладочных данных, сведений о доступности, безопасности и других данных с каждого хоста единым универсальным способом" (collect logs, metrics, traces, availability, security, and other data from each host in a single unified way).
Честно говоря, это гораздо больше напоминает перечень исполняемых функций, нежели определение, однако, ничего лучшего мне найти не удалось, поэтому давайте посмотрим, что это значит на практике.
2.1. Задание политик
На следующем шаге kibana задает вопрос о том, чего мы хотим от агента - то есть, какие именно логи и/или события должен отслеживать данный агент, после чего полученная информация будет записана в файл Политик агента. По умолчанию, агенту поручается следить за основные системными событиями (system). В рамках данной практики меня это вполне устраивает, поэтому оставляю как есть.
2.2. Установка(?) агента
На следующем этапе мне было снова предложено выполнить набор автосгенерированных команд в терминале, а именно:
То есть, требовалось скачать и распаковать еще один архив, после чего запустить содержащийся в нем исполняемый файл с указанным набором параметров. Честно говоря, здесь с самого начала несколько смущает тот факт, что оба архива имеют совершенно одинаковые имена с точностью до версии - и, более того, добросовестно повторив всю громоздкую процедуру по скачиванию требуемых файлов (см. выше), при попытке выполнения команды я получила ошибку:
... что лишь окончательно подтвердило мои догадки о том, что архивы более или менее равнозначны друг другу. Поэтому я вернулась в прежнюю директорию с успешно установленным elastic-agent и принялась работать с ней.
Тем не менее, мне все равно пришлось еще кое-что подправить, а именно:
- Поскольку elastic-agent уже был установлен, заново install его не нужно - надо enroll;
- Ввиду отсутствия доверенных сертификатов для установки соединения потребовалось добавить флаг --insecure.
По меньшей мере, теперь kibana видит агента - остается лишь дождаться первой партии отправляемых им данных:
3. Еще кое-что об Fleet Server Policies
Покуда я дожидалась поступления каких-бы то ни было вестей от вновь созданного агента, было решено посмотреть, на сбор каких именно логов он рассчитан - ведь, в конечном счете, вполне могло статься, что нужное событие еще попросту не произошло. Для этого возвращаюсь в раздел с Политиками сервера Fleet>Agent Policies>Fleet Server Policies>Edit Integration:
Помимо тривиальных возможностей задания кастомного имени и описания вышеобозначенной Integration, открывшееся меню позволяет указать конкретные директории, откуда должен производиться сбор логов.
На приведенном скриншоте видно, что стандартные настройки агента включают в себя сбор логов об аутентификации/попытке аутентификации в систему наряду с прочими событиями безопасности, а также разнообразные системные события.
Пожалуй, пока что меня все устраивает.
Также, можно настроить работу с JournalID, сбор логов Windows и вспомогательных метрик, что, впрочем, не представляло особого интереса в рамках моей текущей задачи - по меньшей мере, мне удалось удостовериться в том, что теоретическая выборка данных, отправляемая агентом на сервер, будет достаточно велика.
4. Мониторинг логов
Настало время проверить, как там поживает агент. Возвращаясь во вкладку Fleet, вижу, что интересующая меня сущность помечена как "Healthy" - то есть, благополучно установившая соединение с сервером и исправно функционирующая.
Теперь давайте посмотрим, что интересного успел собрать elastic-agent к текущему моменту. Все собранные логи хранятся в разделе Observability>Logs>Logs Explorer.
Пожалуй, данных набралось порядочно:
4.1. KQL
Пожалуй, остается единственная проблема, а именно навигация по собранным данным. Как я уже упоминала в первой части этого материала, собственно elasticsearch являет собой нечто вроде СУБД, то есть системы для хранения, управления и навигации по различным логам и событиям - и, подобно тому, как для "обычных" баз данных существует специальный Structured Query Language (SQL), "язык структурированных запросов", kibana предусматривает собственный формат обращения к БД, получивший немудреное имя Kibana Query Language (KQL).
Если совсем коротко, то структура KQL-запроса сводится к формату [поле]: [значение], возможно, соединенных логическими операторами AND, OR, NOT и им подобными. Также, можно использовать оператор сравнения и регулярные выражения.
Условно говоря, здесь я хочу посмотреть все информационные (message: info) или предупреждающие (message: warning) сообщения, относящиеся к процессам, запущенным НЕ суперпользователем (AND NOT (user.id: "0")):
Наконец, каждое отдельное событие можно развернуть (ма-аленькая кнопочка со стрелкой рядом с полем @timestamp) и изучить более подробно:
Резюме
В продолжение двух последних статей мною был описан процесс развертывания простой ELK-системы.
Набила кучу шишек, прошлась по всем возможным граблям, но, в, конечном итоге, добилась желаемого результата и чертовски довольна собой.
В этой серии статей мною ставился акцент на том множестве вещей, которые способны пойти "не так" - просто потому, что именно в этом, на мой взгляд, состоит одно из жизненно необходимых качеств в IT: умение сесть и разобраться там, где на первый взгляд "ничего не работает" и идет в разрез с документацией.
Ну, а еще читать тяжеловесные технические руководства, гуглить и искать информацию даже, если нужные сведения не отображаются в коротенькой сводке от нейросети.
Разумеется, все изложенное мной выше охватывает лишь малую толику возможностей ELK, изучению которых предполагается посвятить последующие досужие часы.