На основе ELK (Elasticsearch + Logstash + Kibana) создана интегрированная платформа журналов для предоставления комплексных функций, таких как сбор, обработка, хранение, поиск и отображение журналов. Благодаря сбору, передаче и хранению журналов, централизованному управлению, а также поиску и анализу массивных системных журналов в квазиреальном времени персонал по эксплуатации и техническому обслуживанию может осуществлять мониторинг бизнеса в квазиреальном времени, обнаружение и устранение неисправностей, анализ бизнес-трендов, обеспечение безопасности. аудиты соответствия и т. д. Извлечение больших данных из журналов.
В настоящее время журналы, подключенные к платформе журналов Tianyan, охватывают данные журналов приложений, операционных систем, баз данных, промежуточного программного обеспечения, портов хранения и управления, и в то же время собираются и сохраняются некоторые индикаторы каждого модуля.
Архитектура ранней платформы
Ранняя платформа журналов Tianyan использовала исходную модель трехуровневой архитектуры ELK: несколько независимых агентов Logstash (грузоотправитель) отвечали за сбор данных из разных источников, центральный агент (индексатор) отвечал за обобщение и анализ данных, а Брокер — впереди. используемого центрального агента Redis используется в качестве буфера, а Elasticsearch (далее именуемый ES) за центральным агентом используется для хранения и поиска данных Приложение может использовать настроенный Kibana для обеспечения богатого графического отображения или может быть разработан и настроены в соответствии с RESTful API ES.
Слой коллекции:Shipper представляет сбор журналов, использует Logstash для сбора данных из различных источников и случайным образом выбирает сервер в списке серверов Redis для подключения к брокеру при запуске.
буферный слой:В качестве буфера между удаленным грузоотправителем и центральным индексатором брокер реализован с использованием Redis. Один из них предназначен для повышения производительности системы, а другой — для повышения надежности системы. Когда центральному индексатору не удается извлечь данные, данные хранятся в Redis, а не в Redis.
Слой обработки:Центральный индексатор также использует Logstash для извлечения данных из брокера и может выполнять соответствующий анализ и обработку (фильтрацию).
Уровень хранения:Elasticsearch используется для хранения окончательных данных и предоставления функций поиска.
Слой отображения:Kibana предоставляет простой и многофункциональный веб-интерфейс, данные поступают из Elasticsearch, поддерживает различные запросы, статистику и отображение.
По прошествии более года, с развитием платформы журналов, количество журналов доступа увеличилось в геометрической прогрессии.Запрос на запись в журнал сильно повлиял на производительность сервера.В то же время требования к эксплуатации и обслуживанию приложений персонал на платформе становится все более и более сложным и разнообразным, постепенно выявляется ряд проблем на всех уровнях, вызванных ранним проектированием архитектуры:
Платформа агента уровня сбора на основе Logstash ограничена и не может поддерживать операционные системы Unix, такие как AIX и HP_UNIX, в то время как общий продукт с открытым исходным кодом Flume имеет относительно простую функцию и не может удовлетворить наши обычные требования к сбору журналов.
Анализ журнала агента потребляет много ресурсов, и необходимо срочно обновить анализ и обработку журналов до внутреннего уровня обработки.
Буферный уровень не может предоставлять распределенные службы очередей сообщений, поэтому его пропускная способность и эффективность должны быть улучшены.
Первоначальная версия уровня хранения имеет дефектные функции, а итерация версии выполняется быстро, требуя централизованных обновлений.
На уровне отображения отсутствует унифицированная запись управления для сценариев, а каждый сценарий приложения независим друг от друга и не имеет универсальности. На основе вышеуказанных проблем мы проектируем новую архитектуру.
Платформа журналов Tianyan была подключена к 58 системам приложений, из которых 44 являются важными базовыми приложениями класса A и B, охватывающими более 500 серверов, со средним ежедневным объемом записи данных 5T, что может хорошо поддерживать персонал приложений для эксплуатации и обслуживания. в журнал Файлы интеллектуально анализируются и обрабатываются для удовлетворения требований всесторонних функций, таких как сбор журналов платформы, обработка, хранение, поиск и отображение. Ниже мы поделимся с вами некоторыми работами, которые мы проделали в этой архитектуре.
На уровне агента, чтобы лучше адаптироваться к более разнообразным операционным системам, мы в основном используем Logstash и Flume для сбора журналов и индикаторов.В ходе этого процесса мы внесли дополнительные настройки в Flume и предоставили отзывы сообщества.
Во-первых, мы используем Logstash в операционной системе Linux для сбора логов и предварительного анализа. Однако, поскольку среда jvm Logstash не является стандартной средой jdk, Logstash не может работать в операционных системах HP_UNIX и AIX, поэтому эти две операционные системы используют Flume для сбора журналов. Файлы синтаксического анализа у всех агентов общие, класс Logstash общий, класс Flume общий. Если общая система журналов (в основном промежуточное ПО) должна одновременно собирать журналы приложений, Logstash необходимо настроить для включения логики сбора журналов приложений и системных журналов.Принцип заключается в том, что агент Logstash/Flume, который собирает журналы на машина запускает только один процесс. Для системного журнала операционной системы и журналов устройств хранения используется централизованный метод сбора, а для анализа и загрузки используется отдельный агент Logstash.
Flume Первоначально мы использовали Apache Flume 1.6. В процессе использования компонентов Taildir Source и основных компонентов мы обнаружили, что он не может полностью удовлетворить наши потребности, такие как:
Если путь файловой группы содержит регулярное выражение, полный путь к файлу не может быть получен, а путь журнала не может быть расположен после ввода журнала в Elasticsearch;
Taildir Source не поддерживает объединение нескольких строк в одно событие и может читать файлы только построчно;
Каталог, содержащий регулярные выражения, не поддерживается в конфигурации файловой группы, поэтому неудобно настраивать каталог, содержащий несколько дат, и дата автоматически увеличивается, например, /app/logs/yyyymmdd/appLog.log;
При использовании Host Interceptor обнаруживается, что можно зарезервировать только имя хоста или IP-адрес, и они не могут быть зарезервированы одновременно.
Изучив исходный код Flume, мы расширили разработку исходного кода. На данный момент мы предоставили сообществу открытого исходного кода следующие 4 исправления, из которых FLUME-2955 был объединен сообществом и выпущен в версии 1.7. Подробное введение в 4 патча см.«Примите открытый исходный код и верните его сообществу: практика предоставления исходного кода Minsheng Bank Flume» .
Кроме того, мы открыли версию на Github, которая объединила три патча FLUME-2960/2961/3187 в Flume 1.7. Вы можете попробовать ее.
GitHub.com/Тина Вэньцяо…, имя ветки trunk-cmbc.
Пример конфигурации Flume выглядит следующим образом:
При постоянном совершенствовании работы по доступу к журналам все недостатки разбора журнала выполняются на стороне агента. Поскольку Logstash написан на Java, а подключаемый модуль написан на jruby и требует для запуска среды jvm, требования к ресурсам для сервера будут относительно высокими. В то же время, когда Logstash использует подключаемый модуль filter/grok для обработки сложного извлечения полей журнала и предварительной обработки, регулярный синтаксический анализ будет потреблять много ресурсов ЦП и иногда нарушать порог предупреждения мониторинга ЦП в момент начального запуска, что может повлиять производственный сервер. Хотя фактического негативного воздействия на приложение не обнаружено (у агента есть механизм самоубийства сценария мониторинга), это вызовет сильное нервное напряжение персонала, занимающегося эксплуатацией приложения и обслуживающим персоналом.В последующем развитии архитектуры мы постепенно отменяем парсинг на стороне источника и перейти к фоновому разбору.
С развитием стека технологий Elastic появился Filebeat. Filebeat входит в состав Beat, написан на языке Go и не имеет зависимостей, легче Logstash и очень подходит для установки на продакшн-машины без чрезмерного использования ресурсов. В сравнительном тесте мы создали лог-данные объемом 1 Гб без регулярного парсинга.При условии выделения тех же ресурсов загрузка однопоточного логташа мгновенно подскочила до 80%, а затем была в основном около 60%.После 63 с обработка была завершена.При запуске Filebeat процессор на мгновение составляет около 40%, а затем около 20%, и обработка завершается за 15 секунд. Судя по результатам, Filebeat намного лучше, чем Logstash, с точки зрения производительности и соотношения ресурсов. В более поздней эволюции мы постепенно переносим работу по анализу журналов на серверную часть в новой архитектуре, и Filebeat нужен только для интеграции собранных журналов и загрузки их в том виде, в каком они есть.
Поскольку агент, развернутый на исходной архитектуре платформы предыдущего поколения, не имеет унифицированной функции управления, соответствующую информацию о конфигурации необходимо внедрять вручную, степень автоматизации слабая, и ее нельзя связать с другими системами. В связи с этим мы полагаемся на платформу управления и контроля больших данных для выполнения соответствующих требований к автоматизации в соответствии с новой архитектурой платформы журналов.Платформа управления и контроля больших данных представляет собой набор унифицированных операций, управления техническим обслуживанием и контроля агентов в больших данных. Кластер и платформа журналов Tianyan, независимо разработанная нашей командой по базовым продуктам для работы с большими данными, проект с интеллектуальным обнаружением сервисов и возможностями управления сервером. Платформа управления и контроля больших данных была переведена в онлайн-режим, чтобы реализовать автоматическое развертывание агента платформы журналов, запуск и остановку с помощью триггера и визуализацию мониторинга.Визуализация мониторинга отправляет информацию о пульсе в Kafka через Filebeat и Flume и разрабатывает программы топологии в кластере Storm для использования Kafka. информацию о сердцебиении и хранить ее в базе данных MySQL платформы управления и контроля больших данных. Кроме того, платформа управления и контроля больших данных связана с системой рабочих заданий, каталогом услуг и системой CMDB.Сама платформа журналов действует только как базовая структура.Добавление единого органа аутентификации, распределение информации метаданных и обработка потока данных заказа на работу настраивается через конфигурацию агента на странице платформы управления и контроля.Реализован модульный ввод и загрузка файлов кластера.
С точки зрения потребления ресурсов агента, помимо необходимых методов оптимизации, мы также настраиваем мониторинг процессов агента при развертывании агента, который развертывается платформой централизованного мониторинга, при этом на стороне агента развертывается crontab-скрипт. Завершите процесс агента, который занимает много ресурсов (процессор, память, хранилище), чтобы избежать влияния агента сбора на производительность системы приложений.
В спецификации журнала приложения мы оговариваем, что журнал приложения должен иметь метку времени, и эта метка времени будет использоваться как @timestamp по умолчанию при сборе данных агентом. Агенту Logstash необходимо добавить аббревиатуру приложения на английском языке, а агенту Flume необходимо использовать метод сериализации avro, чтобы добавить имя приложения, имя хоста и путь к заголовку заголовка, чтобы сформировать массив и отправить его индексатору для десериализации. Самособранные индикаторы операционной системы будут содержать поле типа операционной системы, а операционная система и журналы после набора хранилища должны содержать имя хоста или IP-идентификатор. В настоящее время все данные индикаторов, хранящиеся в ES, написаны строчными буквами, а соответствующие журналы могут быть оптимизированы и проанализированы в соответствии с конкретными потребностями системного персонала в будущем.
На этом уровне мы в основном используем Kafka для замены Redis. С технической точки зрения, хотя Redis рекомендовался в раннем официальном руководстве по Elastic, с точки зрения продукта Redis не является профессиональной очередью сообщений.Самая большая проблема Redis как очереди заключается в том, что емкость ограничена по памяти, а большая память одного узла является постоянной.Если она слишком длинная и нет репликации, данные, хранящиеся в Redis, легко могут быть потеряны при сбое всей машины (слишком расточительно иметь реплики, поэтому репликация сначала не используется). При среднесуточном объеме данных уровня T и сотнях миллионов документов, доступ к которым осуществляется в секунду, пропускная способность и кластерный режим Kafka лучше, чем у Redis, и Kafka имеет относительно полный механизм высокой доступности.Один брокер в автономном режиме не влияет на всю работу кластера. Чиновники Elastic также опубликовали в блоге серию текстов об использовании Kafka в качестве брокера ELK. В качестве распределенной очереди сообщений Kafka может в полной мере использовать ресурсы кластера Каждое приложение загружает журнал и назначает тему Различные системные журналы используют свою собственную тему Flume и Logstash загружают журналы и индикаторы в свою собственную тему Тема может иметь свою Существует несколько разделов, и разделы могут быть разумно распределены по каждому узлу, а собранные журналы будут равномерно размещены в разделах.
В то же время мы разработали соответствующие системы управления и контроля для Kafka's Broker, Topic, ConsumerGroup и его Offset, чтобы обеспечить такие функции, как услуги по настройке, сбор индикаторов производительности, отображение и операции по техническому обслуживанию.
Мы также разработали соответствующие функции управления конфигурацией и мониторинга производительности для Zookeeper, используемые Kafka:
Коды основных микросервисов вышеупомянутых Kafka и Zookeeper имеют открытый исходный код, и вы можете попробовать их:GitHub.com/GNU HPC/K AFK…
Слой обработки (индексатор)
Как упоминалось в предыдущей статье, мы начали постепенно проводить работу по облегчению исходной стороны, поэтому специально подали заявку на партию машин с сильными процессорными возможностями в качестве сервиса парсинга логов Logstash Indexer. планирует использовать Filebeat/Rsyslog вместо Logstash для сбора журналов. , Filebeat занимается только сбором журналов и многострочным сопоставлением, а обработка синтаксического анализа журналов сосредоточена на индексаторе Logstash после Kafka. Предварительная схема архитектуры выглядит следующим образом:
Соответствующие правила следующие: операционная система, стандартное промежуточное ПО, журналы и индикаторы работы базы данных и т. д. Из-за спецификации журнала индексатор в Logstash, как правило, может обрабатывать данные, отправленные всеми агентами. Однако из-за несогласованного формата журналов приложений, будь то данные, собранные Flume или Logstash, один (или несколько, в зависимости от вычислительной мощности) индексатор Logstash используется системой на уровне индексатора для обработки полей журнала. Парсинг выполняется на бэкенде цели. При обработке данных в ЭС единообразно используется принцип по дням.В ЭС индексы создаются в единицах приложений.Индексы разбиты по дням, а журналы приложений одного и того же приложения хранятся в одном и том же индексном режиме.
В то же время из-за эффективности синтаксического анализа журналов Logstash как внутреннего индексатора и сложности, связанной с управлением многими процессами Logstash, в настоящее время мы активно изучаем Hangouts.
Ctrip с открытым исходным кодом, моя команда второй автор проекта) на Docker и возможность StreamSets заменить бэкенд Logstash, чтобы более эффективно и гибко обрабатывать логи. Первый является альтернативой Logstash. По сравнению с Logstash имеет более простые функции, но более эффективную обработку. Второй, Streamsets, представляет собой платформу обработки данных, оптимизированную для данных в пути, предоставляющую визуальную модель создания потока данных. Жизненный цикл сборщика можно управляется через консоль управления, предоставляя богатый интерфейс мониторинга и управления. Однако сам по себе он не поддерживает кластерный режим, и в производственной среде в стране и за границей фактически применяется несколько случаев, а стоимость обучения высока.
Мы сделали обновление с 2.x до 5.x для Logstash. Согласно результатам некоторых тестов, производительность новой версии Logstash была значительно улучшена. Кроме того, новая версия Logstash предоставляет интерфейс API для мониторинга, а x-pack montior Kibana также бесплатен, что очень полезно для управления и просмотра состояния Logstash, особенно для нашей текущей архитектуры, где несколько индексаторов Logstash используют сообщения Kafka. Обновление Logstash относительно простое, и программный слой можно заменить напрямую, однако, поскольку многие параметры и файлы конфигурации были изменены в последней версии, необходимо перепланировать и перенастроить каталог следующим образом:
Отличие от старой версии заключается в том, что разные файлы конфигурации синтаксического анализа Logstash 5.X необходимо размещать в разных каталогах отдельно, поскольку параметры jvm и связанные с ними конфигурации новой версии записываются в отдельные файлы конфигурации, а не передаются как параметры как и раньше. , чтобы было удобно выделять разные ресурсы для разных индексаторов, такие как процессор, память и так далее. В то же время, поскольку новая версия Logstash предоставляет API мониторинга, ей необходимо выделить HTTP-порты для доступа. Та же конфигурация каталога также вызовет конфликты портов, что приведет к сбою запуска Logstash. В команду запуска необходимо добавить -- path.settings в соответствующие разные каталоги конфигурации.
Необходимо изменить параметры, связанные с разбором файла конфигурации. Новая версия входного плагина Logstash Kafka больше не поддерживает старые параметры API Kafka, такие как zk_connect и white_list. Новые параметры необходимо использовать для подключения к порту 9092 вместо zookeeper. порт для потребления данных.
Установите различные параметры ресурсов для объема данных, потребляемых различными темами Kafka, выделите память, изменив jvm.options, и задайте ресурсы ЦП и параметры пакета, изменив Logstash.yml.
-
Используя обновленный Logstash, было обнаружено, что китайские журналы, не закодированные в кодировке UTF-8, в производстве имели искаженные символы после десериализации последовательностью avro. Наконец, мы изменили исходный код подключаемого модуля Logstash-input-Kafka.
vendor/bundle/jruby/1.9/gems/Logstash-input-Kafka-5.1.8/lib/Logstash/inputs/ Kafka.rb
Модификации в предоставляет две новые опции:
(1) кодировка указывает кодировку исходного журнала, которая по умолчанию не установлена в UTF-8.
(2) charset_field — это массив, который указывает, какие поля нужно перекодировать, по умолчанию пусто, то есть без конвертации.
Конкретные коды см.
GitHub.com/logs он есть - комментарии...
В следующей статье мы представим техническую архитектуру нашего уровня хранения (Storage) и уровня представления (Presentation) и нашу работу, и, наконец, мы покажем текущие сценарии приложений и подведем итоги. Кроме того, данные China Minsheng Bank быстро растут, и существует острая нехватка технического персонала ELK, Hadoop, Spark, связанного с большими данными.Наш официальный веб-сайт искренне набирает мелких партнеров, которые заинтересованы в присоединении к банковской индустрии больших данных и сосредоточены на Вы также можете связаться с нами.
Чжао Мэн,Работая в основной технологической платформе больших данных и группе продуктов Департамента информационных технологий штаб-квартиры китайского банка Minsheng, руководитель платформы журналов Tianyan, уделяя особое внимание созданию общебанковской распределенной платформы журналов и внедрению прикладных решений Elasticsearch в банк.
Хуан Пэнчэн,Работал в платформе базовых технологий больших данных и группе продуктов Департамента информационных технологий штаб-квартиры China Minsheng Bank, руководил группой, отвечал за планирование, создание и обслуживание платформы Hadoop, а также участвовал в платформе журналов Tianyan и управлении большими данными. и платформа управления, WeChat gnuhpc.
Венчо,Работал в базовой технологической платформе больших данных и группе продуктов Департамента информационных технологий штаб-квартиры China Minsheng Bank, отвечал за проектирование и разработку платформы управления и контроля больших данных в банке, а также участвовал в технической работе Elasticsearch. Она также находится в глубине на Flume.
Обычный путь эволюции архитектуры бревенчатой платформы Tianyan от China Minsheng Bank (часть 2)
Уровень хранения (Хранилище)
Наш уровень хранения использует Elasticsearch. Он использует иерархическую структуру хранения, которая использует горячие данные для ввода SSD, теплые данные на диск SATA и моментальные снимки холодных данных на HDFS. Самая ранняя платформа журнала Tianyan Elasticsearch и Logstash использовали версию 2.3.5, основанную на Kibana4 для визуального отображения. Из-за очень активного сообщества ES выпуски ELK выпускаются особенно часто: переход с 2.X на 5.X менее чем за год. Версия lucene 5.X была обновлена до версии 6.2, и при поиске должно быть относительно большое улучшение производительности. В то же время официально рекомендуется, чтобы производительность нового ES была более стабильной, а весь продукт стека технологий ELK имел большие изменения и функциональные расширения. Официальные данные показывают, что ES 5.X относительно стабилен во время обновления.После наблюдения в течение определенного периода времени мы наконец использовали версию 5.5.0.Кроме того, 5.X ES оптимизирует индексацию, и мы также с нетерпением ждем к этому.
Официальный метод автономного обновления используется для прямой замены старой версии новой версией программного обеспечения и обеспечения доступности исходных данных. Используйте подключаемый модуль миграции ES для проверки потенциальных проблем перед обновлением.
А. свойства узла
В новой версии изменились имена атрибутов некоторых узлов, например, node.box_type изменен на node.attr.box_type. В новой версии нет клиентского узла.Он разделен на главный узел, узел данных, принимающий узел и только координирующий узел.Методы настройки следующие:
B. index settings
Начиная с ES 5.0, параметры, связанные с индексом, не настраиваются в файле конфигурации, но должны быть установлены на уровне индекса кластера (за исключением index.codec и аналогичных уровней экземпляра, которые можно установить на уровне узла). Обратите внимание, что выполнение следующего оператора сообщит об ошибке, поскольку эти параметры нельзя изменить динамически.
C. Переименовать настройки
5. Названия параметров X сильно изменились, bootstrap.mlockall изменен на bootstrap.memory_lock, discovery.zen.initial_ping_timeout изменен на discovery.zen.ping_timeout, по умолчанию 3s, новая версия убирает discovery.zen.initial_ping_timeout и discovery.zen.ping .timeout две настройки.
D. Изменения параметров
Параметр discovery.zen.ping.multicast устарел. Многоадресная рассылка удалена в версии 5.X, и используется подключаемый модуль обнаружения одноадресной или облачной рассылки. обновить API:
Отсутствует path.work: конфигурация в 5.X, параметр flush транслога в ES 5.X есть только
index.translog.flush_threshold_size.
Шаги обновления ES примерно следующие:
Приостановить запись данных журнала Logstash Indexer
Закрыть выделение сегмента кластера
Вручную выполните POST /_flush?wait_for_ongoing, дождитесь окончания операции и затем вернитесь
Вручную выполните POST /_flush/synced
Выключите все узлы кластера ES
Выполните замену программного обеспечения Elasticsearch новой версией
Запустите все узлы кластера ES
Перезапустить выделение сегмента кластера
Дождитесь завершения восстановления, статус работоспособности кластера станет зеленым
Перезапустите запись данных журнала Logstash Indexer.
После обновления кластера ES некоторые связанные плагины и инструменты также необходимо объединить и обновить. используйте cerebro вместо kopf.Церебро и старая версия страницы плагина kopf практически не отличаются.Функционально его можно полностью заменить. В то же время мы планируем использовать кросс-кластер, представленный в последней версии, для достижения межкластерного доступа между центрами.
Конечно, процесс апгрейда не может быть гладким, и в процессе возникало много проблем, и сейчас я поделюсь с вами более репрезентативной «ямой».
После замены новой версии программы ES и перезапуска статус всегда красный, проверьте лог, там много ошибок по ik, а анализатор для ik не может быть найден, как показано ниже:
Перед обновлением мы узнали из проекта ik на Github, что после 5.0 ik был переименован, скриншоты следующие:
Но для существующего индекса анализатор некоторых полей указывает ik, например, индекс l-Kibana-2017.08 в отчете об ошибке выше — это индекс, установленный до обновления, анализатор, указанный полем _all, — это ik, и он переименовал после апгрейда ik_smart, поэтому выдало ошибку, что ik анализатор не найден. Хотя анализатор, который модифицирует индекс после закрытия индекса, также может модифицировать имя токенизатора (если анализатор модифицируется напрямую без закрытия индекса, будет сообщено об ошибке), но из-за большого количества индексов, чтобы быстрее добиваемся совместимости, модифицируем Elasticsearch-analysis - исправлен исходный код ik, чтобы последняя версия плагина ik тоже могла поддерживать анализатор с именем ik.
(https://GitHub.com/manyout/elastic search-analysis-IK/pull/411/commits/63326 322 руб. спринт класс 8 от 1 Baidu 3662AB7 от 0 процентов 38 ач 86 ач 53 стоимость)
После апгрейда каждого компонента уровня хранилища эффект очевиден, самое интуитивное ощущение, что предыдущая проблема постоянного увеличения использования памяти кучи мастер-узла со временем исчезла. На самом деле уровень хранения не только обновляет ELK, но и настраивает базовую структуру организации индекса, очищает избыточные данные, разрабатывает общие сценарии инструментов, мелкомасштабное расширение ресурсов и т. д., поэтому он был протестирован и использован на практике. , после обновления платформа стала более стабильной, а запросы более эффективными.
В то же время, в ответ на резкий рост объема данных журнала, новая архитектура представляет SSD для повышения производительности чтения и записи ES. Одно хранилище ES имеет 2 диска SD и несколько дисков SATA, поэтому каждый сервер ES запускает 3 узла ES, 2 горячих узла и 1 теплый узел. Индексатор относится к порту, сконфигурированному с горячими узлами, а определение шаблона в ES гарантирует, что данные в реальном времени записываются только на горячие узлы.
Используйте кураторский инструмент, официально рекомендованный ES, чтобы регулярно перемещать данные с горячего узла на холодный, а срок хранения данных SSD составляет одну неделю. Конфигурационный файл действия куратора выглядит следующим образом:
Управление жизненным циклом Платформа журнала Tianyan реализует стратегию регулярного импорта данных журнала в hdfs платформы больших данных, и данные журнала хранятся в течение одного месяца, а период хранения данных журнала и индикаторов составляет один год. Примечание. Куратор, используемый в процессе горячего и холодного разделения данных, также должен использовать последнюю версию, прежде чем его можно будет использовать, и его необходимо переустановить после обновления кластера.
Презентация
Метод визуализации Kibana5 является более гибким и богатым, предоставляя больше компонентов и отслеживая представления визуализации, а также больше функций и улучшенный пользовательский интерфейс, которые очень привлекательны для пользователей платформы. Обновление Kibana относительно простое, но поскольку необработанное поле без сегментации слов в новой версии по умолчанию стало полем ключевого слова, необходимо обновить свойство индексов Kibana, а также настроить ранее созданную визуализацию. В новой версии Kibana действительно добавлены богатые представления и функции презентации, а также более красивое отображение страницы.
Поскольку модуль безопасности X-pack является платным, мы используем прокси Kibana (адрес https://github.com/gnuhpc/Kibana-multitenant-proxy) для реализации контроля разрешений Kibana и десенсибилизации отображения данных посредством саморазвития. В настоящее время разрешения контролируются индексным слоем, то есть пользователь может получить доступ только к указанному индексу, и если он обращается к другим индексам, он не может отображаться в Kibana. При этом из-за чувствительности данных в банковской сфере мы также предоставляем функцию установки ключевых слов десенсибилизации в конфигурационном файле, лог не десенсибилизируется при входе в ЭП, а функция шифруется и отображается при запросе на Kibana . Десенсибилизация Kibana-proxy показывает следующие эффекты:
Сценарии применения
Он может решать проблемы поиска с помощью ключевых слов и простых символов, избегать использования сложных правил и обеспечивать лучший поиск для пользователей. Когда несколько серверов выводят логи, необходимо быстро выяснить, на каком сервере упал запрос, о какой ошибке было сообщено и почему другие сервера не сообщили об ошибках. Иногда необходимо иметь возможность связать и запросить несколько журналов сервера одновременно, чтобы принять решение о проблеме.Например, запросить журналы активной и резервной баз данных одновременно, чтобы определить, синхронизирована ли база данных в определенный точка.
Данные журналов добычи полезных ископаемых, извлечение ценных данных для формирования диаграмм для отображения. Kibana предоставляет множество визуальных диаграмм для облегчения статистики общего дневного трафика и доступа к важным функциям бизнес-системы с точки зрения приложений; с точки зрения транзакций, он отображает общий объем транзакций системы, процент успешных транзакций и задержки, многократные объемная поддержка Бизнес-операции работают.
Регулярно классифицируйте и анализируйте данные аварийных сигналов, чтобы обеспечить поддержку данных для мониторинга, оценки производительности приложений, мониторинга процессов, обнаружения потока задач, продвижения и развертывания. Выполняйте статистику и анализ тенденций по охвату связанных технических компонентов в производственной среде и анализируйте фактическое использование различных технических компонентов в производстве по нескольким параметрам.
После обновления Kibana мы инкапсулировали уровень отображения обзора заданий на приборной панели, чтобы отображать статус доступа к системам A, B, C и D унифицированным образом, формируя шаблон анализа представления приложения. шаблон без отдельной настройки.Шаблон содержит унифицированную информацию журнала, такую как бизнес-транзакции, операционные системы, промежуточное программное обеспечение и базы данных, и может быть расширен, чтобы стать аналитическим представлением системы приложений.
Резюме и перспективы
Менее чем за два года строительства, путем различных корректировок архитектуры, проектирования и разработки, наша платформа для журналов на основе ELK, как и ожидалось, достигла следующих функциональных целей:
Точное позиционирование данных:Выполняя детальный полевой анализ журналов, он может максимально соответствовать бизнес-требованиям централизованного хранения и управления журналами в различных сценариях, а также упрощать запросы.
Записи и запросы эффективны:Благодаря обновлению платформы ELK и настройке памяти кластера, разумной конфигурации сегментирования и разделению «горячих» и «холодных» данных достигается максимальная эффективность записи журнала и запросов.
Развертывание высокой доступности:Сама система платформы журналов доступна во время отработки отказа благодаря дизайну высокой доступности и развертыванию кластера платформы ELK, и служба не прерывается.
Безопасно и надежно:Благодаря независимой разработке контроля разрешений и десенсибилизации данных гарантируется безопасность и надежность данных журналов платформы.
Архитектура продолжает развиваться, а технологии всегда движутся вперед. Объективно говоря, каждое архитектурное изменение платформы не является самым правильным выбором или лучшим решением.Как сделать «обычную дорогу» необычной, наша базовая технологическая платформа больших данных Minsheng Bank и команда разработчиков неустанно искали. Наша конечная цель, как и название платформы, позволить инженерам по разработке, эксплуатации и техническому обслуживанию активно проверять состояние системы в режиме реального времени через «Sky Eye» в любое время, хорошо знать ситуацию в системе, иметь четкое представление скрытых опасностей несчастных случаев и иметь четкое представление о производительности и мощности, чтобы способствовать использованию платформы журналов Sky Eye для доступа и управления журналами, которые стали важной частью производственной эксплуатации и обслуживания. Кроме того, данные China Minsheng Bank быстро растут, и существует острая нехватка технического персонала, связанного с большими данными ELK, Hadoop, Spark.Наш банк ищет небольших партнеров, которые заинтересованы в присоединении к банковской индустрии больших данных и сосредоточении на технологиях. на официальном сайте. Вы также можете связаться с нами. Оба автора общаются в WeChat.
об авторе:
Чжао Мэн,Работая в основной технологической платформе больших данных и группе продуктов Департамента информационных технологий штаб-квартиры китайского банка Minsheng, руководитель платформы журналов Tianyan, уделяя особое внимание созданию общебанковской распределенной платформы журналов и внедрению прикладных решений Elasticsearch в банк.
Хуан Пэнчэн,Работал в платформе базовых технологий больших данных и группе продуктов Департамента информационных технологий штаб-квартиры China Minsheng Bank, руководил группой, отвечал за планирование, создание и обслуживание платформы Hadoop, а также участвовал в платформе журналов Tianyan и управлении большими данными. и платформа управления, WeChat gnuhpc.
Венчо,Работал в базовой технологической платформе больших данных и группе продуктов Департамента информационных технологий штаб-квартиры China Minsheng Bank, отвечал за проектирование и разработку платформы управления и контроля больших данных в банке, а также участвовал в технической работе Elasticsearch. Она также находится в глубине на Flume.
Следите за нами в WeChat"Передовая линия ИИ", ответьте "AI" в фоновом режиме, чтобы получить серию электронных книг в формате PDF "AI Frontline".