Graylog как настроить dashboard

Пошаговая настройка Graylog2

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

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

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

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

По нашим подсчетам, нам нужно 6 серверов. В каждом сервере по 2 сетевых интерфейса; первый — 100Мб в мир и 1Гб приватная сеть. На внешнем интерфейсе будет слушать веб-интерфейс и на части нод будет слушать HAproxy, но об этом позже. Приватная 1Гб сеть используется для сообщения всего остального.

Итого у нас есть 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 раскидывает трафик по всем нодам грейлога;
• грейлог в свою очередь тоже балансирует обработку логов по нодам.

(На настройке HAproxy и keepalived останавливаться не будем, так как это находится за рамками данной статьи.)

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

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

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

#Указываем нашу тайм зону

#Так как хостов не очень много, тут указываем все хосты эластика

#Разрешаем начинать поиск с вайлдкарда, потоум что у нас все понимают, что это и чем грозит

#Это относится больше к тюнингу, но на первом этапе мы указали ring_size равный половине L2 кеша процессора.

#И указываем данные для отправки писем грейлогом (в пустые строки нужно вставить ваши данные).

Дальше нужно потюнить хипсайз эластика в файле /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.

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

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

Теперь нам нужно сделать так называемый стрим. Грейлог предоставляет права на уровне этих самых стримов. Суть такова: в стриме указываем, в какой индекс писать данные и по каким условиям. Находится это в Sterams. Настройка происходит в 2 этапа.

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

• Title и Description. Как обычно — имя и описание.
• Index Set. В какой индекс писать данные, тут выбираем тот, который создали ранее.
• Remove matches from ‘All messages’ stream. Удалять сообщения из ‘All messages’. Чтобы не было путаницы — удаляем.

2. Дальше Manage Rules.

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

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

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

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

Путь настройки агентов описан здесь. Работает это всё следующим образом: на клиенте ставится 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.

Define NXLog Snippets мы обычно не трогаем.

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

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

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

• Win: github.com/Hravn/grsidecar_win
• Lin: github.com/Hravn/grsidecar_lin

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

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

Источник

Как мы работаем с логами (сбор логов с сервера, возможность визуализации данных при помощи Graylog)

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

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

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

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

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

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

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

System/Overview → Inputs

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

Select input → Syslog UDP

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

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

Внимание!

Порты меньше чем 1024 использовать можно только через костыли, поэтому будем использовать 10514:
http://docs.graylog.org/en/2.4/pages/faq.html#how-can-i-start-an-input-on-a-port-below-1024

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

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

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

Переходим в веб-интерфейсе Show received messages, видим полученное сообщение.

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

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

В 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: можно выбрать цвет

Webhook URL: Выглядит как https://hooks.slack.com/services/aaa/bbb123 — можно создать его в настройках Slack.

Channel: #monit (в какой канал будут приходить данные уведомления).

Custom Message (optional): можно выбрать какие поля оставляем в сообщении.

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

Нажимаем кнопку Execute test notification, контролируем доставку сообщения в указанный канал Slack-а, и если всё работает — нажимаем кнопку Done.

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

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

Нажимаем Done.

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

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

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

В Slack видим оповещение о событии (здесь сообщение стандартное, по умолчанию, но его можно кастомизировать под ваши требования):

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

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

https://graylog.itsft.ru/api/api-browser — REST API Browser

filebeat

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

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

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

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

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

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

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

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

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

Extractor

Дебаг grok patterns

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

System → Inputs → Manage extractors

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

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

Recent message выбирает последнее пришедшее сообщение, но удобнее выбрать нужное сообщение по message_id и index.

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:

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

gl2_source_input:6091644a7f58801671462478 — все сообщения с данного инпута;

gl2_source_input:6091644a7f58801671462478 AND request_method:POST — все сообщения с методом POST;

gl2_source_input:6091644a7f58801671462478 AND NOT http_status_code:200 — не 200-й ответ.

При составлении запроса 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:

Требуется все сообщения из Sidecar-а поместить в этот поток, поэтому:

Type: match input

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

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

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

Нажав на имя потока Sidecars можем также просматривать сообщения в нём и производить поиск по этим сообщениям.

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

На этапе установки, в первой части статьи мы прикрутили к 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:

Создаём Pipeline (пайплайны позволяют обрабатывать сообщения из потоков):

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 и добавляем к нему правило:

Идём в Streams → Sidecars, смотрим новые сообщения.

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

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

Идём в 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, смотрим новые сообщения и видим в них искомые геоданные:

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

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

Нажимаем Edit:

Visualization type: World Map

Сохраняем: Save

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

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

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

Источник