Ну и Клеппман пишет, по большей части, о более сложных сценариях, нежели описаны в статье. Возможно, автор никогда не сталкивался с действительно сложными и крупными базами и проблемами целостности в них.
Да ладно, я в 2007 году спокойно делал 100 пишущих транзакций в секунду со сложной обработкой на тех же двух ядрах и не было с этим никаких проблем. Вот 10k пишущих транзакций в секунду на дешевом железе времен HDD - уже вызов, да.
Хм, "не прошел аудит" - это значит что был аудит сервиса и в нем найдены какие-то недостатки, хотелось бы про них послушать. А пока звучит "мы взяли эластик и не рассматривали альтернатив, поэтому приходится работать с логами кривыми инструментами". Так-то 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-файлы )
У микросервисов только одна выгода - упрощение линейного менеджмента. И ради этого их и внедряют - так как компетентность линейного менеджмента очень невысокая в индустрии (
Хм, а с чего бы распределенная система - более перспективная? При том что не понятно, почему задачи магазина не помещаются в один небольшой монолит, откуда там высокие нагрузки, требующие сложного масштабирования.
Хм, а почему решили, что если нет компетенций написать монолит, то хватит написать гораздо более сложную распределенную систему? Если даже понимания МСА особого нет и даже с простыми задачами в монолите не удалось справиться?
Но в среднем микросервисная архитектура стоит в несколько раз дороже по требуемому железа. В данном случае выигрыш мог бы быть от централизации вычислений и упрощения поддержки, но тут дело вообще не в облаке. И да, на монолите оно было бы много выгоднее.
При этом никаких проблем с горизонтальным масштабированием монолита нет. Впрочем, в статье столько, эээ, некорректных утверждений про монолиты и про микросервисы, что стало страшно за будущее Пятерочки.
А что у вас тогда используется? Что прошло аудит?
Ну и Клеппман пишет, по большей части, о более сложных сценариях, нежели описаны в статье. Возможно, автор никогда не сталкивался с действительно сложными и крупными базами и проблемами целостности в них.
Да ладно, я в 2007 году спокойно делал 100 пишущих транзакций в секунду со сложной обработкой на тех же двух ядрах и не было с этим никаких проблем. Вот 10k пишущих транзакций в секунду на дешевом железе времен HDD - уже вызов, да.
Хм, "не прошел аудит" - это значит что был аудит сервиса и в нем найдены какие-то недостатки, хотелось бы про них послушать.
А пока звучит "мы взяли эластик и не рассматривали альтернатив, поэтому приходится работать с логами кривыми инструментами". Так-то 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-файлы )
У микросервисов только одна выгода - упрощение линейного менеджмента. И ради этого их и внедряют - так как компетентность линейного менеджмента очень невысокая в индустрии (
Хм, а с чего бы распределенная система - более перспективная?
При том что не понятно, почему задачи магазина не помещаются в один небольшой монолит, откуда там высокие нагрузки, требующие сложного масштабирования.
Угу, автор явно не очень разбирается ни в монолитах, ни в микросервисах )
Хм, а почему решили, что если нет компетенций написать монолит, то хватит написать гораздо более сложную распределенную систему? Если даже понимания МСА особого нет и даже с простыми задачами в монолите не удалось справиться?
Но в среднем микросервисная архитектура стоит в несколько раз дороже по требуемому железа. В данном случае выигрыш мог бы быть от централизации вычислений и упрощения поддержки, но тут дело вообще не в облаке. И да, на монолите оно было бы много выгоднее.
При этом никаких проблем с горизонтальным масштабированием монолита нет.
Впрочем, в статье столько, эээ, некорректных утверждений про монолиты и про микросервисы, что стало страшно за будущее Пятерочки.