Меню

Elk установка и настройка



linux-notes.org

Для тех, кто не знает, Elastic стек (ELK стек) — это инфраструктурная программа, состоящая из нескольких компонентов, разработанных компанией Elastic.

  • Elasticsearch — Высокомасштабируемая поисковая система полнотекстового поиска и аналитики данных с открытым исходным кодом. Данная утилита позволяет быстро (а главное, — режиме реального времени) хранить, искать и анализировать большие объемы данных. Обычно он используется в качестве базового механизма / технологии, которая обеспечивает помощь приложениям со сложными функциями поиска.
  • Logstash — Механизм сбора событий, который обеспечивает конвейер в реальном времени. Он может принимать данные из нескольких источников и преобразовывать их в документы JSON.
  • Kibana — Утилита с открытым исходным кодом которая визуализирует работу Elasticsearch. Он используется для взаимодействия с данными, хранящимися в индексах Elasticsearch. Kibana имеет веб-интерфейс, который позволяет быстро создавать и обмениваться динамическими панелями мониторинга, отображающими изменения в запросах Elasticsearch в реальном времени.
  • FileBeat — Утилита с открытым исходным кодом, которая работает в качестве агентов на серверах, для отправки различных типов оперативных данных в Elasticsearch.

И сейчас я расскажу как можно установить сие чудо.

  • ELK — 192.168.13.195 — собственно сам сервер.
  • Filebeats — 192.168.13.150 — взял одну машину в качестве примера.

Установка ELK (ElasticSearch/Logstash/Kibana) в Unix/Linux

Я уже описывал установку некоторых компонентов и сейчас я объединю воедино. И начну с установки компонентов.

У меня не будет сильно много нод ( я не вижу смысла в этом т.к я использую ELK для тестовых целей) и я буду использовать всего лишь 1 машину. Это не столь важно, т.к можно настроить и на нескольких. Для примеров, хватит с головой.

Как будет работать ELK? А вот скриншот того как это выглядит:

Работа elk в Unix/Linux

Установка Elasticsearch в Unix/Linux

Установка хорошо расписана в моей теме:

Если ES уже имеется в системе, пропускаем данный шаг и идем далее.

Установка Logstash в Unix/Linux

Установка хорошо расписана в моей теме:

Если Logstash уже имеется в системе, пропускаем данный шаг и идем далее.

Установка Kibana в Unix/Linux

Установка хорошо расписана в моей теме:

Если Kibana уже имеется в системе, пропускаем данный шаг и идем далее.

Настройка ELK в Unix/Linux

Пришло время настроить все это дело и запустить…

-==Настройка ElasticSearch===-

Настроим «memory lock» для различных типов ОС.

Если имеется Systemd на хосте:

Сохраните и выйдите.

Открываем еще один файл:

И раскомментируйте строку (60-я строка):

Еще открываем один файл:

И перезапускаем Elasticsearch:

Если имеется SysV на хосте:

Сохраните и выйдите.

Еще открываем один файл:

И перезапускаем Elasticsearch:

Если имеется Upstart на хосте:

Еще открываем файл:

Сохраните и выйдите.

Еще открываем один файл:

И перезапускаем Elasticsearch:

Тестирование!

И проверяем чтобы было:

Проверим, открылся ли порт:

PS: Если поменяли IP, то стоит использовать именно его! И конечно же, не забываем менять все это дело в конфигурации.

-==Настройка LogStash===-

Если у вас нет DNS, то придется добавить свой собственный IP-адрес вашего ELK-сервера в subjectAltName (SAN). Это позволит вашим серверам собирать логи. И для этого, потребуется ключик.

Необходимо создать новый SSL сертификат. Сначала отредактируйте файл:

В [ v3_ca ] разделе, прописываем:

Где, localhost — Это ваш ИП адрес сервера с логстешем.

……….СПОСОБ 1 — использовать IP……….

У меня это — 192.168.13.195!

……….СПОСОБ 2 — использовать доменное имя……….

ELK_domain_name — Ваше доменное имя!

Настраиваем input, output, filter файлы для Logstash.

-===INPUT==-

И он имеет следующее содержание:

-===OUTPUT==-

И он имеет следующее содержание:

-===FILTER==-

И он имеет следующее содержание:

Проверьте файлы конфигурации Logstash:

И перезапускаем службу:

-==Настройка Kibana===-

Приводим к такому виду:

Смотрим, открылся ли порт:

Теперь установим nginx и настроим его как обратный прокси — это позволит заходить на кибану с публичного IP-адреса.

И создаем конфиг:

PS: Для более лучшей защиты, рекомендуют использовать SSL (т.к я его сгенерировал выше, можно заюзать). Под стройкой listen 80, прописываем:

Но это самоподписанный сертификат и он будет обозначен красным цветом, по этому, можно заюзать следующую статью:

Создать новый файл аутентификации:

Смотрим, открылся ли порт:

Установка Filebeat в Unix/Linux

Установка хорошо расписана в моей теме:

Как я и говорил, он служит для отправки логов на logstash. Я на этом завершаю свою статью «Установка ELK (ElasticSearch/Logstash/Kibana) в Unix/Linux».

One thought on “ Установка ELK (ElasticSearch/Logstash/Kibana) в Unix/Linux ”

А почему про kiban-у ни слова? Про нее напиши.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Источник

Elasticsearch + Kibana + Logstash на CentOS

Если в двух словах, Elasticsearch предоставляет механизм поиска, Kibana — веб-интерфейс для работы с Elasticsearch, Logstash — инструмент для сбора логов и их передачи в Elasticsearch. Таким образом, связка Elasticsearch + Kibana + Logstash (или ELK Stack) является инструментом по сбору и хранению журналов операционных систем. При этом поддерживаются разные платформы (Windows, Linux, BSD).

В данной инструкции мы рассмотрим пример установки серверной части ELK на Linux CentOS. Также мы настроим сбор логов с CentOS, Ubuntu, Windows.

Подготовка сервера

Прежде чем начать, подготовим к установке и настройке наш сервер.

1. Установка wget

В процессе установки пакетов нам понадобиться скачивать установочные файлы. Для этого в системе должен быть установлен wget:

yum install wget

2. Настройка брандмауэра

Открываем порты для работы ELK:

firewall-cmd —permanent —add-port=<5044,5601>/tcp

  • 5044порт, на котором слушаем Logstash.
  • 5601 — Kibana.

3. SELinux

Отключаем SELinux двумя командами:

sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

* первая команда выключит систему безопасности до перезагрузки сервера, вторая — навсегда.

Установка Java

Все программные продукты стека ELK разработаны на Java, поэтому не будут работать без соответствующей платформы на сервере. Для ее установки необходимо загрузить дистрибутив с сайта Oracle и выполнить его установку.

Переходим на страницу загрузки Java — на открывшейся странице принимаем лицензионное соглашение:

Читайте также:  Настройка xsplit gamecaster для стрима

После появятся ссылки на платформу — кликаем по ссылке для скачивания RPM пакета:

Нас перебросит на страницу ввода логина и пароля — необходимо авторизоваться или зарегистрироваться. После начнется процесс загрузки пакета, и когда он завершится, перекидываем файл на сервер CentOS, например, при помощи WinSCP.

Если у нас нет аккаунта на портале Oracle и нет возможности его зарегистрировать, то можно скачать более раннюю версию java командой:
curl -L -C — -b «oraclelicense=accept-securebackup-cookie» -O ‘http://download.oracle.com/otn-pub/java/jdk/8u131-b11/d54c1d3a095b4ff2b6607d096fa80163/jdk-8u131-linux-x64.rpm’

Устанавливаем скачанный пакет командой:

После окончания установки можно ввести команду:

Она должна вернуть, примерно, следующее:

openjdk version «1.8.0_212»
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)

Elasticsearch

Переходим на страницу загрузки эластика и копируем ссылку на последнюю версию пакета RPM:

. и скачиваем по ней сам пакет:

* в моем случае была версия 7.3.2.

После устанавливаем эластик на наш сервер:

rpm -ivh elasticsearch-*

Разрешаем автозапуск сервиса и запускаем его:

systemctl enable elasticsearch

systemctl start elasticsearch

Kibana

Переходим на страницу загрузки Kibana и скачиваем ссылку на последнюю вервию пакета RPM:

. и скачиваем по ней пакет для установки kibana:

Открываем на редактирование конфигурационный файл:

Редактируем параметр host:

* в данном примере мы говорим, что сервер должен слушать на интерфейсе 192.168.1.10.

Разрешаем автозапуск Kibana и запускаем ее:

systemctl enable kibana

systemctl start kibana

Открываем браузер и переходим по ссылке http:// :5601. Если мы увидим сообщение «kibana not ready yet», просто ждем создания индекса (на это может уйти до 10 минут). После снова пробуем открыть страницу.

Мы должны увидеть страницу приветствия с заголовком «Welcome to Kibana».

Logstash

Процесс установки Logstash аналогичен — переходим на страницу загрузки программного продукта, копируем ссылку на пакет RPM:

Скачиваем пакет на нашем сервере:

. и устанавливаем его:

rpm -ivh logstash-*

Разрешаем автозапуск и стартуем сервис:

systemctl enable logstash

systemctl start logstash

Настройка Logstash

Настройки для логстэша хранятся в каталоге /etc/logstash/conf.d в файлах формата JSON. Для конфигурации используются следующие секции:

  1. input (входные данные).
  2. filter (фильтры).
  3. output (выходные данные).

Для каждой из них мы создадим свой файл.

* в данном примере мы настроили logstash для приема логов на порту 5044.

Источник

Настраиваем стек ELK для централизованного хранения журналов

Архив номеров / 2018 / Выпуск №1-2 (182-183) / Настраиваем стек ELK для централизованного хранения журналов

СЕРГЕЙ ЯРЕМЧУК, сисадмин/DevOps, автор более 1000 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС, yaremchuk@samag.ru

Настраиваем стек ELK
для централизованного хранения журналов

В статье разберем, как настроить магическую тройку Elasticsearch + Logstash + Kibana

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

Проблема в том, что сервис обычно представлен несколькими подсистемами, которые относятся к серверной части (LEMP, Redis, RabbitMQ. ), и само приложение нередко состоит из микросервисов. Все может быть расположено на разных серверах, что усложняет поиск проблемы. К тому же обнаруженная ошибка могла появиться гораздо раньше (например, после последнего деплоя), но не была так явно выражена (выходные или праздники, нагрузка меньше).

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

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

Стек ELK

На самом деле, чтобы реализовать подобную схему, нужны три инструмента:

  • кто-то должен отправить данные (это может быть rsyslog или специальный агент),
  • кто-то их собирает (с предварительной обработкой),
  • и, наконец, сам анализатор.

Здесь могут быть варианты, каждый имеет свои плюсы и минусы, и очень легко запутаться с выбором. А выбирать есть из чего, реализаций агрегаторов журналов, как свободных, так и коммерческих, реализованных в виде облачного решения, предостаточно: Graylog2, Loggly, Log4j, Splunk, Logentries, PaperTrail, Fluentd, ArcSight, макрософтовское Log Analytics Azure и другие. Список на самом деле очень большой.

Очень тяжело советовать идеальную конфигурацию, часто бывает, что подходит одним, совершенно не приживается в другой обстановке, при тех же исходных данных. Но, наверное, самым популярным из Open Source-решений является стек ELK – Elasticsearch, Logstash, Kibana. Все они разрабатываются нидерландской Elasticsearch BV [1], поэтому очень хорошо работают в связке и просто настраиваются.

Рубрика: Администрирование / DevOps
Kibana – это удобный инструмент, позволяющий на порядок быстрее локализовать проблемы

Основой является поисковый движок Elasticsearch, построенный на базе библиотеки Apache Lucene, используемый для индексирования и поиска информации в любом типе документов. Язык запросов достаточно простой, хотя и потребует некоторого времени на усвоение. Для индексации большого количества данных несколько копий Elasticsearch легко объединяются в кластер.

Logtash разработан Джорданом Сисселем (Jordan Sissel) как автономный инструмент для обработки большого количества журналов из нескольких источников, а после того как Джордан присоединился в 2013 году к Elasticsearch, этот продукт стал неотъемлемой частью платформы ELK.

Поддерживается множество входных типов данных – журналы, метрики разных сервисов и служб. Полученная информация фильтруется, идентифицируется (при помощи Grok, склеивание, мутация, удаление. ), нормализуется, что упрощает дальнейшую обработку.

Результат обычно отдается в Elasticsearch (размещенный на этом же сервере или удаленной системе), но это может быть другой приемник данных – email, stdout, файл. То есть фактически вместо Elasticsearch можем использовать любое другое решение или обработчик.

Но у Logstash есть одна проблема – производительность. Он написан на Ruby и требует запуска JVM, в результате он очень любит память, особенно если задействуется много конвейеров и фильтрация.

Как результат, появился проект Lumberjack – написанное на Go приложение, представляющее легкую реализацию сборщика журналов и отправку на удаленный хост. Со временем проект переименовали в Logstash-Forwarder, вторая версия протокола стала основой нового семейства форвардеров под названием Beats – специальных клиентов, обеспечивающих сбор и отправку данных в Logstash.

В частности, за сбор данных с журналов отвечает Filebeat, причем современные версии позволяют производить предварительную фильтрацию. Кроме этого, также доступны Winlogbeat (сбор событий Windows Event Logs), Metricbeat (метрики), Packetbeat (сетевая информация) и Heartbeat (uptime). Все клиенты доступны для платформ Linux, Windows и Mac OSX. В статье разберем, как настраивать Filebeat.

И, наконец, Kibana – это веб-интерфейс для вывода индексированных Elasticsearch логов. Кстати, изначально Kibana была привязана к данным именно Logstash и только после перехода разработчика Rashid Khan в Elasticsearch переориентирована на информацию, выводимую Elasticsearch. При помощи веб-интерфейса можно отбирать нужную информацию для анализа. Причем доступны не только сами записи, но на их основе можно строить разные графики и таблицы. При установке дополнительного X-Pack будут доступны отчеты, визуализация геоинформации, мониторинг, алерты, интеграция с LDAP и многое другое. Предлагается X-Pack под несколькими лицензиями [2], есть и Free.

Настройка Filebeat

Нужно отметить, что с установкой и обновлением всех продуктов линейки проблем нет. Доступны как apt и yum-репозитории, так и deb и rpm-файлы. В сети есть готовые плейбуки для Ansible и других систем управления конфигурацией. Причем очень удобно – в репозитории можно найти абсолютно любую версию, когда-то выпущенную командой. Обновление вверх обычно происходит без проблем, старые индексы подхватываются с лета. Проблема может быть в несовместимости параметров в конфигурационных файлах. А вот вниз далеко откатить уже не всегда возможно, старая версия не видит новых индексов. Актуальной версией является 6.1.2, но я пока использую 5.6, поэтому буду ориентироваться на нее. Хотя существенных отличий нет.

Подключаем репозиторий и ставим пакеты:

Сервис помечен как enable для автозапуска, но в Ubuntu 16.04 для всех продуктов от Elasticsearch почему-то это не происходит.

Все настройки производятся в конфигурационном файле /etc/filebeat/filebeat.yml, после установки уже есть готовый шаблон с минимальными настройками. Там же лежит файл filebeat.full.yml (в новой версии filebeat.reference.yml), в котором прописаны все установки, доступные для Filebeat [3].

В файле для Filebeat нужно указать, что брать и куда отправлять. При этом указываются тип документа (input_type, log_type и document_type, он потом будет доступен в поиске) и специфические параметры подключения. По умолчанию Filebeat собирает все файлы в пути /var/log/*.log, то есть все файлы в каталоге /var/log, заканчивающиеся на .log.

Очень удобно, что поддерживаются шаблоны, поэтому можно задать что-то вроде /var/www/microservices/*/shared/var/logs/*.log и не беспокоиться при появлении нового микросервиса, что его журналы не попадут в Filebeat. Тип указывает на характер данных – log, redis, docker stdin, udp. Дополнительные опции позволяют отобрать определенные файлы и события. Так, параметр exclude_files позволяет задать шаблон файлов, которые не нужно собирать. По умолчанию экспортируются все строки, используя include_lines и exclude_lines, задаются или исключаются строки из сбора. Их можно указывать в как общем для всех, так и для каждого paths.

Если определены оба варианта, Filebeat сначала выполняет include_lines, а затем exclude_lines. Порядок, в котором они прописаны, значения не имеет. Кроме этого, в описании задаются при необходимости кодировка, теги, поля и тип документа.

Источники с одинаковыми input_type, log_type и document_type можно указывать по одному в строке. Если они отличаются, то создается отдельная запись. Создадим запись, собирающую ошибки nginx, и укажем поле nginx_error, которое затем будем использовать в фильтрах.

Раздел Outputs файла указывает, куда нужно отдавать данные. В шаблоне уже есть установки для Elasticsearch и Logstash. Мы отправляем в Logstash, минимально нужно указать только адрес и порт.

Если соединяемся через небезопасную сеть, необходима авторизация по ключу.

В случае появления в журнале /var/log/filebeat/filebeat записи:

ERR Connecting error publishing events (retrying): read tcp i/o timeout

следует поиграть параметрами filebeat.spool_size, timeout, bulk_max_size, slow_start, max_retries.

В конце настраивается ротация журналов:

Для проверки работы можно использовать шаблон:

Настраиваем Logstash

Для Logstash и Elasticsearch нужна Java. Это может быть как официальная Java SE или OpenJDK, имеющаяся с репозиториях дистрибутивов Linux. Но здесь есть нюанс. Сам Elasticsearch отлично ладит с Java 9, а вот для Logstash придется использовать Java 8. Репозиторий добавляется так же.

Конвейер Logstash имеет два обязательных элемента – input и output – и необязательный – filter. Плагины ввода берут данные из источника, выходные записывают по назначению, фильтры изменяют данные по указанному шаблону.

Флаг -e позволяет указать конфигурацию непосредственно в командной строке, что можно использовать для тестирования.

Простой конвейер выглядит так:

То есть просто выводим то, что пришло на stdin, Logstash продублирует, добавив метку времени.

Все конфигурационные файлы находятся в /etc/logstash. Настройки в /etc/logstash/startup.options, jvm.options определяют параметры JVM и в logstash.yml параметры работы самого сервиса. Важный момент. По умолчанию количество воркеров, обрабатывающих запросы, привязано к количеству CPU. Это можно изменить при помощи параметра pipeline.workers в конфигурационном файле, но в случае проблем с производительностью это может не помочь. Нужно просто добавить еще CPU. Ну и поиграть с другими pipeline-параметрами, в частности:

Сами конвейеры описываются в файлах в каталоге /etc/logstash/conf.d. Он пока пуст. При запуске считываются все файлы, поэтому их можно компоновать как удобно. Очевидны два варианта: файлы по назначению (input, output и filter) или каждый сервис описывать в отдельном файле. Описания плагинов для inputs, outputs и filter, обеспечивающих ту или иную функцию (beats, file), доступны на сайте [4]. После установки в системе уже есть некоторые плагины. Их список можно получить при помощи специальной команды.

Или конкретная группа:

Рисунок 1. Проверяем список плагинов

Периодически их можно обновлять, хотя обычно все обновления приходят с новой версией, а версии выпускаются достаточно часто. Но тем не менее могут быть ситуации, когда это понадобится.

Этой же командой добавляются и собственные плагины.

Указываем порт, на котором будем принимать подключение Filebeat.

Как уже говорилось, Logstash может самостоятельно собирать информацию журналов локального узла.

Отдаем данные на Elasticsearch.

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

И далее фильтры. В Logstash их тоже около 50, все варианты расписаны в документации [5], наиболее популярный, наверное, Grok, при помощи которого можно отобрать любые неструктурированные данные, причем без особой подготовки. Создаем для примера файл, который будет обрабатывать данные с типом nginx-access.

Рисунок 2. Фильтр Grok, при помощи которого можно отобрать любые неструктурированные данные

Если сравнить c любым сообщением из файла ошибок nginx, то станет очевидно, как создается такой шаблон.

2018/01/30 16:53:25 [error] 1167#1167: *57846 rewrite or internal redirection cycle while internally redirecting to «/index.html», client: 192.168.1.148, server: *.example.org, request: «GET //phpMyAdmin/scripts/setup.php HTTP/1.1»

Logstash после установки уже содержит приблизительно 120 шаблонов буквально на все случаи, и обычно с нуля писать ничего не нужно. Просмотреть варианты можно в github проекта [6]. Свои правила лучше прописать в отдельном файле, задав уникальное имя. На место нахождения каталога с правилами указывает переменная patterns_dir:

Для проверки корректности правил можно использовать сайт [7], там же можно поискать еще готовые паттерны.

Убеждаемся в журналах, что все работает.

[INFO ][logstash.inputs.beats ] Beats inputs: Starting input listener <:address=>«localhost:5044″>

[INFO ][logstash.pipeline ] Pipeline main started

[INFO ][logstash.agent ] Successfully started Logstash API endpoint <:port=>9600>

Устанавливаем Elasticsearch

Важно: для эластика, возможно, потребуется место. В нашем случае данные за полгода для боевого кластера спокойно умещались в 150 Гб, с переходом на микросервисы объем пришлось увеличить до 1 Тб. Установка стандартна. По умолчанию данные размещаются в /var/lib/elasticsearch, но этот путь можно изменить при помощи переменной path.data.

По умолчанию Elasticsearch слушает локальный 9200-й порт. Большинство операций выполняется при помощи обычного curl.

В большинстве случаев лучше так и оставить, для кластера или в случае другой необходимости можно указать внешний IP и изменить порт, если он уже занят.

В общем, поначалу здесь можно ничего не трогать, а приступить к изучению настроек в случае проблем с производительностью. Файл хорошо комментирован, плюс документация. Не без экспериментов, но все настраивается прекрасно. Нужно помнить, что Elasticsearch любит ОЗУ (по умолчанию запускается 2 Гб -Xms2g -Xmx2g), в зависимости от возможности сервера и данных в процессе эксплуатации параметры скорее всего нужно будет переопределить в /etc/elasticsearch/jvm.options. Но больше 50% ОЗУ отдавать не рекомендуется. Это все. Эластик начал индексировать данные.

Список актуальных индексов можно получить при помощи запроса:

Чтобы удалить ненужный индекс выполняем:

Для постоянной чистки индексов лучше использовать elasticsearch-curator, который также есть в репозитории.

Настройки работы хранятся в файле /etc/curator/curator.yml. Там описывается подключение к Elasticsearch, и, в общем, его можно не трогать. Далее индекс можно чистить как из командной строки, так и создав готовые настройки. Например, для удаления индексов logstash-*, filebeat-* старше 90 дней подготовим такой файл:

Прописываем запуск в crontab, и нам остается только следить за местом на жестком диске:

Настройка Kibana

С Kibana то же самое.

По умолчанию Kibana стартует на localhost:5601. Изменив параметр server.host в файле /etc/kibana/kibana.yml, можно разрешить подключаться удаленно, но так как какой-то аутентификации не предусмотрено, лучше в качестве фронта использовать nginx, настроив обычный proxy_pass и доступ с htaccess. Ну, или посмотреть в сторону X-Pack.

Все. Можно смотреть. Kibana пока ничего не знает об индексах. Нужно указать, что будем искать, для работы нужно указать хотя бы один индекс (индекс по умолчанию). Идем в Management → Index Patterns. Обычно нужно некоторое время подождать, затем указать новый индекс (см. рис. 3). Для filebeat пишем filebeat-*, можно использовать -*. Кибана подхватит шаблон и покажет поля.

Рисунок 3. Настраиваем индекс

Теперь в разделе Discover начнут появляться записи (см. рис. 4).

Рисунок 4. Записи журналов в Kibana

По умолчанию отображаются последние 15 минут, изменить время можно в правом верхнем углу. Выбрав сообщение, можно посмотреть подробно.

Справа отображаются поля. Если выбрать любое, оно будет использовано как фильтр поиска. Таким образом, можно указать файл, сервер, статус запроса и т.д. Далее в строке поиска указываем, что ищем, в самом простом случае только пишем текст (см. рис. 5), на временной метке также будет показано, когда появилась нужная запись. В более сложных случаях придется все-таки прочитать документацию [8].

Рисунок 5. Выполняем запрос

Запросы можно сохранять для повторного использования и для вызова графиков Visualize. Здесь просто. Нажимаем Create new visualization, выбираем тип и сохраненный запрос.

Для удобства из визуализаций создаем Dashboard, на котором будут показаны все данные.

Проект предлагает готовые Dashboard [9], которые можно взять за основу.

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

Ключевые слова: elasticsearch, kibana, logstash, filebeat, журналы.

Источник

Adblock
detector