company_banner

Как мы Graylog2 выбирали



    Перед каждым относительно крупным продакшном рано или поздно встает вопрос о централизованном сборе и просмотре логов. В настоящее время имеется огромный выбор опенсорсных, платных, online и on-premises решений. Я же постараюсь изложить процесс выбора в нашем конкретном случае.

    Эта обзорная статья, суть которой рассказать об основных особенностях Graylog2, почему мы выбрали именно его и как эксплуатируем.

    Немного про нашу инфраструктуру (чуть подробнее можно прочитать тут): мы используем 7 дата-центров по всему миру, порядка 500 production-серверов и ещё пара сотен разного рода приложений, с которых хотелось бы собирать логи. Всё это под управлением как Linux, так и Windows, а поверх крутятся разнородные сервисы. У всех сервисов свой формат логов, при этом есть еще и Java, у которой своеобразный StackTrace.

    Наши требования и что мы хотели получить в итоге


    Со стороны программистов и всех заинтересованных требования к логам были простыми:

    • агент отправки логов не должен сильно грузить систему;
    • возможность добавления кастомных полей в произвольный момент времени, на произвольных серверах;
    • поиск, сортировка и так далее;
    • возможность отправлять логи POST запросами или чем-то похожим (для отправки логов, например, с мобильных устройств).

    Тут в целом ничего сложного, всё вполне обычно. Но в нашем случае нужно было еще удовлетворить следующие требования обслуживания сервиса:

    • аутентификация в openLDAP (в нашем случае это FreeIPA);
    • удобное разграничение прав;
    • удобное конфигурирование клиентов (желательно из одного места);
    • возможность автоматизированной установки агентов на все используемые варианты систем;
    • возможность удобного мониторинга как работоспособности сервисов, так и необходимых метрик;
    • наличие community и документации, либо коммерческой поддержки;
    • простое масштабирование.

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

    На этом этапе мы поняли, что у нас остались только некоторые коммерческие решения и Graylog2 из opensource.

    Как считать количество логов и нагрузку


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

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

    На этом этапе при подсчете коммерческих решений и собственной инфраструктуры было принято решение использовать Graylog2. Решив, что лучший способ посчитать реальную нагрузку, это завести часть прод трафика на тестовый сервер, мы развернули одну ноду Graylog2 и направили туда трафик с определённой фокус-группы.

    Около недели мы видели нагрузку в 10-20к сообщений в секунду и в целом были уже готовы закладываться на эти цифры при развертке боевого кластера. Но в какой-то момент на серверах что-то сломалось, количество логов выросло почти в 10 раз и на одном сервере мы увидели всплеск до 100к сообщений в секунду. При этом ещё и часть StackTrace из Java-приложений не влезло в разрешенный размер лога. В этот момент к нам пришло понимание, что логи нужны как раз для удобной работы в таких критических ситуациях, а все предыдущие подсчеты велись исключительно в нормальных условиях.

    Основные выводы:

    • подсчёт логов в нормальных условиях не дает картины происходящего в случае аварий. А сбор логов нужен именно для оперативного решения этих ситуаций;
    • разные сервисы и языки пишут сообщения по-своему и учитывать такие ситуации надо заранее;
    • производительность кластера должна позволять обрабатывать в разы больше сообщений от нормальной нагрузки.

    Небольшое описание функционала Graylog2


    Основные причины, по которым мы выбрали именно его:

    • Хорошо зарекомендовавший себя ранее продукт. С хорошей документацией и освещенностью основных проблем.
    • Возможность конфигурировать агентов через веб-интерфейс через Collectors.
    • Простая и функциональная интеграция с OpenLDAP, в том числе синхронизация групп.
    • Удобное горизонтальное масштабирование.
    • Огромный выбор разных вариаций инпутов для получения логов.
    • Наличие плагинов и расширений.
    • Довольно простой и удобный язык запросов и построения выборок.
    • Наличие дашбордов и возможности уведомлений.

    Этот функционал покрыл практически все наши потребности и очень сильно упростил жизнь. Буквально за пару месяцев из тестового сервиса с сомнительным будущим он превратился в довольно важный business-critical юнит и уже полгода замечательно справляется со своими задачами.

    Конечно, внедрение подобных решений не самый прозрачный процесс. Мы столкнулись с довольно большим количество нюансов и подводных камней как при первоначальной настройке, так и при дальнейшей эксплуатации. В следующей статье я расскажу, как именно мы настраивали и тюнили Graylog2 и его компоненты такие как MongoDB и Elasticsearch.
    Pixonic 81,63
    Международная компания по разработке мобильных игр
    Поделиться публикацией

    Вакансии компании Pixonic

    Комментарии 6
    • 0
      Использовать E и не использовать LK? Странно.

      Расскажите про причны, почему не logstash.
      • 0
        Потому-что грейлог гораздо удобнее управляет коллекторами на хостах.
        На винде logstash очень часто течёт по памяти.
        У ELK нет нормальной связки с лдапом и вообще нет вменяемых разграничений прав.
        • 0
          Я понял. Вы используете модель с коллекторами на хостах. Это совсем не тривиально, так как есть вариант с центральным коллектором (на udp). Использование syslog/udp в свою же очередь обеспечивает возможность не тормозить работу чего-либо в ситуации, когда elastic'у плохо или медленно.

          Винда в этой схеме, конечно, выглядит как гигантский технический долг для исправления.
          • 0
            «7 дата-центров по всему миру» При udp мы теряем очень много данных.
            Для syslog так или иначе надо на хосте править конфиги чтобы добавить какое-то поле, у нас же этим могут заниматься сами программисты. Единственное требование это написать о добавлении нового поля в чатик.

            Ну и винда в нашем случае это половина всех логов, так что с этой суровой реальностью приходится мириться.
          • 0

            Разве? https://www.elastic.co/guide/en/x-pack/current/ldap-realm.html Другое дело, что оно по подписке работает

            • 0
              «2. Restart Elasticsearch» — При добавлении каких-то вещей рестартиться, а между тем на дворе 21век.

              И удобного управления разграничением доступа к тем или иным логам я не увидел. В грейлоге же права на уровне дашбордов у которых очень гибкая система наполнения.
              Мы больше 3-х месяцев ресёрчили вопрос. И наш выбор более чем осознанный.

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

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