Пошаговая настройка 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 довольно проста и банальна, поэтому я всем просто крайне советую действовать по официальным инструкциям:

• docs.graylog.org/en/2.2/pages/installation/operating_system_packages.html
• docs.graylog.org/en/2.2/pages/architecture.html#big-production-setup
• docs.graylog.org/en/2.2/pages/configuration/multinode_setup.html#configure-multinode

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

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

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

root_timezone = Europe/Moscow

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

elasticsearch_discovery_zen_ping_unicast_hosts =
elasticsearch_discovery_zen_ping_multicast_enabled = false

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

allow_leading_wildcard_searches = true

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

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

#Email transport

transport_email_enabled = true
transport_email_hostname = smtp.gmail.com
transport_email_port = 465
transport_email_use_auth = true
transport_email_use_tls = false
transport_email_use_ssl = true
transport_email_auth_username = 
transport_email_auth_password = 
transport_email_subject_prefix = [graylog]
transport_email_from_email = 
transport_email_web_interface_url = 

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

ES_HEAP_SIZE=31g

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

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

Пришло время настроить наш грейлог и начать получать данные. Первое, что нам необходимо — это определиться с тем, как мы будем получать логи. Мы остановились на 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 дней.

Идём в SystemIndices, там нажимаем 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).

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

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

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

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

Exec $Hostname= $collector_node_id;
Exec if ( $collector_node_id =~ /^(w+).(w+).(w+).(w+).(w+)/)
         { 
               $name = $1;
               $datacenter = $2; 
               $region = $3;
               $platform = $5;
         };

Это была общая настройка конфигурации, куда отправлять и как подписывать каждый лог. Дальше в поле 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

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

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

Автор: Vrenskiy

Источник