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



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

Несколько тысяч серверов создают трафик примерно от 1 до 100 событий в секунду. Событие — это широкий json объект без вложенности, один из примерно 40-50 заранее известных типов. Широкий — где-то до килобайта размером.

Всё это очень хорошо шардится по владельцам серверов и по времени.

Как это записать?

Понятно, что «если не знаешь куда писать логи, то пиши в кликхаус», но как туда складывать объекты разной структуры?

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

Предвосхищаю вопрос: зачем записать?

Ответы: затем, чтобы научиться связывать это с ошибками (льются в sentry), мониторингом (prometheus) и т.п.

174   26  
  1. Денис Габайдулин 3 месяца назад
    Ну я бы тебе советовал ELK/greylog стек или вариации, но если у тебя нет джавщиков в команде, то может и не надо. На больших объемах там нужна будет экспертиза.
    https://habr.com/ru/company/odnoklassniki/blog/494260/
  2. Юрий Насретдинов 3 месяца назад
    Если типов событий 40-50, но их приходит так мало, то можно может быть ClickHouse и не нужен :). Если прямо совсем не нужен реалтайм и можно событий чуть-чуть потерять при падении сервера или самого ClickHouse (что должно происходить очень очень редко), то можно сделать по таблице на тип событий и настроить буферные таблицы перед ними так, чтобы реально туда данные сбрасывались лишь раз в минуту, скажем. В общем, для ClickHouse главное — не писать туда чаще ~1 раза в секунду, если используются HDD.
  3. Сергей Аксёнов 3 месяца назад
    Я бы сказал ELK. Вроде в последнее время там всё меньше боли с деплоем и настройкой.
  4. Алексей Никандров 3 месяца назад
    aws sqs+ aws lambda + s3 + athena
  5. Антон Беляев 3 месяца назад
    Свойства между разными типами событий насколько сильно пересекаются?
  6. Dmitry Orshanskiy 3 месяца назад
    Можно использовать в качестве транспорта Kafka, в нее просто кладешь json, у Clickhouse есть штатный механизм queue -> view -> table, он читает json из Kafka и раскладывает json по колонкам и переносит в таблицу, попутно можно обогатить данные или преобразовать тип.
  7. Ilya Golshtein 3 месяца назад
    Монга же.
  8. Станислав Беляев 3 месяца назад
    А сколько времени нужно хранить данные? Какова глубина доступа к данным?

    Насколько быстро нужно достать старые логи?

    А с ними нужно работать? Какой профиль работы? Какие запросы будут делаться? А аналитика по логам будет?
  9. Julia Kane 3 месяца назад
    только преобразоанием.
  10. Andrey Dudin 3 месяца назад
    Если хочется переживать пики, то нужен буфер, например kafka.
    Куда класть? Ну если типов реально 40-50, то вполне реально предзаготовить таблицы в ClickHouse и класть в него. Точнее он сам умеет забирать из kafka.
  11. Данила Штань 3 месяца назад
    Можно хранить «не общие» поля в кликхаусе в json - он довольно эффективно по нему ходит и достаёт.

    Главное среди «общих полей» иметь те, на которые можно повесить индексы, чтобы выборку в запросах существенно сужать.

    Мы так наливаем ~300к сообщений из логов в секунду в кликхаус на hdd и нормально селектим. Эластик с такой нагрузкой хочет на порядок больше железа и все равно работает херово.
  12. Григорий Соколик 3 месяца назад
    Можно в монгу.
  13. Григорий Кочанов 3 месяца назад
    В этом задании есть неописанные нефункциональные требования. Если "Всё это очень хорошо шардится по владельцам серверов и по времени" - почему бы не уйти в multi tenancy, и не сделать множество независимых хранилищ? Зачем здесь централизация и героическая борьба? Вероятно, кроме мапинга на логи есть еще требования.
    100k/sec - не rocket science, это даже кролик может вертеть, только непонятно зачем именно так, если задача решается самыми разными способами. Смотрели ли на вариант по монге на инстанс? А sqs/lambda/s3/athena?
  14. Алик Курдюков 3 месяца назад
    А надо коррелировать логи между клиентами?
  15. Игорь Лидин 3 месяца назад
    Cassandra?
  16. Sergey Mikhalev 3 месяца назад
    Под логами что понимается? Если там реально логи с текстами, то clickhouse будет не так хорош, ellastic предпочтительней.
  17. Александр Румянцев 3 месяца назад
    Kafka->Clickhouse(kafka engine + json per line)
    Просто идеально для вашего случая. Сверху, взяв пилу и напильник, накрутить loghouse (он для дугого, но морду просмотра логов можно выдрать)
  18. Роман Скваж 3 месяца назад
    AWS CloudWatch Logs. Дешево, бесконечно, гибкий язык запросов для разбора полетов, алерты, конвертация в метрики и т.п. JSON парсит на лету.
  19. Андрей Степенко 3 месяца назад
    А читать их будет один чел, несколько? Какой режим обращений к базе? Эт я просто вслух рассуждаю.
  20. Сергей Нужненко 3 месяца назад
    Абаждите!
    1000 серверов по 100 событий в секунду по 1кб - это ~10Тб в сутки.
    Как бы и фиг с ним, но тут уже надо понять, какой у вас будет селект, с чем джойн и на какую глубину отбор: сутки? Неделя? Месяц? Год?
    По потоку: можно лить через кафку, складывать туда, где вы сможете это заселектить и сджойнить. При просмотре хотя бы на сутки-неделю это будет hadoop и spark, например. Если вы готовы урезать окно просмотра до минуты, то хоть в памяти словарем держите, хоть mysql, хоть что угодно.
    По схеме данных - зависит от того, как будет селект.
    Если я правильно угадал, что значит связывать, то одна таблица - список всех событий для джойна и к ней нужное количество таблиц с детальными атрибутами в зависисости от типа.
    Второй вариант при колоночном хранении сделать сверхширокую схему, как объединение всех имеющихся
  21. Nicola Ryzhikov 3 месяца назад
    попробуй timescaldb - потом расскажешь ;)
  22. Nicola Ryzhikov 3 месяца назад
    ребята на конфе про сотни терабайт рассказывали в pg. Шардить ручками
  23. Алексей Еремихин 3 месяца назад
    Мы схожую задачу про поток событий решили для нескольких хранилищ. Типов событий - несколько сотен. Все типы событий и атрибуты соответствующие этим типам объявлены заранее в реестре (конфиге). И вот этот централизованный реестр дал нам широкий простор для адаптации под разные хранилища. Не везде мы затачивались под наиболее оптимальное хранение, потому просто покажу разнообразие. У событий есть глобально общие поля - тип, время, идентификатор, версия приложения и т.д. Их там штук 20 и они организованы в структуры. У каждого события есть свои специфичные поля в зависимости от типа события. В ClickHouse общие поля вынесены в столбцы. Специфичные для типа поля вынесены в два параллельных массива строк - с ключами и значениями. В Hadoop (Hive/Presto) для обобщающей таблицы общие поля вынесены в соответствующие структурные столбцы, а специфичные в map<string, string>. Также есть и по таблице на эвент, где все специфичные поля раскрыты в отдельные столбцы. В Exasol - кажому эвенту своя таблица, каждому полю - свой столбец соответствующего типа. Сделать генератор DDL и скрипты миграции на новый конфиг - простая задача. Самым главным тут является центральный реестр событий: хранится и развивается в отдельной репе, расширяется централизованно, позволяет генерировать SDK под разные языки и поддерживать актуальную структуру БД. А, и документация к событиям тоже получается актуальной. Хоть я и не ответил на твой вопрос, но показал, что когда у тебя есть реестр, то выбор хранилища можно делать каким хочешь и уже по месту оптимизировать под задачу. Или даже выбрать несколько хранилищ для разных задач.
  24. Анатолий Орлов 3 месяца назад
    В озоне сразу писали в kafka, а потом из нее выгребали, обогащали(условно когда по id пользователя находишь его регион) и после этого клали в клик
  25. Алексей Кудряшов 3 месяца назад
    Apache Parquet хоть в хадуп, хоть на фс. Потом можно позапрашивать и в спарк позагонять.
  26. Макс Лапшин 3 месяца назад
    Коллеги, большое спасибо за советы.

    Я решил остановиться пока на такой схеме:

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

Добавить ответ:
Отменить.