- PVSM.RU - https://www.pvsm.ru -
В первой [1] статье этого цикла я рассказал, как и почему мы выбрали опенсорсный 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 рейд и под хранилище эластика. Так как репликация происходит на уровне самого эластика, другие рейды нам нужны не сильно.
Сервера распределены следующим образом:
Схематично это выглядит вот так:
Настройки:
(На настройке HAproxy и keepalived останавливаться не будем, так как это находится за рамками данной статьи.)
Первоначальная настройка Graylog2 довольно проста и банальна, поэтому я всем просто крайне советую действовать по официальным инструкциям:
Там много полезной информации, которая в дальнейшем поможет в понимании принципов конфигурирования и тюнинга. При первоначальной настройке у меня ни разу не возникало проблем, поэтому перейдем к конфигурационным файлам.
В 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:
Открывается окно:
Теперь у нас есть наш первый инпут, который будет принимать сообщения. Приступаем к настройке хранения логов. Необходимо определиться сколько логов и как мы будем их хранить.
Мы поделили всё на проекты и логически связанные сервисы внутри проектов, а потом поделили на количество логов, которое нам необходимо хранить. Лично мы часть логов храним 14 дней, а часть — 140.
Хранение данных происходит в индексах грейлога. Индексы в свою очередь делятся на шарды. Шарды бывают праймари и реплика. По умолчанию данные пишутся в праймари шарды и реплицируются в реплику. Реплицируем мы только важные индексы. Большие индексы у нас имеют 2 праймари шарды и по одной реплике, что гарантирует выход из строя 2-х нод без потери данных.
Давайте создадим индекс который будет иметь 2 шарда и 1 реплику и будет хранить их логи 14 дней.
Идём в SystemIndices, там нажимаем Create index set:
Следующие пункты отвечают за количество хранимых логов и по названиям становится ясно, что их можно хранить по количеству сообщений, по времени, и по размеру индекса. Мы хотим хранить 14 дней.
Теперь нам нужно сделать так называемый стрим. Грейлог предоставляет права на уровне этих самых стримов. Суть такова: в стриме указываем, в какой индекс писать данные и по каким условиям. Находится это в Sterams. Настройка происходит в 2 этапа.
1. Создание стрима.
2. Дальше Manage Rules.
Там всё просто: добавляем необходимые правила, по которым туда будут попадать логи.
Теперь у нас есть инпут, который принимает логи; индекс, который их сохраняет; и стрим, который по сути собирает много логов в одно пространство.
Дальше настраиваем отправку логов в сам грейлог.
Путь настройки агентов описан здесь [5]. Работает это всё следующим образом: на клиенте ставится Graylog Collector Sidecar, который управляет бэкендом сборщика логов (в нашем случае для линукса и винды это — nxlog).
Подготовим правила сборки логов SystemCollectorsManage Configurations. Создаём конфигурацию и переходим к её настройке, там сразу переходим на вкладку NXLog. Видим 3 поля: Output, Configure NXLog Inputs и Define NXLog Snippets. Это всё кусочки конфигов этого самого NXLog’a, которые будут коллектором забираться на конечные ноды. Отсюда мы будем управлять полями и их значениями, а также файлами, которые мы будем мониторить и т.д.
Начнём с тегов. Вбиваем теги, по которым клиент будет понимать, какую конфигурацию ему нужно забрать.
Поле Output, тут одна конфигурация:
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 укажем, какие файлы мониторить.
Define NXLog Snippets мы обычно не трогаем.
На этом будем считать, что дефолтная настройка закончена, вы же можете добавить туда больше файлов, полей и т.д.
Перейдем к установке агента. Вообще, она очень хорошо описана по ссылке [5], поэтому здесь мы не будем останавливаться на ручной раскатке агентов, а сразу перейдём к автоматизации. Делаем мы это ансиблом.
В условиях линукса нет ничего ничего сложного, а на винде есть проблема в автоматической установке, поэтому мы просто распаковываем файл и на стороне ансибла генерим уникальный UUID. Роли для ансибла:
На этом настройку можно считать законченной и первые логи уже начнут появляться в системе.
Ещё бы я хотел рассказать о том, как мы тюнили систему под свои нужды, но так как статья и так получилась довольно объёмной, то продолжение следует.
Автор: Vrenskiy
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/267014
Ссылки в тексте:
[1] первой: https://habrahabr.ru/company/pixonic/blog/340168/
[2] docs.graylog.org/en/2.2/pages/installation/operating_system_packages.html: http://docs.graylog.org/en/2.2/pages/installation/operating_system_packages.html
[3] docs.graylog.org/en/2.2/pages/architecture.html#big-production-setup: http://docs.graylog.org/en/2.2/pages/architecture.html#big-production-setup
[4] docs.graylog.org/en/2.2/pages/configuration/multinode_setup.html#configure-multinode: http://docs.graylog.org/en/2.2/pages/configuration/multinode_setup.html#configure-multinode
[5] здесь: http://docs.graylog.org/en/2.2/pages/collector_sidecar.html
[6] на сайте: http://nxlog-ce.sourceforge.net/nxlog-docs/en/nxlog-reference-manual.html
[7] github.com/Hravn/grsidecar_win: https://github.com/Hravn/grsidecar_win
[8] github.com/Hravn/grsidecar_lin: https://github.com/Hravn/grsidecar_lin
[9] Источник: https://habrahabr.ru/post/341274/
Нажмите здесь для печати.