Настройка graylog для linux

Обновлено: 05.07.2024

Привет! Это вторая часть статьи, в которой мы будем разбирать практическое применение платформы Graylog.

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

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

Настраиваем сбор логов с сервера

Работаем в web-интерфейсе:

Начнем со сбора syslog

Создаём UDP Input для системных логов:

System/Overview → Inputs

Выбираем тип Input-а:

Select input → Syslog UDP

(Будем использовать UDP, но если кому-то удобнее использовать tcp - почему бы и да)

Нажимаем кнопку Launch new input.

Внимание!

Остальные значения можно оставить по умолчанию:

Сохраняем конфигурацию, получаем работающий Input:

Для проверки работы Input выполним со своей рабочей станции или с любого другого хоста с linux/mac:

Настройки для сервера с которого собираем логи:

Уменьшаем количество логов

В CentOS 7 в /var/log/messages, как правило видим много спама, примерно такого:

Передаём логи в Graylog:

Если передаём данные по UDP, как сейчас настроено в инпуте Graylog-а:

Но если нужно по TCP, добавляем ещё одну “@”:

После редактирования делаем рестарт сервиса:

Проверяем наличие данных от хоста в Graylog-е.

На этом настройку сбора syslog считаем завершённой. На случай чрезвычайных ситуаций, или просто для информации, полезны будут оповещения о событиях (ошибках дисков, нехватке памяти, логинах, etc).

Настраиваем оповещения

Для примера - отловим приход oom-killer-а c уведомлением в Slack:

Alerts → Alerts & Events → Get Started!

Шаг 1: “Event Details”:

Title: oom-killer invoked

Description (Optional): oom-killer was invoked on server or virtual machine

Шаг 2: “Filter & Aggregation”:

Condition Type: Filter & Aggregation

Search Query: "oom-killer"

(Тут правила построения запроса)

Streams (Optional): All messages

Search within the last: 10 minutes

Execute search every: 10 minutes

Устанавливаем чекбокс Enable

Create Events for Definition if… Filter has results

Если в логах уже есть такое событие, можно будет наблюдать его в Filter preview.

Шаг 3: "Fields" - не используем.

Шаг 4: "Notifications" → Add Notification:

Choose Notification: Create New Notification.

Title: Slack notification

Notification Type: Slack Notification

Configuration Color: можно выбрать цвет

Остальные настройки можно оставить по умолчанию.

В Notification Settings ничего изменять не будем:

Шаг 5: "Summary": Ещё раз удостоверимся что настройки верны.

Нажимаем Done.

Тестируем оповещение. На хосте, с которого собираем syslog пишем маленькую программку на С:

Компилируем и запускаем. Скрипт занимает всю доступную память, после чего приходит oom-killer и его убивает:

В /var/log/messages можем наблюдать данный процесс:

Graylog Sidecar

Graylog может собирать также логи сервисов, и вообще практически любые логи.

Будем использовать Graylog Sidecar для управления конфигурацией и бэкенд Filebeat, который собирает события и отправляет на Graylog-сервер. Схема работы для данного кейса:

Мы будем работать с access-логами веб-сервера nginx, работающего под CentOS linux.

Готовые контент-паки для различных сервисов (apache, nginx, …) различной степени свежести есть тут.

Но, чтобы разобраться как всё работает мы пойдём своим путём.

Получаем токен

System → Sidecars:

Нажимаем на ссылку:

Do you need an API token for a sidecar? Create or reuse a token for the graylog-sidecar user

Ранее созданные токены также можно найти по этой ссылке.

Вводим имя токена:

Token Name: myToken

Нажимаем кнопку Create Token

Там же можно скопировать его в буфер обмена, если нужно кнопкой Copy to clipboard, предварительно убрав чекбокс Hide Tokens.

System → Inputs:

Выбираем тип инпута Beats, жмём Launch New Input

Настройка в данном случае практически не отличается от той, что делали для syslog

Устанавливаем чекбокс Global:

Bind address: 0.0.0.0

Остальное оставляем по умолчанию (разумеется, в продакшн-среде, особенно при передаче сенситивных данных нужно будет добавить SSL-сертификаты, но пока обойдемся без них).

Нажимаем кнопку Save.

Не забываем добавить правило для 5044/tcp в Firewall.

Также нужен будет 443-й порт, но он у нас уже должен быть открыт:

System → Sidecars → Configuration

В секции Configuration нажимаем кнопку Create Configuration:

Configuration color: можно выбрать желаемый цвет

collector: filebeat on linux

Configuration редактируем следующим образом

(paths - путь, где лежат лог-файлы сервиса,
hosts - ip-адрес и порт graylog-сервера):

Нажимаем кнопку Create:

Далее необходимо установить менеджер конфигурации и коллектор на хосте, с которого будет производиться сбор логов:

Sidecar

Обязательно, вносим в файл конфигурации строки:

filebeat

Не забываем про правило firewall с соответствующим портом, если это необходимо:

Теперь Sidecar должен быть виден в System → Sidecars → Overview

Назначим созданную конфигурацию на этот Sidecar.

Нажимаем кнопку Administration:

filebeat → Configure → выбираем нужную конфигурацию:

В открывшемся поп-апе подтверждаем, что всё верно → Confirm:

Контролируем статус - Running.

Идём в System → Inputs, на инпуте graylog-sidecar нажимаем Show received messages,

наблюдаем логи nginx:

Extractor

Просто хранение лога - не та задача к которой мы шли. Нам нужно парсить и анализировать эти логи!

System → Inputs → Manage extractors

В секции Add extractor нажимаем единственную кнопку - Get started

Выбираем нужный Sidecar, затем нажимаем кнопку Load Message

id здесь 6dfdda90-ad89-11eb-9611-5254007a7f25, index - graylog_0

На поле message нажимаем Select extractor type → Grok pattern

Лог nginx по умолчанию имеет формат (можем найти его в nginx.conf):

Grok pattern будет выглядеть так:

Нажимаем Try against example и в Extractor preview проверяем правильность паттерна:

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

Condition: Always try to extract

Extraction strategy: Copy

Extractor title: nginx combined

Нажимаем Create extractor

Переходим в меню System → Inputs → Show received messages, в инпуте graylog-sidecar.

Теперь все новые логи будут содержать отдельные поля message:

Поиск по логам стал намного проще, например:

При составлении запроса Graylog подсказывает параметры, что довольно удобно:

Также будет полезно создать Stream (поток).

Он нам нужен будет в дальнейшем:

Streams → Create stream

Description: Nginx access logs

Index Set: Default index set

Сохраняем кнопкой Save

Stream создан, но пока неактивен.

Добавляем правило для этого потока (кнопка Manage Rules):

Выбираем нужный Input, создаём правило (кнопка Add stream rule).

В поп-апе New Stream Rule:

Type: match input

Сохраняем кнопкой Save.

Правило добавлено, сохраняем кнопкой I’m done!:

Запускаем поток: Start stream.

Немного бесполезного, но красивого

На этапе установки, в первой части статьи мы прикрутили к graylog-у базу geoip.

Теперь посмотрим, как её использовать, а также выведем карту мира, визуально демонстрирующую, откуда к нам на сайт приходят посетители.

Создаём data adapter

System → Lookup Tables → кнопка Data Adapters → Create data adapter:

Data adapter type → Geo IP - MaxMindTM Databases

Description: GeoIP Lookup Table

File Path: /etc/graylog/server/GeoLite2-City.mmdb

Database type: City database

Остальное по умолчанию.

Для завершения нажимаем кнопку Create adapter.

Когда результаты кешируются - всё становится лучше

Создаём Caches:

System → Lookup Tables → кнопка Caches → кнопка Create cache

Cache Type: Node-local, in-memory cache

Description: GeoIP Cache

Остальное можно оставить по умолчанию.

Нажимаем кнопку Create Cache:

Создаём Lookup table:

System → Lookup Tables → Lookup Tables (активна по умолчанию) → Create Lookup Table

Description: GeoIP Lookup

Data Adapter: GeoIP (geoip)

Cache: GeoIP (geoip)

Нажимаем кнопку Create Lookup Table:

System → Pipelines → кнопка Manage rules → кнопка Create Rule

Description: Incoming connections

Нажимаем кнопку Save&Close.

Теперь пайплайн:

System → Pipelines → кнопка Manage pipelines → кнопка Add new pipeline

Description: Incoming connections

Нажимаем кнопку Edit connections, подключаем:

А также в Stage 0 нажимаем Edit и добавляем к нему правило:

Проблема - ничего не происходит. Никаких гео-тегов не видно.

Проблема возникает из-за порядка обработки правил.

Идём в System → Configurations

По умолчанию так:

1 AWS Instance Name Lookup

2 GeoIP Resolver

3 Pipeline Processor

4 Message Filter Chain

А нам нужно так:

1 AWS Instance Name Lookup

2 GeoIP Resolver

3 Message Filter Chain

4 Pipeline Processor

Нажимаем кнопку Update, перетаскиванием располагаем правила в правильном порядке:

Теперь будем смотреть красивую карту:

В Streams → Sidecars добавляем Aggregation:

Нажимаем Edit:

Visualization type: World Map

Сохраняем: Save

Теперь можно визуально оценить откуда к нам на сайт приходят посетители:

На этом всё, надеемся, что данная информация будет вам полезна.

Данная статья изначально появилась в виде заметки / howto для внутреннего использования, поэтому может местами быть немного запутанной. Ждем ваши вопросы, предложения и замечания в комментариях!

Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.

В первой статье этого цикла я рассказал, как и почему мы выбрали опенсорсный Graylog2 для централизованного сбора и просмотра логов в компании. В этот раз я поделюсь, как мы разворачивали грейлог в production, и с какими столкнулись проблемами.

Напомню, кластер будет размещаться на площадке хостера, логи будут собираться со всего мира по TCP, а среднее количество логов — около 1,2 Тб/день при нормальных условиях.

В настоящее время мы используем CentOS 7 и Graylog 2.2, поэтому все конфигурации и опции будут описываться исключительно для этих версий (в Graylog 2.2 и Graylog 2.3 ряд опций отличается).

Планирование размещения

Итого у нас есть 6 серверов Hp DL380p Gen8, 2x Intel Octa-Core Xeon E5-2650, 64 GB RAM, 12x4TB SATA. Это стандартная конфигурация хостера. Диски мы разбили так: 1 диск под систему, монгу и журнал грейлога, остальные — в 0 рейд и под хранилище эластика. Так как репликация происходит на уровне самого эластика, другие рейды нам нужны не сильно.

Сервера распределены следующим образом:

на первых 4-х: HAproxy, elasticsearch, graylog, mongod, keepalived, cerebro;
на оставшихся 2-х только elasticsearch и graylog.

в DNS указаны 2 адреса, которые обычно находятся на 1 и 2 нодах;
между 1-3 и 2-4 настроен HAproxy, чтобы в случае падения ноды адрес поднимался на другой ноде;
дальше каждая нода при помощи HAproxy раскидывает трафик по всем нодам грейлога;
грейлог в свою очередь тоже балансирует обработку логов по нодам.

Первоначальная настройка

Первоначальная настройка Graylog2 довольно проста и банальна, поэтому я всем просто крайне советую действовать по официальным инструкциям:

В server.conf грейлога на первом этапе мы указали:

Дальше нужно потюнить хипсайз эластика в файле /etc/sysconfig/elasticsearch (в доке рекомендуют 31 Гб):

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

Хранение и сборка логов, права доступа

Пришло время настроить наш грейлог и начать получать данные. Первое, что нам необходимо — это определиться с тем, как мы будем получать логи. Мы остановились на GELF TCP — он позволяет конфигурировать коллекторы через веб-интерфейс (покажу чуть ниже).

Настраиваем наш первый инпут. В веб-интерфейсе System/Inputs слева вверху выбираем GELF TCP и потом Launch new input:

Global. Говорит о том, что инпут будет поднят на всех нодах.
Title. Как будет называться инпут.
Bind address. На какой адрес будет байндиться наш инпут (в нашем случае это 0.0.0.0, потому что на всех нодах разные адреса).
Port. Тут нужно помнить, что у нас перед инпутами стоит HAproxy как балансировщик, соответственно, сюда вписываем порт, на который будет перенаправлять балансер.
Receive Buffer Size, Decompressed size limit и Maximum message size. Подбирается исходя из конкретных случаев.
Настройка ssl по желанию.

Мы поделили всё на проекты и логически связанные сервисы внутри проектов, а потом поделили на количество логов, которое нам необходимо хранить. Лично мы часть логов храним 14 дней, а часть — 140.

Хранение данных происходит в индексах грейлога. Индексы в свою очередь делятся на шарды. Шарды бывают праймари и реплика. По умолчанию данные пишутся в праймари шарды и реплицируются в реплику. Реплицируем мы только важные индексы. Большие индексы у нас имеют 2 праймари шарды и по одной реплике, что гарантирует выход из строя 2-х нод без потери данных.

Давайте создадим индекс который будет иметь 2 шарда и 1 реплику и будет хранить их логи 14 дней.

Идём в System\Indices, там нажимаем Create index set:

Title и Description. Тут всё ясно — имя и описание.
Index prefix. Какой префикс в эластике будут иметь индексы (обычно как-то отражает название самого индекса в грейлоге).
Analyzer. Мы не меняем.
Index shards. Количество шардов (мы хотим иметь 2 праймари шарда, поэтому тут надо поставить 2).
Index replicas. Количество реплик каждого шарда оставляем 1.
Max. number of segments. Обычно мы не оптимизируем шарды, поэтому оставляем 1.

Select rotation strategy — Index Time.
Rotation period (ISO8601 Duration). Есть в документации, мы оставляем P1D, что говорит: один индекс — один день.
Select retention strategy — Delete index. Будем удалять старые индексы.
Max number of indices. Максимальное количество индексов, ставим 14, что в данном случае говорит о том, что будет храниться 14 индексов по 1 дню.

1. Создание стрима.

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

Теперь у нас есть инпут, который принимает логи; индекс, который их сохраняет; и стрим, который по сути собирает много логов в одно пространство.

Дальше настраиваем отправку логов в сам грейлог.

Настройка агентов

Путь настройки агентов описан здесь. Работает это всё следующим образом: на клиенте ставится Graylog Collector Sidecar, который управляет бэкендом сборщика логов (в нашем случае для линукса и винды это — nxlog).

Подготовим правила сборки логов System\Collectors\Manage Configurations. Создаём конфигурацию и переходим к её настройке, там сразу переходим на вкладку NXLog. Видим 3 поля: Output, Configure NXLog Inputs и Define NXLog Snippets. Это всё кусочки конфигов этого самого NXLog’a, которые будут коллектором забираться на конечные ноды. Отсюда мы будем управлять полями и их значениями, а также файлами, которые мы будем мониторить и т.д.

Начнём с тегов. Вбиваем теги, по которым клиент будет понимать, какую конфигурацию ему нужно забрать.

Поле Output, тут одна конфигурация:

Name. Тут всё ясно — имя, по которому мы поймём, что это.
Type. В нашем случае это TCP.
Server IP. Тут указываем адрес, куда отправлять логи (в нашем случае это днс, имя которое разрешается в 2 адреса).
Port. Как помним, у нас используется балансировщик — на входе мы указываем порт именно балансировщика, который в свою очередь раскидает на ноды грейлога.
Дальше включаем буфер на хосте.
И не перезаписываем хостнейм.
Additional Fields. Тут добавляем дополнительные поля, которые будут применяться на уровне конфигурации.
Дальше поле для ручной конфигурации полей. Детально можно почитать на сайте NXLog’a. В нашем случае, как пример, просто разбиение хостнейма на нужные поля:

Это была общая настройка конфигурации, куда отправлять и как подписывать каждый лог. Дальше в поле Configure NXLog Inputs укажем, какие файлы мониторить.

Name — …
Forward to (Required). Сюда выше созданный аутпут.
Type. Типов, которые умеет NXLog, довольно много, в данном случае укажем файл, что говорит о том, что данные будем брать из файла.
Path to Logfile. Путь до файла или файлов. Поддерживаются регэкспы, нужно только помнить, что в случае винды у файла обязательно должно быть расширение и все файлы в директории выглядят вот так: “*.*”.
Poll Interval. Как часто проверять изменения в секундах.
Следующий набор чек-боксов описывает поведение работы с файлом и зависит от специфики ваших логов.
И дальше опять же кастомные поля и raw поле. В данном случае из лога мы выбираем поле и передаем его как severity.

На этом будем считать, что дефолтная настройка закончена, вы же можете добавить туда больше файлов, полей и т.д.

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

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

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

Добавить в избранное

Главное меню » Операционная система Linux » Настройка Graylog на сервере для управления журналами в Linux

(3 оценок, среднее: 2,67 из 5)
З адумывались ли вы об управлении большим количеством журналов? Мы думаем что каждый сисадмин задавал себе этот вопрос. Решение очень простое: «Настройка сервера Graylog».

В предыдущем статье мы показали, как начать работу с Buildah для управления контейнерами Linux. В этой статье мы покажем вам, как настроить сервер Graylog для управления огромным количеством журналов (большие данные).

Что такое Graylog?

Для установки и настройки сервера Graylog существуют следующие условия:

Установка openJDK
Установка MongoDB
Установка Elasticsearch

Основными компонентами сервера Graylog являются:

Начнем с установки сервера Graylog. Мы пройдем процедуру шаг за шагом.

Необходимое условие для сервера Graylog

Давайте сначала начнем с установки необходимых компонентов сервера Graylog.

Обратите внимание, что в этой статье мы используем Red Hat Linux, поэтому на этапах установки показан менеджер пакетов Yum. Если вы используете какой-то другой дистрибутив, вы должны использовать менеджер пакетов вашего дистрибутива.

Установка openJDK

Сначала мы установим openJDK. Зачем тебе OpenJDK? Потому что Elasticsearch основан на Java. Вы также можете использовать OracleJDK, но я предпочитаю версию OpenJDK с открытым исходным кодом.

Установка Elasticsearch

После установки openJDK перейдем к Elasticsearch. Этот движок играет прекрасную роль на сервере Graylog. Движок Elasticsearch может хранить и искать огромное количество данных. Вот почему он предпочтителен при работе с большими данными.

Мы собираемся импортировать ключ GPG, используя следующую команду:

Поскольку репозиторий Elasticsearch по умолчанию недоступен в Centos 7/Rhel 7, нам нужно будет создать файл repo вручную, включая следующие записи в файле репозитория Elasticsearch.

Теперь вы готовы установить пакет Elasticsearch.

После установки пакета Elasticsearch будет создан файл конфигурации esticsearch.yml, установите для имени кластера значение graylog, как показано ниже.

Все готово чтобы начать и включить elasticsearch.service

После того, как вы начали, и включили elasticsearch.service ; Запустите команду curl:

Установка MongoDB

Нам нужно добавить репозиторий MongoDB с указанными ниже записями в репо-файле MongoDB, так как он по умолчанию недоступен в Centos 7/Rhel 7.

Установите пакет MongoDB.

Запустите и включите mongod.service.

Установка и настройка сервера Graylog

После того, как все предпосылки выполнены и проверены. Пришло время настроить и установить сервер Graylog. Вы можете скачать последнюю версию сервера Graylog с открытым исходным кодом по ссылке ниже:

Установите сервер Graylog:

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

Установите хеш-пароль для пользователя root. Обратите внимание, что вы будете использовать этот пароль при регистрации в веб-интерфейсе Graylog.

Теперь введите пароль root и сгенерированный ключ в файле server.conf. Также добавьте другие обязательные параметры.

Введите эти два параметра с указанным значением в одном файле, чтобы получить доступ к веб-интерфейсу Graylog. Веб-интерфейс Graylog будет прослушивать TCP-порты 12900 и 9000 в веб-браузере.

Настройка портов брандмауэра

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

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

Для управления политики SELinux, мы собираемся установить policycoreutils-python

Команда ниже гарантирует, что ваш веб-интерфейс имеет доступ к сети

Разрешение порта по умолчанию MongoDB.

Доступ к веб-интерфейсу Graylog

Вот и все. Теперь вы можете визуально управлять журналами приложений/сервера благодаря великолепному серверу Graylog с открытым исходным кодом.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Добавить в избранное

Главное меню » Операционная система Ubuntu » Как управлять журналами с Graylog 2 в Ubuntu 16.04

Введение

В этой статье, мы установим и настроим Graylog на Ubuntu 16.04, и создадим простой вход, который будет обрабатывать системные журналы.

Предпосылки

Перед тем, как начать этот урок, вам нужно:

Один сервер Ubuntu 16.04, по крайней мере 2 Гб оперативной памяти, включенные частные сети, и не корневой пользователь. Это может быть создано с помощью статьи: Начальная настройка сервера Ubuntu 16.04.
Установленный Oracle JDK 8.
Elasticsearch 2.x. Некоторые версии Graylog работают только с определенными версиями Elasticearch. Например, Graylog 2.x не работает с Elasticsearch 5.x. В этом руководстве используется Elasticsearch 2.4.4 и Graylog 2.2.
Установленный MongoDB.

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

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

Найдите следующую строку:

Измените cluster.name на значение graylog :

Сохраните файл и выйдите из редактора.

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

Теперь, когда вы настроили Elasticsearch, давайте перейдем к установке Graylog.

На этом шаге мы будем устанавливать сервер Graylog.

Во-первых, загрузите файл пакета, содержащий конфигурацию хранилища Graylog. Посетите страницу загрузки Graylog и найдите номер текущей версии. Мы будем использовать версию 2.2 для этого урока.

Затем установите конфигурацию хранилища из файла пакета .deb , снова замените 2.2 на версию, которую вы скачали.

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

Затем установите пакет graylog-server :

И, наконец, запустите автоматическую загрузку Graylog при старте системы с помощью следующей команды:

Graylog теперь успешно установлен, но это еще начало. Мы должны настроить его, прежде чем он заработает.

Теперь, когда мы настроили Elasticsearch и установили Graylog, нам нужно изменить несколько параметров в файле конфигурации Graylog по умолчанию, прежде чем мы сможем использовать его. Файл конфигурации Graylog находится по адресу /etc/graylog/server/server.conf по умолчанию.

Во-первых, нам нужно установить значение password_secret . Graylog использует это значение для защиты сохраненных паролей пользователей. Мы будем использовать сгенерированный случайным образом значение 128 символов.

Мы будем использовать pwgen для создания пароля, поэтому установить его, если он еще не установлен:

Сгенерировать пароль и поместить его в файл конфигурации Graylog. Мы будем использовать программу sed , чтобы установить значение password_secret в файл конфигурации Graylog. Таким образом, мы не должны копировать и вставлять любые значения. Выполните эту команду, чтобы создать секрет и сохранить его в файле:

Далее, нам необходимо установить значение root_password_sha2 . Это SHA-256 хэш вашего желаемого пароля. Еще раз, мы будем использовать команду sed для изменения файла конфигурации Graylog поэтому мы не должны вручную сгенерировать хеш SHA-256 с использованием shasum и вставить его в файл конфигурации.

Выполните эту команду, и замените password ниже на нужный пароль администратора по умолчанию:

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

Теперь нам нужно сделать еще пару изменений в файл конфигурации. Откройте файл конфигурации Graylog вашим редактором:

Сохраните файл и выйдите из редактора.

Так как мы изменили файл конфигурации, мы должны перезапустить (или запустить) службу graylog-server . Команда перезагрузки запустит сервер, даже если он в настоящее время остановлен.

Затем проверьте состояние сервера.

Вывод должен выглядеть следующим образом:

Вы должны увидеть active в статус.

Если выход сообщает о том, что система не работает, проверьте /var/log/syslog на наличие ошибок. Убедитесь, что вы установили Java при установке Elasticsearch, и что вы изменили все значения в шаге 3. Затем снова перезапустить службу Graylog.

Теперь, когда Graylog работает должным образом, мы можем перейти к обработке логов.

После входа в систему, вы увидите страницу с названием «Начало работы», которая выглядит как на рисунке:

Чтобы просмотреть страницу входов, нажмите System в выпадающем меню в навигационной панели и выберите inputs.

После этого вы увидите выпадающее окно, содержащее текст Select Input. Выберите Syslog UDP из этого выпадающего списка, а затем нажмите на кнопку Launch new input.

Должно появиться модальная форма. Заполните следующие детали, чтобы создать свой input:

Для Node, выберите сервер. Он должен быть единственным пунктом в списке.
Для Title, введите подходящее название, например Linux Server Logs .
Для Bind address, используйте частный IP вашего сервера. Если вы хотите иметь возможность собирать журналы с внешних серверов (не рекомендуется, так как Syslog не поддерживает аутентификацию), вы можете установить его на 0.0.0.0 (все интерфейсы).
Для Port, введите 8514 . Обратите внимание, что мы используем порт 8514 в этой статье, потому что порты 0 до 1024 могут быть использованы только корневым пользователем. Вы можете использовать любой номер порта выше 1024 и должно все работать, пока он не конфликтует с другими службами.

Теперь, когда вход был создан, мы можем послать некоторые журналы Graylog.

У нас есть вход, настроенный и прослушивает порт 8514 , но мы не посылаем никаких данных на вход еще, так что мы не увидим никаких результатов. rsyslog это утилита используется для пересылки журналов и предварительно установленных на Ubuntu, поэтому мы настроим отправлять журналы Graylog. На этом уроке мы настроим сервер Ubuntu для работы Graylog, чтобы отправлять свои системные журналы на вход мы только что создали, но вы можете выполнить следующие действия на других серверах.

Создайте и откройте новый конфигурационный файл rsyslog в редакторе.

Добавьте следующую строку в файл, заменяя your_server_private_ip на частный IP вашего сервера Graylog.

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

Перезапустите службу rsyslog , чтобы изменения вступили в силу.

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

Вы также можете нажать вкладку Search в панели навигации, чтобы просмотреть обзор самых последних журналов.

Вывод

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте также: