Прошлое и настоящее логарифмической системы станции Б

Node.js задняя часть Kafka Logstash
Прошлое и настоящее логарифмической системы станции Б

Ван Сяньюй

Старший инженер по эксплуатации и техническому обслуживанию в Bilibili. Ранее он работал в Baidu и Ele.me. Он присоединился к Bilibili в 2017 году и отвечал за проектирование и разработку лог-платформы Bilibili.

В мае 2017 года началось строительство системы журналов (Миллиарды) станции B. На основе эластичного стека она обеспечивает унифицированные услуги сбора, поиска и мониторинга журналов для всей станции. В настоящее время в кластере 20 машин, более 200 сервисов доступа и 10+ логов в день.

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

оригинальная система регистрации

До Billions внутри станции B не было единой лог-платформы, и бизнесы в основном воевали друг с другом.Был как более перспективный метод на основе ELK, так и более простой и примитивный метод с использованием tail/grep на сервера.Уровни были неровными.вместе. После понимания ситуации с каждой линейкой продуктов существующие проблемы и требования в основном заключаются в следующем:

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

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

  3. Плохая поддержка PAAS. Компания продвигает контейнеризацию приложений в больших масштабах, но не существует хорошего решения для журналов, поддерживающего сбор журналов приложений в контейнерах.

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

Ввиду вышеперечисленных проблем, цели проектирования новой лог-системы предлагаются следующие:

  • Беспрепятственный доступ к бизнес-журналам: для подключения бизнес-журналов к системе журналов требуется только простая настройка; платформа журналов также должна выполнять только некоторые базовые настройки и не требует использования бизнес-информации, такой как содержимое журнала.

  • Поддержка разнообразия: Различные среды: физические машины (виртуальные машины), контейнеры; различные источники: системные журналы, бизнес-журналы, журналы промежуточного ПО...; различные форматы: однострочный/многострочный, обычный/json.

  • добыча бревен: Быстрая проверка, мониторинг журнала, статистический анализ.

  • доступность системы: данные в режиме реального времени, контролируемая скорость потерь (классификация услуг, полный мониторинг).

Эволюция миллиардов

Первоначальная конструкция системы

спецификация журнала

Чтобы решить проблему разнообразия форматов бизнес-журналов, спецификация формата журнала сформулирована единообразно, а в качестве формата вывода журнала используется JSON. Требование к формату:

  1. Должны быть включены четыре категории метаинформации:

  • время: время создания журнала, формат ISO8601

  • уровень: уровень журнала, FATAL, ERROR, WARN, INFO, DEBUG

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

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

  • Детали журнала равномерно сохраняются в поле журнала.

  • В дополнение к указанным выше полям деловые стороны также могут самостоятельно добавлять дополнительные поля.

  • Отображение json должно оставаться неизменным: ключ нельзя добавлять или изменять по желанию, а тип значения должен оставаться неизменным.

    • Например:

    {"log": "hello billions, write more", "level": "INFO", "app_id": "testapp111", "instance_id": "instance1", "time": "2017-08-04T15:59:01.607483", "id": 0}скопировать код

    Техническое решение системы журналов

    От генерации до потребления журналы в основном проходят следующие этапы: сбор -> передача -> сегментация -> извлечение.

    Сбор логов

    Сбор логов возможен двумя способами: неразмещенным и размещенным.

    • Для журналов бизнес-модулей журналы выводятся единообразно в соответствии со спецификацией журнала и нераспределенным образом. Для таких сценариев в сотрудничестве с отделом платформенных технологий мы разработали модуль лог-агента на базе go.

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

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

      • Агент журнала разделен на две части: сборщик и отправитель. Сборщик используется для получения журналов, а отправитель используется для отправки журналов в транспортную систему. Они взаимодействуют напрямую через файловый кеш. Таким образом, в случае сбоя системы передачи логов опора на локальный кеш может обеспечить нормальный прием логов.

      • Мы предоставляем библиотеки журналов (sdk), соответствующие разным языкам, и программы могут быстро получить доступ к системе журналов.

    • Для журналов не бизнес-модулей (промежуточного ПО, системных модулей, уровня доступа) из-за плохой возможности настройки мы завершаем сбор журналов чтением сгенерированных файлов журналов.

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

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

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

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

    Сбор логов

    У компании уже есть единая платформа передачи данных (lancer), преимущества lancer заключаются в следующем:

    • На основе flume+kafka для вторичной индивидуальной разработки, внутренней автоматической балансировки нагрузки и возможности горизонтального расширения.

    • На стороне приема данных реализован набор надежных протоколов передачи данных, совершенный мониторинг канала, безопасная и надежная передача данных.

    • Различные методы потребления (kafka, hdfs) могут быть подключены в соответствии с потребностями бизнеса.

    • Существует профессиональная команда для обслуживания 7 * 24.

    Поэтому мы напрямую выбираем lancer в качестве нашей системы доставки бревен.

    • Модуль отправителя в агенте журналов отправляет журналы на основе настроенного протокола передачи данных lancer, и, наконец, журналы передаются в разные темы в кластере kafka (темы настраиваются в соответствии с трафиком журналов), а затем журналы потребляются из kafka. Все темы используют единый префикс.

    • Поскольку на вторичную кастомизированную разработку filebeat нет сил, то filebeat напрямую выводит логи в кластер kafka lancer'а.

    сегментация журнала

    Основная функция модуля сегментации логов — потреблять логи из kafka, обрабатывать логи (извлечение полей, преобразование формата) и, наконец, сохранять их в соответствующем индексе elasticsearch. Мы используем logstash в качестве схемы разделения логов.

    в:

    • Для журналов, созданных в соответствии со спецификацией журнала, тема журнала kafka принимает единый префикс, поэтому мы используем метод Topics_Pattern для использования журнала.

    • Для параметра partition_assignment_strategy logstash должно быть задано значение "org.apache.kafka.clients.consumer.RoundRobinAssignor". Стратегия по умолчанию (разделение по диапазону) приведет к неравномерному распределению разделов. Если принята стратегия по умолчанию, когда потребитель (количество logstash * количество рабочих) Когда число больше, чем количество разделов темы, разделы всегда будут выделяться только фиксированной части потребителей.

    • Для журналов нестандартного формата отсутствует поддержка нескольких конфигураций из-за ограничений конвейера одного события logstash (ожидайте конвейера нескольких событий 6.0). Каждая конфигурация журнала отличается, поэтому для использования требуется отдельный процесс logstash.

    поиск журнала

    Масштаб кластера elasticsearch: главный узел*3, hot node*20, stale node*20, клиентский узел*2. Версия es — 5.4.3, конфигурация кластера следующая:

    • Машина данных (40 ядер, 256 ГБ памяти, 1T ssd, 6T*4 SATA) использует схему горячего и холодного разделения: развертывание горячего узла и устаревшего узла одновременно. Горячие узлы используют твердотельные накопители в качестве носителя для получения журналов в реальном времени. Устаревший узел использует диск sata в качестве носителя для хранения исторических журналов (только для чтения, но не для записи). Горячая->холодная миграция в фиксированное время в день.

    • Клиентская нода предоставляет внешние API для чтения и подключается к кибане и программам управления (таким как куратор, церебро и т. д.).

    • Для управления индексами (миграция, удаление) используется куратор, а журналы по умолчанию хранятся 7 дней.

    • Оптимизация конфигурации кластера es основана на предложениях многих сообществ и не будет подробно описана.

    • Используйте шаблон для управления отображением индекса.

    • Индекс создается за один день, чтобы предотвратить невозможность записи данных из-за централизованного создания.

    • es Monitoring: Изучил официальный монитор x-pack.Из-за отсутствия функций монитора x-pack (например, отсутствие мониторинга пула потоков) и невозможности выполнения алармов, я, наконец, решил разработать его самостоятельно. Внутренняя система мониторинга компании основана на Prometheus.Мы разработали es_exporter для сбора информации о состоянии es, а окончательный мониторинг и оповещение реализованы через Prometheus. Аварийный сигнал в основном включает в себя ключевые индикаторы, такие как информация о состоянии кластера es, количество отклоненных потоков, количество узлов и количество неназначенных осколков.

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

    итерация системы

    С увеличением количества доступных журналов постепенно возникали некоторые проблемы и новые требования. Billions был обновлен и итерирован в основном в следующих аспектах.

    управление осколками

    Сначала была принята стратегия управления по умолчанию es.Все индексы соответствуют 5*2 шардам (5 первичных и 5 реплик).Основные проблемы заключаются в следующем:

    • Каждый шард имеет дополнительные накладные расходы (память, дескрипторы файлов), а большинство индексов относительно небольшие, поэтому нет необходимости создавать 5 шардов.

    • Некоторые индексы содержат большой объем данных (более 500 ГБ/день), и объем данных, соответствующий одному сегменту, будет очень большим, что приведет к неоптимальной скорости извлечения, а операции ввода-вывода при записи на диск будут сосредоточены на нескольких машинах.

    В ответ на вышеперечисленные проблемы был разработан модуль управления индексом (shard mng), по объему исторических данных индекса (вчерашних данных) было принято решение создать количество шардов, соответствующее индексу завтрашнего дня. стратегия — 30 ГБ/шард, а верхний предел количества шардов — 15. Благодаря приведенной выше оптимизации количество сегментов в кластере сокращается на 70%+, а использование дискового ввода-вывода также становится более эффективным.

    выборка журнала

    Некоторые предприятия имеют большой объем журналов (более 500 ГБ/день), большинство из которых представляют собой журналы доступа к бизнес-процессам. Для журналов "небольшой части большого объема данных достаточно для устранения неполадок и выявления тенденций", а также для НИОКР и O&M.Communicate, эта точка зрения также получила признание. Поэтому в агент журнала-источника сбора данных (модуль-сборщик) добавлена ​​функция выборки журнала:

    • Выборка журнала использует app_id в качестве измерения. Журналы ниже уровня INFO выбираются случайным образом в соответствии с пропорцией, а все журналы выше WARN сохраняются.

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

    • Есть дополнительная деталь: из-за необходимости получения поля app_id в логе, если парсинг json производить напрямую, потребление процессора будет очень высоким. Позже мы улучшили поиск по символам (bytes.Index), чтобы решить эту проблему.

    Службы выборки с большим количеством журналов экономят много ресурсов es, не влияя на их использование. В настоящее время количество операций записи в журнал сокращается на 3+ трлн в день.

    Аппаратное решение узкого места узла данных

    20:00-24:00 вечера — пиковый период работы станции B, а также пиковый период трафика логов. С увеличением трафика часто поступает сигнал тревоги о задержке журнала (журнал не записывается в es вовремя).При наблюдении и мониторинге в основном обнаруживаются два явления:

    • На горячем узле было много отказов от массовых запросов, и в то же время logstash получил много 429 ответов. Пытался увеличить размер пула потоков и размер очереди, но проблема осталась.

    • Машина с горячим узлом долго ждет ввода-вывода, а использование SSD-диска составляет 100%.

    Из-за описанного выше явления предполагается, что отказ от записи вызван недостаточным объемом операций ввода-вывода SSD. Были проведены последующие тесты производительности и сравнения твердотельных накопителей, и было обнаружено, что производительность записи твердотельных накопителей на этом типе машины была низкой. Чтобы уменьшить нагрузку ввода-вывода на SSD, мы перенесли некоторый трафик записи в реальном времени на устаревший узел (устаревший узел раньше не принимал трафик записи в реальном времени, и нагрузка на запись была очень небольшой), а проблема журнала задержка была временно решена. Идеальное решение: модель узла данных — 40-ядерный ЦП, 256 ГБ памяти, 1 Тб SSD+4*6T SATA, очевидно, что эта модель SSD является узким местом с точки зрения производительности и емкости.Чтобы улучшить коэффициент использования этой модели и устранить узкое место производительности SSD IO, мы, наконец, добавили 2 * к каждой машине.Твердотельный накопитель PCIe 1,2 Тб — раз и навсегда!

    решение для повышения производительности logstash

    После решения вышеупомянутого узкого места записи es через некоторое время проблема задержки журнала в периоды пиковой нагрузки снова появилась. На этот раз у es не было проблемы с отклонением массового запроса. Из исследования всей ссылки не возникает задержек при сборе и передаче журналов, и, наконец, основное внимание уделяется модулю сегментации журналов (logstash).

    В сообществе признается низкая производительность logstash. Дальнейшие тесты производительности проводятся на logstash. 8000qps.Производительность действительно очень низкая.В пиковый период трафик 40W/s, поэтому для удовлетворения требований требуется не менее 50 экземпляров logstash.Очевидно, что такое потребление ресурсов недопустимо. Учитывая, что функция сегментации, соответствующая бизнес-логам, относительно проста, мы использовали go для разработки модуля сегментации журналов (индекс миллиардов).

    Производительность самостоятельно разработанного модуля была значительно улучшена.При условии 2 ядра + 4G памяти предельная производительность увеличивается до 5 Вт + QPS, а память потребляет всего 150 МБ. Потребление онлайн-ресурсов от (2 ядра + 4G памяти)30 уменьшено до (2 ядра + 150 МБ памяти)15. Также были решены проблемы с производительностью.

    мониторинг журнала

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

    • Правила хранятся в файлах, которые ненадежны и не подлежат распространению.

    • Конфигурация правила более сложная, неудобная и простая в использовании.

    • Программа единой точки, высокая доступность не может быть гарантирована.

    • Правила мониторинга выполняются последовательно, что неэффективно (если время выполнения всех правил больше интервала выполнения, регулярное выполнение одного правила не гарантируется).

    Ввиду вышеуказанных недостатков и собственных потребностей мы провели вторичную разработку для elastalert:

    Основные улучшения включают в себя:

    • Хранение всех правил в elasticsearch повышает надежность хранения правил и подготавливает к распределенной реализации elastalert.

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

    • Набор Restful API инкапсулирован для добавления, удаления, изменения и проверки правил мониторинга.

    • Объедините с существующей системой мониторинга компании (Bili Moni): настройте мониторинг журналов на основе Интернета и отправляйте сигналы тревоги через платформу сигналов тревоги.

    • Используйте глобальные блокировки для решения одноточечных проблем: два процесса горячие, а другой холодный.После сбоя горячего процесса автоматически вступает во владение холодный и выдается сигнал тревоги.

    • Скорректировано содержание будильника (корректировка формата, китаизация), описание стало понятнее.

    Log Monitoring 1.0 в настоящее время используется и продолжает развиваться.

    Архитектура последних Billions выглядит следующим образом:

    Текущие проблемы и следующие шаги

    В существующей системе журналов по-прежнему много недостатков, в основном в том числе:

    • Отсутствие контроля доступа: В настоящее время отсутствует контроль разрешений, в будущем необходимо реализовать такие функции, как унифицированная аутентификация, авторизация на основе индексов и аудит операций по аналогии с xpack.

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

    • Узкое место производительности мониторинга журналов: На данный момент лог-мониторинг выполняется на одной ноде (работает одна горячая нода) и правила выполняются последовательно, в дальнейшем требуется оптимизация под распределенную архитектуру + параллельное выполнение правил.

    • Конфигурация сегментации журнала сложна: Для журналов нестандартного формата реализована сегментация журналов на основе logstash.Каждому журналу для использования требуется отдельный экземпляр logstash.Конфигурация и онлайн-процесс сложны, а для поддержки в дальнейшем требуется система на базе платформы.

    Вышеуказанные недостатки также являются областями, над улучшением которых мы сосредоточимся на следующем этапе. Кроме того, благодаря мощным функциям es по поиску и анализу агрегации, мы также занимаемся более глубоким изучением ценности журналов. Нам еще предстоит поработать во многих местах, и мы с нетерпением ждем более глубокого общения с нашими партнерами по сообществу!

    Категории