Ну, у нас там логи не только, которые легко представить в чём-то более эффективным для парзинга, чем JSON (к примеру в CSV), а и в виде stack trace-ов, которые уже могут сделать парзинг CSV не таким уж CPU оправданным.
Вообще, я в чём-то с вами согласен — мне тоже давно кажется, что logstash не сильно оптимально написан (хотя, опять же, у нас там кое-где скрипты предобработки выполняются — к примеру, для классификации страниц для просчёта SLA по их типам). Но elasitc corp пилять во всю новые версии со всякими улучшениями производительности и планы по обновлению на последние версии у нас есть.
Микросервисная архитектура, как и любая другая, даёт плюсы, но требует за это ресурсы. В данном случае — увеличение количества запросов. Для бизнеса «развязать» руки и уметь быстро релизить и пробовать различные RnD проекты и эффективнее тратить время дорогостоющих сотрудников гораздо ценнее, чем лишние несколько тачек.
Да, годная идея. Но она будет работать только если можно гарантировать 100% прокидывание reqid абсолютно по всем микросервисам. Причём при любых ответах (даже при экстренно завершённых запросах на проксе).
Хорошая идея, но при расследовании ошибок иногда очень нужно понять, что запрос дошёл до такого-то микросервиса. Логи БД и пр. мы пишем только очень выборочно (при превышении пороговых значений CPU, read, write, duration). Мы используем jaeger (вероятностный trace) и ещё свою систему автопрофилирования (trace по превышению длительности ответа), т.е. полностью прям всё мы, конечно, не пишем.
В идеальном мире — вы правы. В реальном вы можете столкнуться с проблемами ПО, с которыми вы не можете справиться. И вам никто не поможет — даже разработчики самого ПО, потому что вы просто не можете им повторить конкретную проблему для баг репорта. К примеру, в rabbitmq при непонятных для нас обстоятельствах могут образоваться т.н. «мёртвые очереди» — вы с ними вообще ничего не можете сделать (даже удалить нормально не можете ни через UI, ни через cli). Но в этот момент отправка сообщений, которые роутятся в такие очереди начинают очень сильно тупить и это уже аффектит приложение. Всё это случается, к счастью, не регулярно, но единственным быстрым решением пока является выполнеие некой «магической» cli операции, которая через прямой eval в бэк rabbitmq убивает сломанную очередь.
Поэтому я бы не был бы так категоричен в своих высказываниях, потому что по моему опыту категоричные люди делятся на две категории: супер-боги-знающие-всё и те, кто просто ещё не встретил свой «пистолет с большой мушкой» на своём профессиональном пути.
Не смотря на то, что я согласен, что специально обученный человек смог бы такое замечать, к сожалению, это так не работает, когда у вас столько выкладок в день как у нас. Для «масштабирования» процесса вам просто придётся держать штат таких людей и заставлять их заниматься одним и тем же каждый день. Это приводит к тому, что либо у вас будут джуны на таком сидеть (и качество инициативы сомнительное), либо текучка нормальных спецов (потому что тупеешь, если твоя работа только в постоянно смотреть пулрики).
Мы сейчас идём другим путём — хотим, чтобы у каждого микросервиса был, скажем, свой микрокластер postrgre или elastic (на контейнерах, чтобы не получать оверхед от виртуалок). Тогда мы сможем ограничить негативное влияние одного микросервиса на другие.
Мы всегда исходим из того, что накосячить могут все и очень разным способом и под каждый способ накосячить невозможно держать отдельного человека, поэтому более стратегически правильно научиться минимизировать взаимовлияние (изоляция + деградация) и время простоя компонент (алерты + автоматизация).
Мы как раз считаем себя не из тех, кто может просто «заливать железом». Так было бы гораздо проще всё в облаках купить и не морочить себе голову. Но реальность такова, что даже самый дешёвый облачный хостинг будет стоить минимум в два раза дороже того, что мы смогли отстроить.
Поэтому, да — занимаемся оптимизацией. Наверное, не так, как если бы у нас было 10 серверов, но всё же активно с этим работаем.
И, пожалуй, самое «тяжёлое» по железу это не C#, а machine learning (ибо big data и все дела) и, как ни странно, frontend (nodejs server side rendering) — там много CPU bound операций (парзинг json, рендеринг html), на которые приходится достаточно большой RPS. Но шарп мы тоже активно переводим на .NET Core (и вот скоро приступим к переводу на .NET Core 3).
Возможно, это реклама (как в поисковиках, когда вот вы искали обои, а вам также предлагают перфораторы). А, возможно, это баг — у нас достаточно серьёзно относятся к разбору вопроов и отзывов пользователей — попробуйте описать проблему через обратную связь.
8к RPS это только «входящие». К примеру, для того, чтобы показать вам (залогиненному пользователю) результаты поиска нужно выполнить гораздо больше запросов в разные микросервисы — показать вам вашу «шапку» с вашим балансом, отметить «сердечком» в результатах поиска те, которые вы отметили ранее, посмотреть доступны ли вам чатики для этих объявлений, да и просто проранжировать под вас выдачу. Там ещё куча всего «под капотом», что отличает обыный список от выдачи современного информационного ресурса. Так что внутри это далеко не 8к RPS :)
Да, можно и больше — это не «rocket science». Filebeat -> Kafka -> Logstash -> Elastic. Логируем мы также логи приложений уровня info и выше + всякие события с других систем: к примеру, в mssql настроены extended events на тяжёлые запросы, чтобы если кто-то нагнул БД, то мы бы смогли ретроспективно посмотреть кто это был.
Http вызовы + сообщения очередей — это основные каналы взаимодействия, да. И в обоих каналах приложения должны придерживаться объявленного контракта (request/response схемы или model события). У нас также есть система (пока она работает только для api вызовов), которая валидирует при выкладке, что не произошло breaking change в принимаемых api или вызываемых среди всех монолитов и микросервисов (мы умеем по коду автоматически найти схемы request / response приложения).
Это то да, но там, насколько я помню, было то, что даже отправка в syslog из приложения (чтобы на том конце уже дропнули в режиме overflow) было блокирующей операцией и это деградировало отработку запросов в приложении. И это мы говорим про udp! Блокирующая отправка по udp, Карл! Вот это меня удивляет.
Спасибо за разъяснения. А почему тогда такие простые, судя по вашим словам, обёртки недоступны по умолчанию в линуксе? Вот вывод логов через rsyslog из контейнеров блокируется? Потому что мы в ЦИАН уже получали проблемы от этого пару лет назад. Возможно, что-то изменилось или мы что-то не так готовили, но при резком увеличении логов у нас питон глох, если logstash не успевал принимать логи с rsyslog машины.
Ну и про rps — асинхронность она же не про rps, а про масштабирование io heavy приложений (современные микросервисы) и их использование cpu на это дело.
Люди, а за что минусуете? Человек дело говорит. Меня тоже всегда удивляло, что такое сильное ядро не умеет полноценно асинхронно работать, тогда как есть пример как это нормально реализовано в другом ядре.
Скорее всего мы имеем дело с «фасадом» — выносим все методы в отдельный интерфейс (сервис) и тогда в нашем исхожном фасадном методе остаётся только простейшая логика и прямые вызовы сервисных методов. Обычно фасадный метод получается настолько простым, что можно позволить себе его не тестировать (если только вы не гонитесь за процентом покрытия), а направить усилия на тестирование отдельных сервисных методов.
Этот же подход позволит вам разработать контракт передачи данных (чтобы не было соблазна хранить состояние в сервисе), что значительно увеличит прозрачность работы метода и лёгкость его тестирования (все данные приходят только через параметры).
Спасибо за статью. А что скажете про Kafka vs RedPanda?
Вообще, я в чём-то с вами согласен — мне тоже давно кажется, что logstash не сильно оптимально написан (хотя, опять же, у нас там кое-где скрипты предобработки выполняются — к примеру, для классификации страниц для просчёта SLA по их типам). Но elasitc corp пилять во всю новые версии со всякими улучшениями производительности и планы по обновлению на последние версии у нас есть.
Поэтому я бы не был бы так категоричен в своих высказываниях, потому что по моему опыту категоричные люди делятся на две категории: супер-боги-знающие-всё и те, кто просто ещё не встретил свой «пистолет с большой мушкой» на своём профессиональном пути.
А что на счёт написания модулей на go? У Hashicorp есть пример. Или не стоит?
Мы сейчас идём другим путём — хотим, чтобы у каждого микросервиса был, скажем, свой микрокластер postrgre или elastic (на контейнерах, чтобы не получать оверхед от виртуалок). Тогда мы сможем ограничить негативное влияние одного микросервиса на другие.
Мы всегда исходим из того, что накосячить могут все и очень разным способом и под каждый способ накосячить невозможно держать отдельного человека, поэтому более стратегически правильно научиться минимизировать взаимовлияние (изоляция + деградация) и время простоя компонент (алерты + автоматизация).
Да, прилично. Трафик от ботов, по предварительной оценке, может доходить до 50%. Мы не для них тут сервера покупаем.
Поэтому, да — занимаемся оптимизацией. Наверное, не так, как если бы у нас было 10 серверов, но всё же активно с этим работаем.
И, пожалуй, самое «тяжёлое» по железу это не C#, а machine learning (ибо big data и все дела) и, как ни странно, frontend (nodejs server side rendering) — там много CPU bound операций (парзинг json, рендеринг html), на которые приходится достаточно большой RPS. Но шарп мы тоже активно переводим на .NET Core (и вот скоро приступим к переводу на .NET Core 3).
Http вызовы + сообщения очередей — это основные каналы взаимодействия, да. И в обоих каналах приложения должны придерживаться объявленного контракта (request/response схемы или model события). У нас также есть система (пока она работает только для api вызовов), которая валидирует при выкладке, что не произошло breaking change в принимаемых api или вызываемых среди всех монолитов и микросервисов (мы умеем по коду автоматически найти схемы request / response приложения).
Это то да, но там, насколько я помню, было то, что даже отправка в syslog из приложения (чтобы на том конце уже дропнули в режиме overflow) было блокирующей операцией и это деградировало отработку запросов в приложении. И это мы говорим про udp! Блокирующая отправка по udp, Карл! Вот это меня удивляет.
Спасибо за разъяснения. А почему тогда такие простые, судя по вашим словам, обёртки недоступны по умолчанию в линуксе? Вот вывод логов через rsyslog из контейнеров блокируется? Потому что мы в ЦИАН уже получали проблемы от этого пару лет назад. Возможно, что-то изменилось или мы что-то не так готовили, но при резком увеличении логов у нас питон глох, если logstash не успевал принимать логи с rsyslog машины.
Ну и про rps — асинхронность она же не про rps, а про масштабирование io heavy приложений (современные микросервисы) и их использование cpu на это дело.
Люди, а за что минусуете? Человек дело говорит. Меня тоже всегда удивляло, что такое сильное ядро не умеет полноценно асинхронно работать, тогда как есть пример как это нормально реализовано в другом ядре.
Этот же подход позволит вам разработать контракт передачи данных (чтобы не было соблазна хранить состояние в сервисе), что значительно увеличит прозрачность работы метода и лёгкость его тестирования (все данные приходят только через параметры).