company_banner

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

  • Tutorial


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

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

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 дней.

Идём в 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. В нашем случае, как пример, просто разбиение хостнейма на нужные поля:

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. Роли для ансибла:


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

Ещё бы я хотел рассказать о том, как мы тюнили систему под свои нужды, но так как статья и так получилась довольно объёмной, то продолжение следует.
Pixonic 252,33
Международная компания по разработке мобильных игр
Поделиться публикацией
Комментарии 13
    0

    А нормального его можно конфигурировать? Без менюшек и прочего web 2.0. А то как-то довольно трудно собирать логи с половины мира, накликивая конфигурацию.

      0
      Можно. Но если человек способен разобраться в api то подобные инструкции ему не нужны.
        0
        Одно другому не мешает. Те кто умеет разбираться с АПИ — это вовсе не люди, которые все делают мгновенно.
          0
          Тут нет никаких сакральных знаний, всё что здесь есть описано в доке. Api как бы подразумевает что нужно почитать доку.
            0

            У API есть огромный недостаток — нет версионности конфигурации: кто-то, что-то изменил и все сломал — теперь сиди разбирайся что произошло.


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

              0

              Ну пиши в монгу напрямую.
              Меня и веб, и апи устраивает.

                0
                Ну пиши в монгу напрямую.

                И чем это отличается? Та же проблема остаётся.

                  +1
                  Ну если это критическое требование, то тут 2 варианта либо грейлог не подходит, либо делать это раскладывая конфиги прям на машины своей автоматизацией.
                  Нас устроило и апи, и веб интерфейс, чего-то более удобного в плане централизованного управления мы не нашли.
      0
      А можно узнать подробнее, как конкретно у вас устроена подсистема хранения на нодах эластика? Hdd|SSD, рейды, объем, тюнинг эластика и т.п.
        0
        Обычные 11 HDD по 4Тб в 0 рейде,
        Про тюнинг напишем следующую статью, но сам эластик особо не тюнили.
          0
          А какой рейт сообщений в секунду и какого они объема примерно? На сколько быстро ищет при запросе логов за 2 недели, например?
            0
            habrahabr.ru/company/pixonic/blog/340168
            Вот тут всё описали.
            По поиску не мерили, но никто особо не жаловался. Сейчас проводим работы посмотреть не могу?
              0
              За 2 недели логи около полутора минут собираются по одному источнику.

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

        Самое читаемое