Хм, "не прошел аудит" - это значит что был аудит сервиса и в нем найдены какие-то недостатки, хотелось бы про них послушать. А пока звучит "мы взяли эластик и не рассматривали альтернатив, поэтому приходится работать с логами кривыми инструментами". Так-то CH спокойно используют в крупных банках по всем миру, так что с аудитом все нормально.
А в чем проблема с объемом и структурой? Если проблемы есть, значит просто плохо спроектированны логи, нет структуры, нет нормальных инструментов работы с логами.
В метриках у тебя пишется и хранится среднее (с точностью до персентиля), не конкретные значения. Иногда этого достаточно, но если у тебя запрос начинает тормозить при конкретных значениях входящих параметров (а обычно оно так и бывает), метрики не дадут никакой информации.
OpenTelemetry, увы, довольно плохо описывает логи и делает их достаточно неудобными для анализа. Для метрик и трассировки - да, вполне. Впрочем, трассировку как раз лучше делать по логам. Как и бизнес-метрики.
Хм, что значит "отлаживаешь"? Как ты можешь что-то отлаживать на продакшене? Откуда ты возьмешь идентичную продакшену (на какой-то момент в прошлом) систему? Логировать 200 rps - не вызывает никаких проблем, как и хранить. Проблемы начинаются от сотен тысяч строк логов в секунду (т.е. не хватает одного дешевого сервера), но и там проблемы не слишком сложные.
Sentry вообще не для траблшутинга и при нормальном логировании бесполезная штука.
В Sentry попадают exceptions (с небольшим объемом контекста вокруг), но это про "предусмотренные" ошибки. А вот например некорректный расчет комиссии на конкретном платеже, обнаруженный пользователем через пару дней после платежа на основании данных из Sentry уже не разобрать. И подобных кейсов гораздо больше, чем возникающих исключений. Впрочем, обычно и контекста из Sentry мало для обнаружения проблем, особенно в случае влияния соседних процессов.
Так логи и нужны, в первую очередь, для поиска и исправления возникающих ошибок на продакшене (ну и так как данных при этом достаточно, то можно заодно и трассировку сделать и бизнес-метрики посчитать и так далее). Но если проблемы на продакшене не существенны, то можно и без логов (впрочем, зачем тогда метрики и sentry - тоже не понятно).
Основной плюс JSON5 - возможность комментариев и можно запятую в конце оставлять. Основной минус - менее распространен, не все стеки нормально поддерживают.
Ну, в Clickhouse нормально пакуются почти все данные, даже даты. Да, если в логах только числовые идентификаторы, то сжатия в 10 раз не будет. Хотя не совсем понятно, все-таки размер указан для json или только для содержимого внутри json? В первом случае упаковка в 10 раз не будет чем-то странным.
А почему Clickhouse нельзя, раз уж это эффективный способ работы с логами? А VictoriaLogs можно? И зачем вообще использовать ELK, если из-за него приходится отказываться от Debug?
NB: 100GB в сутки - это 3TB в месяц, не 30. Если хранить на шпинделях, то копейки, да и на SSD недорого. В ELK, правда, эти 3TB могут превратиться в 30, но это проблема использования эластика....
Люди редко видят разницу между МСА и другими видами распределенных систем. Увы, но сейчас когда пишут про "микросервисы" - имеют в виду просто "разные элементы деплоя". Обычно их еще и делают те, кто даже не смог распилить приложение на отдельные jar-файлы )
У микросервисов только одна выгода - упрощение линейного менеджмента. И ради этого их и внедряют - так как компетентность линейного менеджмента очень невысокая в индустрии (
Хм, а с чего бы распределенная система - более перспективная? При том что не понятно, почему задачи магазина не помещаются в один небольшой монолит, откуда там высокие нагрузки, требующие сложного масштабирования.
Хм, а почему решили, что если нет компетенций написать монолит, то хватит написать гораздо более сложную распределенную систему? Если даже понимания МСА особого нет и даже с простыми задачами в монолите не удалось справиться?
Но в среднем микросервисная архитектура стоит в несколько раз дороже по требуемому железа. В данном случае выигрыш мог бы быть от централизации вычислений и упрощения поддержки, но тут дело вообще не в облаке. И да, на монолите оно было бы много выгоднее.
При этом никаких проблем с горизонтальным масштабированием монолита нет. Впрочем, в статье столько, эээ, некорректных утверждений про монолиты и про микросервисы, что стало страшно за будущее Пятерочки.
Вообще, если для конфигов становится существенным формат хранения, значит что-то не так с дизайном и надо бы подумать. В файлах обычно есть только техническая конфигурация (а ее нужно очень мало), бизнесовая конфигурация и секреты живут в специализированных сервисах.
А так, у XML основной плюс - наличие стандартных механизмов валидации и инструментов редактирования на базе XML_Schema. Для некоторых условий это обязательное условие. JSON - быстрый, очевидный, но сложно с комментариями и описанием. YAML - легко читать, очень опасно редактировать, сложный стандарт с разночтениями, несовместимость между версиями. Сложно придумать, когда бы использование YAML было бы удачным. TOML - не для всех стеков есть хорошие библиотеки с поддержкой, нетривиально заводить сложные сущности.
В реальности выбор между XML и JSON. YAML обычно является арх.ошибкой. TOML используется скорее для утилит или десктоп-приложений, не для сервисов.
Но вообще в статье почти каждый абзац вызывает много вопросов. Что, впрочем, и логично.
Скорее наоборот. Послойные конфиги довольно сложные в сопровождении, так что стараются их не использовать. В крупных проектах обычно появляется отдельный сервис конфигурации и большая часть логики переносится в него.
Хм, "не прошел аудит" - это значит что был аудит сервиса и в нем найдены какие-то недостатки, хотелось бы про них послушать.
А пока звучит "мы взяли эластик и не рассматривали альтернатив, поэтому приходится работать с логами кривыми инструментами". Так-то CH спокойно используют в крупных банках по всем миру, так что с аудитом все нормально.
А в чем проблема с объемом и структурой? Если проблемы есть, значит просто плохо спроектированны логи, нет структуры, нет нормальных инструментов работы с логами.
В метриках у тебя пишется и хранится среднее (с точностью до персентиля), не конкретные значения. Иногда этого достаточно, но если у тебя запрос начинает тормозить при конкретных значениях входящих параметров (а обычно оно так и бывает), метрики не дадут никакой информации.
OpenTelemetry, увы, довольно плохо описывает логи и делает их достаточно неудобными для анализа. Для метрик и трассировки - да, вполне. Впрочем, трассировку как раз лучше делать по логам. Как и бизнес-метрики.
Хм, что значит "отлаживаешь"? Как ты можешь что-то отлаживать на продакшене? Откуда ты возьмешь идентичную продакшену (на какой-то момент в прошлом) систему?
Логировать 200 rps - не вызывает никаких проблем, как и хранить. Проблемы начинаются от сотен тысяч строк логов в секунду (т.е. не хватает одного дешевого сервера), но и там проблемы не слишком сложные.
Sentry вообще не для траблшутинга и при нормальном логировании бесполезная штука.
Ну, если честно, идентификатор пользователя (identityId) и идентификатор сессии (еще один UUID) не являются персональными данными.
Ну и умение понять, что нужно логировать, а что нет - обычно приходит с опытом, увы.
В Sentry попадают exceptions (с небольшим объемом контекста вокруг), но это про "предусмотренные" ошибки.
А вот например некорректный расчет комиссии на конкретном платеже, обнаруженный пользователем через пару дней после платежа на основании данных из Sentry уже не разобрать. И подобных кейсов гораздо больше, чем возникающих исключений.
Впрочем, обычно и контекста из Sentry мало для обнаружения проблем, особенно в случае влияния соседних процессов.
Так логи и нужны, в первую очередь, для поиска и исправления возникающих ошибок на продакшене (ну и так как данных при этом достаточно, то можно заодно и трассировку сделать и бизнес-метрики посчитать и так далее).
Но если проблемы на продакшене не существенны, то можно и без логов (впрочем, зачем тогда метрики и sentry - тоже не понятно).
Эээ, какой именно аудит не прошел Clickhouse (и при этом прошел Elastic)? И какие проблемы с дисками?
Эээ, а какие "такие объемы"? Один магазин, даже большой - не выглядит чем-то неподъемным для 1С, где даже автозапчасти умудрялись впихнуть.
Основной плюс JSON5 - возможность комментариев и можно запятую в конце оставлять.
Основной минус - менее распространен, не все стеки нормально поддерживают.
Ну, в Clickhouse нормально пакуются почти все данные, даже даты. Да, если в логах только числовые идентификаторы, то сжатия в 10 раз не будет. Хотя не совсем понятно, все-таки размер указан для json или только для содержимого внутри json? В первом случае упаковка в 10 раз не будет чем-то странным.
А почему Clickhouse нельзя, раз уж это эффективный способ работы с логами? А VictoriaLogs можно? И зачем вообще использовать ELK, если из-за него приходится отказываться от Debug?
NB: 100GB в сутки - это 3TB в месяц, не 30. Если хранить на шпинделях, то копейки, да и на SSD недорого. В ELK, правда, эти 3TB могут превратиться в 30, но это проблема использования эластика....
Люди редко видят разницу между МСА и другими видами распределенных систем. Увы, но сейчас когда пишут про "микросервисы" - имеют в виду просто "разные элементы деплоя". Обычно их еще и делают те, кто даже не смог распилить приложение на отдельные jar-файлы )
У микросервисов только одна выгода - упрощение линейного менеджмента. И ради этого их и внедряют - так как компетентность линейного менеджмента очень невысокая в индустрии (
Хм, а с чего бы распределенная система - более перспективная?
При том что не понятно, почему задачи магазина не помещаются в один небольшой монолит, откуда там высокие нагрузки, требующие сложного масштабирования.
Угу, автор явно не очень разбирается ни в монолитах, ни в микросервисах )
Хм, а почему решили, что если нет компетенций написать монолит, то хватит написать гораздо более сложную распределенную систему? Если даже понимания МСА особого нет и даже с простыми задачами в монолите не удалось справиться?
Но в среднем микросервисная архитектура стоит в несколько раз дороже по требуемому железа. В данном случае выигрыш мог бы быть от централизации вычислений и упрощения поддержки, но тут дело вообще не в облаке. И да, на монолите оно было бы много выгоднее.
При этом никаких проблем с горизонтальным масштабированием монолита нет.
Впрочем, в статье столько, эээ, некорректных утверждений про монолиты и про микросервисы, что стало страшно за будущее Пятерочки.
Вообще, если для конфигов становится существенным формат хранения, значит что-то не так с дизайном и надо бы подумать. В файлах обычно есть только техническая конфигурация (а ее нужно очень мало), бизнесовая конфигурация и секреты живут в специализированных сервисах.
А так, у XML основной плюс - наличие стандартных механизмов валидации и инструментов редактирования на базе XML_Schema. Для некоторых условий это обязательное условие.
JSON - быстрый, очевидный, но сложно с комментариями и описанием.
YAML - легко читать, очень опасно редактировать, сложный стандарт с разночтениями, несовместимость между версиями. Сложно придумать, когда бы использование YAML было бы удачным.
TOML - не для всех стеков есть хорошие библиотеки с поддержкой, нетривиально заводить сложные сущности.
В реальности выбор между XML и JSON. YAML обычно является арх.ошибкой. TOML используется скорее для утилит или десктоп-приложений, не для сервисов.
Но вообще в статье почти каждый абзац вызывает много вопросов. Что, впрочем, и логично.
Скорее наоборот. Послойные конфиги довольно сложные в сопровождении, так что стараются их не использовать.
В крупных проектах обычно появляется отдельный сервис конфигурации и большая часть логики переносится в него.
Нет. Телеметрия и логирование достаточно ортогональные. И чаще проще телеметрию делать по логам, нежели наоборот.
Уровни нужно смотреть под конкретные кейсы. Они разные для разных продуктов, нет общих решений.
Почему игнорируется? В Java trace попадает в логи прямо из коробки.
Но да, актуальных статей я тоже не видел. Доклад, что-ли, сделать...