Ну, будем честными, мультимастер в Оракле тоже сомнительная вещи и для обработки транзакций не очень пригоден. Да и PG вполне справляется с процессингом на десятки миллионов активных пользователей - если нормально готовить.
А в RMQ не упираетесь? Там же даже 100K сообщений в секунду вытащить нетривиально. Да и надежность он не особо добавляет, скорее наоборот (особенно если на векторе включить буферизацию)
А что такое "большой проект"? По опыту, система observability занимает от 30% (если не ELK стеке) до 5% от продакшена и такие затраты вполне осмысленны, так как сильно уменьшают TCO для системы.
Хранить error достаточно странно, так как обычно этот уровень используется для "неожиданных" ошибок, требующих реакции человека и число error составляет единицы в день максимум (если больше - то нужно исправлять систему и добавлять обработку соответствующей операции). Хранение trace/debug для отдельных особо чувствительных операций и info для всего вообще - совершенно нормальный подход для достаточно крупных систем.
Ну и подход OpenTelemetry ужасен, так как в случае падения сервиса нет никакой информации о причинах этого (библиотека отправляет логи вместе с response и в случае критических ошибок не получаешь ничего). Подход с поточным логером типа log4j гораздо лучше. А семплирование вообще нужно где-то на масштабах главной страницы Яндекса, для огромного количества проектов оно бесполезно (если, конечно, не пытаться использовать jaeger, который просто плохо хранит трейсы).
А какой смысл в логах, если нельзя посмотреть debug/trace? Они для этого и нужны ) Там вообще много разной магии возможно - от автоматического включения debug при ошибке и до возможности разметки отдельных запросов на другие уровни логирования. Но, в среднем, для небольших проектов (сотни операций в секунду) можно и жить на debug level.
На мой вкус, CH удобнее кибаны. Можно прямо из IDE делать запросы, считать агрегаты, преобразовывать как хочется. Ну и всякие "выгрузи в CSV на проде, загрузи в CH на девстенде" делать легко.
Мы вот разделяем на уровне CH логи на debug/trace (которые храним совсем недолго) и info (которые храним годами). Ну и трейсинг поверх СH сделать удобно, так как выборки быстрые. Правда, мы написали свой клиент для наших логов, так как у нас много своей специфики (бинарные данные, которые хочется красиво показывать и т.п.)
Ну и обычно стоит создавать число партиций с запасом (120 или 720, например). Тогда можно включить автоскейлинг для консюмеров. Но при этом будет перегруппировка партиций по консюмерам, которая не мгновенная.
Да вообще не бывает никакого exactly once нигде и никогда. В Кафка есть механизм частичного уменьшение дублей который назвали exactly once. Но это не про семантику взаимодействия, повторы на consumer все равно возможны. Поэтому смысла включать exactly once нет, только если нужны внутрикафковские транзакции (там, кажется, режим exactly once необходим для включения транзакций)
Проблема, вообще говоря, в самом использовании sp для оценки трудозатрат (они для этого не пригодны), в попытках забить задачами спринт (это противоречит скрамгайду), да и вообще в очевидно неверном использовании скрама и полной некомпетентности менеджеров, которые все это предлагают.
Там две основные проблемы, во-первых, тест ничего не измеряет. Т.е. один и тот же человек, пройдя тестирование, в разное время получает разные оценки и попадает в разные типы. Это делает бесполезным процесс типизации. во-вторых, есть довольно много исследований (включая метаисследования), показывающие, что типы по Майер-Бриггс никак не коррелируют ни с какими-то персональными характеристиками, ни с карьерными успехами или выбором профессий. Т.е. никакого практического смысла в типизации по Майер-Бриггс нет, те консультанты, которые ее используют - или врут или некомпетентны. Ну а уж на взаимодействие между людьми типы МБ вообще никак не влияют, это очевидные глупости (как и в соционике и в большинстве других классификаций).
Собственно, какой-то ненулевой "онтологический статус" имеет шкала экстравертности-интровертности по Айзенку и Big5. Вроде бы оба теста корректно локализованы на русский язык. Но и там, на самом деле, можно говорить только о статистической корреляции теста и каких-то психологических характеристик, про конкретного человека все равно практически ничего нельзя сказать.
Все попсовые типизации из менеджмента не имеют никакой предсказательный силы и не должны использоваться в найме или формировании команд )
Ох, само использование Майер-Бриггс уже говорит о некоторых проблемах с базовыми знаниями, но когда ее еще и используют некорректно, это совсем грустно.
Вадим, спасибо тебе огромное (и, кстати, привет!). Я учился программировать на PL/I (это было в маткружке и я был единственным учеником у двух преподавателей), моя первая программа была написана на PL/I (не работала, конечно, но сама возможность в шестом классе дойти до ЕС1060? и попробовать запустить простенькую программу казалось абсолютным чудом, первый Z80 я увидел года на три позже).
Я не понимаю проблемы. Если я вызываю какую-то функцию и она может кинуть исключение (а любой код в системе может кинуть исключение) и я знаю, как его обработать - я делаю try-catch и обрабатываю исключение. Мне не нужна никакая информация про саму функцию, я просто знаю, что в этот момент я могу разобраться с проблемой - и получить всегда корректную логику. Так как реально бывает только две разумных реакции - "повторить" или "поднять выше", то не понятно, зачем нужно знать список возможных ошибок и для чего. Крайне редко нужно реагировать на какие-то конкретные исключения (и, обычно, только для переупаковки их в какие-то свои сообщения, не для разной логики).
Result - не дает никаких плюсов, кроме кучи плохого кода. При этом panic все равно приходится обрабатывать всюду, где нужно как-то реагировать на события. Но panic - неудобен для обработки, не оптимизирован, не даст тебе никакой информации о том, что кто-то решил кидать panic в еще какой-то ситуации.
В Java, заметим, тоже все с исключениями типобезопасно, нет никаких проблем выделить собственные исключения и работать с ними одним способом, а с системными - другим. И компилятор все нужное проверит. А Either стоит использовать для управления потоком исполнения, а не для обработки исключительных ситуацией. И наличие и Exception и Either/Option/Result позволяет разделить логику и ошибки.
А ты много видел проектов на Java/С#/Kotlin? Более-менее современных (не старше 10 лет)?
А как ты думаешь, почему индустрия ушла от checked exception? Потому что неудобно и уменьшает надежность, а не увеличивает.
Теперь приложение не падает, а просто работает неправильно
А почему оно работает неправильно? У тебя в глубине произошло что-то непредвиденное (исключительная ситуация) и ты на верхнем уровне обработки сообщил о том, что что-то не то произошло. Это как раз правильное поведение, именно то, что и ожидается при вызове. Исключения надо ловить не там, где они возникли, а там, где это важно из бизнес-логики, а там уже все равно (обычно), какое было исключение и кто его кинул. Ну, просто отдал 500 - это лучше, чем упасть или чем пропустить проблему.
Ну, можно считать список возможных исключений частью контракта, но это не очень помогает со всякими техническими исключениями. Собственно, checked exception и предлагали такой подход, но в результате в том же Spring JDBC чуть-ли не самое полезное - замена checked exception на аналогичные unchecked.
Скорее нужен способ прокидывать в документацию список тех исключений, которые надо в документации показать. С автоматическим "сбором" всех исключений по стеку. Но это уже про какие-то фреймворки вокруг web api, да и то не очень востребовано (хотя мы в своей библиотеке похожее делаем, но на уровне всего сервиса, не конкретного метода).
Это вообще не проблема, так как ловить исключения на уровне бизнес-логики нужно все равно (так же, как и ловить паники, чтобы они не роняли весь сервис, а только конкретный поток исполнения). На уровне адаптера входящих сообщений пишешь try catch автоматически (вернее, он написан внутри библиотек/фреймворков).
Угу. Проблема не в исключениях, а в кривом синтаксисе работы с ними в некоторых языках. Ну, тогда можно просто взять языки, где большая часть проблем решена )
И чем хранение в S3 дешевле базы? S3 - те же файлы, та же дисковая подсистема, откуда там выигрыш в стоимости-то может появиться?
Ну, будем честными, мультимастер в Оракле тоже сомнительная вещи и для обработки транзакций не очень пригоден. Да и PG вполне справляется с процессингом на десятки миллионов активных пользователей - если нормально готовить.
А в RMQ не упираетесь? Там же даже 100K сообщений в секунду вытащить нетривиально.
Да и надежность он не особо добавляет, скорее наоборот (особенно если на векторе включить буферизацию)
А что такое "большой проект"? По опыту, система observability занимает от 30% (если не ELK стеке) до 5% от продакшена и такие затраты вполне осмысленны, так как сильно уменьшают TCO для системы.
Хранить error достаточно странно, так как обычно этот уровень используется для "неожиданных" ошибок, требующих реакции человека и число error составляет единицы в день максимум (если больше - то нужно исправлять систему и добавлять обработку соответствующей операции).
Хранение trace/debug для отдельных особо чувствительных операций и info для всего вообще - совершенно нормальный подход для достаточно крупных систем.
Ну и подход OpenTelemetry ужасен, так как в случае падения сервиса нет никакой информации о причинах этого (библиотека отправляет логи вместе с response и в случае критических ошибок не получаешь ничего). Подход с поточным логером типа log4j гораздо лучше. А семплирование вообще нужно где-то на масштабах главной страницы Яндекса, для огромного количества проектов оно бесполезно (если, конечно, не пытаться использовать jaeger, который просто плохо хранит трейсы).
А какой смысл в логах, если нельзя посмотреть debug/trace? Они для этого и нужны )
Там вообще много разной магии возможно - от автоматического включения debug при ошибке и до возможности разметки отдельных запросов на другие уровни логирования.
Но, в среднем, для небольших проектов (сотни операций в секунду) можно и жить на debug level.
На мой вкус, CH удобнее кибаны.
Можно прямо из IDE делать запросы, считать агрегаты, преобразовывать как хочется.
Ну и всякие "выгрузи в CSV на проде, загрузи в CH на девстенде" делать легко.
Мы вот разделяем на уровне CH логи на debug/trace (которые храним совсем недолго) и info (которые храним годами). Ну и трейсинг поверх СH сделать удобно, так как выборки быстрые.
Правда, мы написали свой клиент для наших логов, так как у нас много своей специфики (бинарные данные, которые хочется красиво показывать и т.п.)
А зачем? Решение на CH удобнее и эффективнее, чем на Loki.
Можно еще смотреть на Victoria Logs, они недавно сделали.
Ну и обычно стоит создавать число партиций с запасом (120 или 720, например). Тогда можно включить автоскейлинг для консюмеров. Но при этом будет перегруппировка партиций по консюмерам, которая не мгновенная.
Эээ, репликами чего являются партиции? В разных партициях живут разные сообщения, откуда там реплики?
Да вообще не бывает никакого exactly once нигде и никогда.
В Кафка есть механизм частичного уменьшение дублей который назвали exactly once. Но это не про семантику взаимодействия, повторы на consumer все равно возможны.
Поэтому смысла включать exactly once нет, только если нужны внутрикафковские транзакции (там, кажется, режим exactly once необходим для включения транзакций)
Проблема, вообще говоря, в самом использовании sp для оценки трудозатрат (они для этого не пригодны), в попытках забить задачами спринт (это противоречит скрамгайду), да и вообще в очевидно неверном использовании скрама и полной некомпетентности менеджеров, которые все это предлагают.
Там две основные проблемы,
во-первых, тест ничего не измеряет. Т.е. один и тот же человек, пройдя тестирование, в разное время получает разные оценки и попадает в разные типы. Это делает бесполезным процесс типизации.
во-вторых, есть довольно много исследований (включая метаисследования), показывающие, что типы по Майер-Бриггс никак не коррелируют ни с какими-то персональными характеристиками, ни с карьерными успехами или выбором профессий.
Т.е. никакого практического смысла в типизации по Майер-Бриггс нет, те консультанты, которые ее используют - или врут или некомпетентны. Ну а уж на взаимодействие между людьми типы МБ вообще никак не влияют, это очевидные глупости (как и в соционике и в большинстве других классификаций).
Собственно, какой-то ненулевой "онтологический статус" имеет шкала экстравертности-интровертности по Айзенку и Big5. Вроде бы оба теста корректно локализованы на русский язык. Но и там, на самом деле, можно говорить только о статистической корреляции теста и каких-то психологических характеристик, про конкретного человека все равно практически ничего нельзя сказать.
Все попсовые типизации из менеджмента не имеют никакой предсказательный силы и не должны использоваться в найме или формировании команд )
Ох, само использование Майер-Бриггс уже говорит о некоторых проблемах с базовыми знаниями, но когда ее еще и используют некорректно, это совсем грустно.
Вадим, спасибо тебе огромное (и, кстати, привет!).
Я учился программировать на PL/I (это было в маткружке и я был единственным учеником у двух преподавателей), моя первая программа была написана на PL/I (не работала, конечно, но сама возможность в шестом классе дойти до ЕС1060? и попробовать запустить простенькую программу казалось абсолютным чудом, первый Z80 я увидел года на три позже).
Я не понимаю проблемы. Если я вызываю какую-то функцию и она может кинуть исключение (а любой код в системе может кинуть исключение) и я знаю, как его обработать - я делаю try-catch и обрабатываю исключение. Мне не нужна никакая информация про саму функцию, я просто знаю, что в этот момент я могу разобраться с проблемой - и получить всегда корректную логику.
Так как реально бывает только две разумных реакции - "повторить" или "поднять выше", то не понятно, зачем нужно знать список возможных ошибок и для чего.
Крайне редко нужно реагировать на какие-то конкретные исключения (и, обычно, только для переупаковки их в какие-то свои сообщения, не для разной логики).
Result - не дает никаких плюсов, кроме кучи плохого кода. При этом panic все равно приходится обрабатывать всюду, где нужно как-то реагировать на события. Но panic - неудобен для обработки, не оптимизирован, не даст тебе никакой информации о том, что кто-то решил кидать panic в еще какой-то ситуации.
В Java, заметим, тоже все с исключениями типобезопасно, нет никаких проблем выделить собственные исключения и работать с ними одним способом, а с системными - другим. И компилятор все нужное проверит.
А Either стоит использовать для управления потоком исполнения, а не для обработки исключительных ситуацией. И наличие и Exception и Either/Option/Result позволяет разделить логику и ошибки.
А ты много видел проектов на Java/С#/Kotlin? Более-менее современных (не старше 10 лет)?
А как ты думаешь, почему индустрия ушла от checked exception? Потому что неудобно и уменьшает надежность, а не увеличивает.
А почему оно работает неправильно? У тебя в глубине произошло что-то непредвиденное (исключительная ситуация) и ты на верхнем уровне обработки сообщил о том, что что-то не то произошло. Это как раз правильное поведение, именно то, что и ожидается при вызове.
Исключения надо ловить не там, где они возникли, а там, где это важно из бизнес-логики, а там уже все равно (обычно), какое было исключение и кто его кинул. Ну, просто отдал 500 - это лучше, чем упасть или чем пропустить проблему.
Ну, можно считать список возможных исключений частью контракта, но это не очень помогает со всякими техническими исключениями.
Собственно, checked exception и предлагали такой подход, но в результате в том же Spring JDBC чуть-ли не самое полезное - замена checked exception на аналогичные unchecked.
Скорее нужен способ прокидывать в документацию список тех исключений, которые надо в документации показать. С автоматическим "сбором" всех исключений по стеку. Но это уже про какие-то фреймворки вокруг web api, да и то не очень востребовано (хотя мы в своей библиотеке похожее делаем, но на уровне всего сервиса, не конкретного метода).
Это вообще не проблема, так как ловить исключения на уровне бизнес-логики нужно все равно (так же, как и ловить паники, чтобы они не роняли весь сервис, а только конкретный поток исполнения).
На уровне адаптера входящих сообщений пишешь try catch автоматически (вернее, он написан внутри библиотек/фреймворков).
Угу. Проблема не в исключениях, а в кривом синтаксисе работы с ними в некоторых языках. Ну, тогда можно просто взять языки, где большая часть проблем решена )