Введение

Данный проект представляет собой архитектурный дизайн для решения проблемы сбора, передачи и хранения больших объёмов данных журналов. В отличие от традиционных решений, таких как ELK (Elasticsearch, Logstash, Kibana), этот проект направлен на решение проблем с высокой стоимостью и низкой производительностью при обработке огромных объёмов журналов, включая журналы входа и выхода, а также журналы отслеживания ссылок.

Основные аспекты проекта — это производительность и стоимость.

Основное применение проекта — отслеживание пользователей, то есть возможность поиска по определённым условиям запросов пользователей, входов и выходов, а также журналов всей цепочки.

По сравнению с традиционными решениями, такими как filebeat, mq-передача и es-хранилище, этот фреймворк обеспечивает повышение производительности более чем в 10 раз и экономию дискового пространства более чем на 70%. Это означает, что при использовании той же конфигурации оборудования можно передавать и хранить 1 секунду 100M журналов, тогда как с помощью этого фреймворка можно обрабатывать 1 ГБ журналов в секунду и сократить использование дискового пространства для всей цепочки на 70% или более.

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

Проект подходит для случаев, когда объём журналов очень велик и требуется экономия на промежуточных звеньях, таких как использование Kafka для передачи журналов. Он используется в таких компаниях, как JD и Fangzhou Health, и поскольку каждая компания имеет разные требования к индексам при поиске журналов, потребуется определённая разработка. Это не готовый к использованию проект.

Что касается производительности и конфигурации машин, текущая конфигурация рабочих узлов в основном составляет 8 ядер и 32 ГБ памяти в Docker. 32 ГБ оперативной памяти являются специально настроенными параметрами, поскольку рабочим узлам требуется использовать чистую память для приёма и буферизации большого количества журналов. Такой одиночный узел может принимать от 160 до 200 МБ журналов в секунду, так как они сжаты, что соответствует примерно 1 ГБ исходных журналов или около 1 миллиона строк.

Конфигурация машины ClickHouse составляет 16 ядер и 64 ГБ памяти, и она может стабильно записывать 180 МБ в секунду. Более высокие скорости могут привести к снижению коэффициента готовности. Это соответствует примерно 1 ГБ исходных журналов.

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

Использование

Использование

Группа уже заполнена 200 участниками, вы можете добавить меня в WeChat, указав JLog в качестве примечания, чтобы я мог пригласить вас в группу.

Фон

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

Система журналов состоит из нескольких модулей: сбор (filebeat, logstash и т. д.), передача (Kafka, TCP и т. п.), хранение (ES, MySQL, Hive и т. д.) и запрос (Kibana, самописные).

На примере традиционного решения для журналов, если генерируется 1 ГБ журнала, он записывается на локальный диск (используя 1 ГБ дискового пространства), затем считывается и записывается в очередь сообщений (используя ещё 2 ГБ, включая одну резервную копию), а затем потребляется из очереди и записывается в ES (используя 1 ГБ пространства). В общей сложности требуется 4 ГБ дискового пространства, а также использование полосы пропускания сети и ресурсов сервера того же объёма (один сервер может обрабатывать 100 МБ в секунду).

Для приложения JD, которое генерирует сотни ГБ журналов в секунду, требуемые аппаратные ресурсы становятся непомерно большими, а стоимость становится неприемлемой.

Этот фреймворк был разработан для обработки огромных объёмов журналов с некоторыми компромиссами. Как упоминалось ранее, этот фреймворк в той же конфигурации обеспечивает увеличение пропускной способности журналов более чем в 10 раз и сокращение использования дискового пространства на 70% и более.

Решение

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

Основная процедура заключается в сборе информации о веб-запросах, входах и выходах, а также пользовательских журналах с использованием фильтров и настраиваемых приложений log4j и logback. Затем данные записываются в локальную память (вместо записи на диск), сжимаются (сокращая использование пространства строк на 80% и более) и отправляются через UDP на рабочие узлы (вместо MQ). Рабочие узлы извлекают индексные поля из данных и загружают их в ClickHouse. За исключением полей индекса, необходимых для будущих запросов, все остальные данные полностью сжимаются перед загрузкой.

Ответы на вопросы

1. Почему используется UDP вместо TCP?

Основное различие заключается в том, что UDP знает IP-адрес и порт получателя, отправляет сообщение и сразу очищает локальный буфер. TCP, с другой стороны, ожидает подтверждения от получателя после отправки сообщения и только затем удаляет сообщение из своего буфера. Если получатель зависает, клиент может столкнуться с переполнением внешней памяти. Кроме того, время связи увеличивается вдвое, а пропускная способность снижается.

2. Что делать, если UDP теряет сообщения?

3. Сетевое переполнение и перегрузка коммутатора могут привести к тому, что ни UDP, ни TCP не смогут отправлять сообщения.

4. При перезагрузке машины сообщения, отправленные во время простоя, не будут повторно отправлены.

5. Рабочий процесс может отказаться от данных, если не сможет обработать их достаточно быстро.

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

3. Один ClickHouse может записать максимум 180 МБ за секунду, что эквивалентно примерно 1 тысяче запросов в секунду. Как 30 серверов могут поддерживать 60 тысяч запросов в секунду или больше?

Предпосылка: производительность ClickHouse известна, например, один сервер может обработать 1 тысячу запросов в секунду, а 30 серверов — 30 тысяч. Тогда для поддержки 60 тысяч запросов в секунду нам нужно использовать другие методы для буферизации данных.

Решение: настроить 8-ядерные 32-гигабайтные машины, каждая из которых будет иметь очередь на 10 тысяч пользователей. Данные пользовательских запросов будут храниться в этих очередях, а затем массово загружаться в ClickHouse. Используя память, эти машины могут справиться с резким увеличением трафика в течение нескольких секунд. Таким образом, 50 таких машин могут вместить 500 тысяч очередей, что позволяет им обрабатывать до 80 или даже 100 тысяч одновременных запросов. Однако после пика трафик постепенно снижается до 30 или 20 тысяч, и система продолжает работать. Достаточно иметь кластер из 30 машин ClickHouse для обработки такого трафика.

Кроме того, рабочие машины можно легко масштабировать. Например, в обычные дни достаточно 4 машин для обслуживания от 1 до 5 тысяч запросов в секунду, но во время пиковых нагрузок можно быстро увеличить количество машин. Стоимость такого расширения крайне низка.