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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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