Автор: Цао Линьхуа

Данная статья является оригинальной статьей, просьба указывать автора и источник для перепечатки

задний план

Являясь крупнейшим онлайн-образовательным сайтом в Китае, нынешние пользователи Hujiang Log Service включают поиск и анализ журналов нескольких продуктов в различных отделах, таких как онлайн-школа Hujiang, торговля, финансы, CCtalk (платформа прямых трансляций) и т. д., и ежедневно генерируются различные типы журналов. Существует более дюжины типов, обрабатывающих около 1 миллиарда (1 ТБ) журналов каждый день, горячие данные сохраняют данные за последние 7 дней, а холодные данные хранятся постоянно.

зачем лог система

Во-первых, что такое журнал?Журнал — это сгенерированные программой текстовые данные, которые соответствуют определенному формату (обычно включая метку времени).

Обычно журналы генерируются сервером и выводятся в разные файлы, обычно это системные журналы, журналы приложений и журналы безопасности. Эти журналы разбросаны по разным машинам.

Обычно при сбое системы инженерам необходимо войти на каждый сервер и использовать инструменты сценариев Linux, такие как grep/sed/awk, чтобы найти причину сбоя в журнале. При отсутствии системы журналов сначала необходимо найти сервер, обрабатывающий запрос.Если на этом сервере развернуто несколько экземпляров, вам необходимо перейти в каталог журналов каждого экземпляра приложения, чтобы найти файлы журналов. Для каждого экземпляра приложения также устанавливается политика переноса журнала (например, файл создается каждый день), а также политика сжатия и архивирования журнала.

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

На мой взгляд, данные журнала очень важны по следующим причинам:

Поиск данных: найдите решения, извлекая информацию из журнала и обнаруживая соответствующие ошибки.
Диагностика службы: благодаря статистике и анализу информации журнала можно понять нагрузку на сервер и текущее состояние службы.
Анализ данных. Вы можете выполнить дальнейший анализ данных, например, узнать курсы, которые интересуют пользователей из ТОП-10, на основе идентификатора курса в запросе.

В ответ на эти проблемы, чтобы предоставить распределенную систему мониторинга для сбора и анализа журналов в режиме реального времени, мы внедрили распространенное в отрасли решение для управления данными журналов, которое в основном включает три системы: Elasticsearch, Logstash и Kibana. Обычно в отрасли это решение сокращалось до ELK, беря инициалы трех систем, но после практики мы оптимизировали его до EFK, а F означает Filebeat для решения проблем, вызванных Logstash. Ниже мы раскрываем детали.

Версии стека ELK, рассматриваемые в этой статье:

Elasticsearch 5.2.2
Logstash 5.2.2
Kibana 5.2.2
Filebeat 5.2.2
Kafka 2.10скопировать код

Logstash: Механизм обработки сбора данных. Он поддерживает динамический сбор данных из различных источников данных, фильтрацию, анализ, обогащение и объединение данных, а затем их сохранение для последующего использования.

Kibana: Платформа визуализации. Он может искать и отображать проиндексированные данные, хранящиеся в Elasticsearch. Используя его, вы можете легко отображать и анализировать данные с помощью диаграмм, таблиц и карт.

Elasticsearch: Распределенная поисковая система. Он обладает характеристиками высокой масштабируемости, высокой надежности и простоты управления. Его можно использовать для полнотекстового поиска, структурированного поиска и анализа, а также сочетать эти три функции. Elasticsearch разработан на основе Lucene и в настоящее время является одной из наиболее широко используемых поисковых систем с открытым исходным кодом.Wikipedia, StackOverflow, Github и т. д. создают свои собственные поисковые системы на ее основе.

Filebeat: Легкий механизм сбора данных. На основе оригинального исходного кода Logstash-fowarder. Другими словами: Filebeat — это новая версия Logstash-fowarder, и она также будет первым выбором ELK Stack на стороне грузоотправителя.

Поскольку мы хотим поговорить о применении ELK в системе Hujiang, необходимо обсудить архитектуру ELK. В этом обмене в основном перечислены архитектуры ELK, которые мы использовали, и обсуждаются подходящие сценарии, а также преимущества и недостатки различных архитектур для справки.

Простая архитектура

В этой архитектуре мы напрямую подключаем экземпляр Logstash к экземпляру Elasticsearch. Экземпляр Logstash напрямую считывает данные источника данных (например, журналы Java, журналы Nginx и т. д.) через подключаемый модуль ввода, фильтрует журналы с помощью подключаемого модуля фильтра и, наконец, записывает данные в экземпляр ElasticSearch с помощью подключаемого модуля вывода.

На данном этапе функции сбора, фильтрации и вывода журналов в основном состоят из этих трех основных компонентов: ввода, фильтрации и вывода.

Input: Ввод, входными данными могут быть File, Stdin (прямой ввод из консоли), TCP, Syslog, Redis, Collectd и т. д.

Filter: Фильтр для вывода журнала в нужном нам формате. Logstash имеет богатые плагины фильтров: регулярный захват Grok, обработка времени, кодирование и декодирование JSON, модификация данных Mutate. Grok — самый важный плагин в Logstash, всем настоятельно рекомендуется использовать Grok Debugger для отладки собственных выражений Grok.

grok {
      match => ["message", "(?m)\[%{LOGLEVEL:level}\] \[%{TIMESTAMP_ISO8601:timestamp}\] \[%{DATA:logger}\] \[%{DATA:threadId}\] \[%{DATA:requestId}\] %{GREEDYDATA:msgRawData}"]
    }скопировать код

Output: вывод, местом назначения вывода может быть Stdout (непосредственный вывод из консоли), Elasticsearch, Redis, TCP, File и т. д.

Это самый простой способ архитектуры ELK, экземпляр Logstash напрямую подключен к экземпляру Elasticsearch. Преимущество в том, что он прост в изготовлении и удобен в использовании. Начинающим рекомендуется изучать и использовать в качестве справочного материала, и его нельзя использовать в онлайн-среде.

Архитектура кластерной версии

В этой архитектуре мы используем несколько узлов Elasticsearch для формирования кластера Elasticsearch. Поскольку Logstash и Elasticsearch работают в режиме кластера, режим кластера позволяет избежать проблемы чрезмерной нагрузки на один экземпляр. В то же время агент Logstash развертывается на каждый сервер онлайн для удовлетворения потребностей различных объемов данных.Большие и ненадежные сценарии.

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

Хранение данных и поиск: Конфигурация Elasticsearch может быть удовлетворена по умолчанию. В то же время мы смотрим на важность данных, чтобы решить, добавлять ли копию. При необходимости можно использовать не более одной копии.

Отображение данных: Kibana может создавать различные диаграммы на основе данных Elasticsearch для визуального отображения бизнес-условий в реальном времени.

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

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

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

Внедрить очередь сообщений

В этом сценарии несколько фрагментов данных сначала собираются через Lostash Shipper Agent, а затем доставляются в кластер Kafka через подключаемый модуль вывода, поэтому, когда способность Logstash получать данные превышает возможности обработки кластера Elasticsearch, его можно обрабатывать через очередь, он может играть роль сбривания пиков и заполнения впадин, а проблемы потери данных в кластере Elasticsearch нет.

В настоящее время в сценарии службы журналов наиболее часто используются две очереди сообщений: Kafka VS Redis. Хотя официальный сайт ELK Stack рекомендует использовать Redis для очередей сообщений, мы рекомендуем использовать Kafka. В основном из следующих двух аспектов:

данные потеряны:Очереди Redis в основном используются для отправки сообщений в реальном времени, и их надежность не гарантируется. Kafka гарантированно надежен, но с небольшой задержкой.
Накопление данных:Емкость очереди Redis зависит от объема памяти машины.Если установленная максимальная память превышена, данные будут удалены. Емкость стека Kafka зависит от размера жесткого диска машины.

По вышеуказанным причинам мы решили использовать Kafka для буферизации очередей. Тем не менее, в этой структуре все еще есть ряд проблем.

Грузоотправитель Logstash, собирающий данные, также потребляет ресурсы ЦП и памяти.
Развертывание в нескольких комнатах не поддерживается

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

Развертывание в нескольких комнатах

С быстрым ростом бизнеса Hujiang архитектура одного компьютерного зала больше не может удовлетворить спрос. Неизбежно бизнес Hujiang должен быть распределен по разным компьютерным комнатам, что также является большой проблемой для служб журналов. Конечно, в отрасли есть много зрелых методов, таких как унификация Ali, решение Tencent SET и так далее. Унифицированная архитектура здесь не описана, вы можете обратиться к [Унифицированной архитектуре] Weibo.

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

Четыре кластера Logstash, Elasticsearch, Kafka и Kibana развернуты в одном и том же компьютерном зале. Каждому компьютерному залу нужен собственный кластер службы журналов. Например, журналы бизнеса в компьютерном зале A могут передаваться только в Kafka. в компьютерном зале, в то время как кластер Indexer в компьютерном зале A Потребляйте и записывайте в кластер Elasticsearch в компьютерном зале A и отображайте его кластером Kibana в компьютерном зале A. Любой промежуточный шаг не зависит ни от каких услуги в компьютерном зале Б.

Представляем Filebeat

Filebeat основан на исходном коде оригинального logstash-forwarder, может работать без использования среды Java, а размер установочного пакета составляет менее 10 МБ.

Если количество журналов велико, Logstash столкнется с проблемой высокого использования ресурсов.Чтобы решить эту проблему, мы представили Filebeat. Filebeat основан на исходном коде logstash-forwarder.Он написан на Golang и не требует опоры на среду Java.Он обладает высокой эффективностью и занимает меньше памяти и процессора.Очень подходит для работы на сервере в качестве Агент.

Давайте посмотрим на основное использование Filebeat. Напишите файл конфигурации для анализа данных журнала из Nginx access.log:

# filebeat.yml
filebeat.prospectors:
- input_type: log
  paths: /var/log/nginx/access.log
  json.message_key:

output.elasticsearch:
  hosts: ["localhost"]
  index: "filebeat-nginx-%{+yyyy.MM.dd}"скопировать код

Посмотрим на данные измерения давления:

Среда стресс-тестирования

Виртуальная машина 8 ядер 64G памяти 540G SATA диск
Логсташ версии 2.3.1
Файлбит версии 5.5.0

Решение для стресс-тестов

Logstash/Filebeat читает в консоль логи 350W, одна строка данных 580B, и 8 процессов пишут в файл коллекции

Результаты испытаний под давлением

проект	workers	cpu usr	общее время	скорость сбора
Logstash	8	53.7%	210s	1.6w line/s
Filebeat	8	38.0%	30s	11w line/s

Filebeat потребляет всего 70% ЦП Logstash, но скорость сбора данных в 7 раз выше, чем у Logstash. Судя по нашей практике применения, Filebeat действительно решает проблему потребления ресурсов Logstash с меньшими затратами и стабильным качеством обслуживания.

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

1. Индексатор автоматически зависает после работы в течение определенного периода времени.

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

2. Вывод журнала исключений Java

В начале, когда мы разрезали лог через grok, мы обнаружили, что после вывода лога Java Exception будет проблема с новой строкой. Позже используйте Logstashcodec/multilineплагин для решения.

input {
    stdin {
        codec => multiline {
            pattern => "^\["
            negate => true
            what => "previous"
        }
    }
}скопировать код

3. Журнал имеет 8-часовую разницу во времени из-за часового пояса.

Плагин даты Logstash версии 2.3 настроен следующим образом, и результат анализа показывает, что @timestamp на 8 часов раньше, чем время в Китае.

Решение Kibana считывает текущий часовой пояс браузера, а затем преобразует отображение содержимого времени на странице.

  date {
    match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss.SSS" ]
    target => "@timestamp"
  }скопировать код

4.Grok parse failure

Мы столкнулись с онлайн-журналом узла, который внезапно нельзя было просмотреть в течение нескольких дней. Позже исходный журнал был извлечен для сравнения, и было обнаружено, что сгенерированный формат журнала был неправильным и содержал журналы как в формате JSON, так и в формате, отличном от JSON. Но когда мы используем grok для его анализа, он находится в формате json. Рекомендуется выводить журнал, чтобы обеспечить тот же формат и не отображать нестандартные символы, такие как пробелы.Вы можете использовать онлайн-отладку grok (http://grokdebug.herokuapp.com/) для устранения регулярности.

Суммировать

Преимущества решения для ведения журналов на основе стека ELK в основном отражаются в:

Масштабируемость. Архитектура распределенной системы разработана с учетом высокой масштабируемости, которая может поддерживать новые данные на уровне терабайт в день.
Простота в использовании: различные функции статистического анализа реализованы через пользовательский графический интерфейс, который прост в использовании и быстр в использовании.
Быстрый ответ: от создания журнала до видимости запроса, сбора данных, обработки и статистики поиска можно выполнить за считанные секунды.
Ослепительный интерфейс: в интерфейсе Kibana вам нужно всего лишь щелкнуть мышью, чтобы выполнить функции поиска и агрегации, а также создать ослепительную панель инструментов.

использованная литература

https://www.elastic.co/guide/en/beats/filebeat/1.3/filebeat-overview.html
https://zhuanlan.zhihu.com/p/26399963

Техническая рекомендация салона

Нажмите на изображение ниже, чтобы прочитать

Окончательное издание | Обзор глубокого обучения (обзор)

Перевод | Crucial CSS и Webpack: автоматизированное решение для уменьшения блокировки рендеринга CSS

рекомендательные системы