Комментарии 7
Используете ли head/tail сэмплинг на коллекторе?
Нет, не используем.
Head сэмплинг - точно не наш вариант, так как у нас в экосистеме множество взаимосвязанных продуктов, разрабатываемых и поддерживаемых разными командами. В результате предугадать по первым спанам - нужен этот трейс какой-либо команде или нет практически невозможно. Как и оперативно менять эти правила, при появлении у одного из продуктов новых методов API/процессов.
Tail сэмплинг мог бы теоретически пригодиться, но он достаточно дорог и сложен в реализации на наших объемах и все равно требует договоренностей о правилах со всеми продуктами. Кроме этого, у нас есть длительные асинхронные (несколько дней) бизнес-процессы - ожидать несколько дней поступления всех спанов трейса не вариант.
В результате оказалось проще научится масштабироваться и собирать 100% трейсов. Вот тут еще аргументы за и против: https://opentelemetry.io/docs/concepts/sampling/
Я вообще ничего не понял, кроме того что в МТС работают крутые ребята. Молодцы!
А я ещё раз убедился в прописной истине: чем сложнее система, тем больше в ней багов.
Например, после недавнего отказа от подписки МТС.Premium компания начала списывать деньги за каждый 1 КБ интернет-трафика, округляя его до 200 КБ. Казалось бы, немного — всего 2,44 ₽ за сессию. Но в месяц набегает прилично, ни за что ни про что.
@bocharovf, вы уж там разберитесь, пожалуйста.
Да, Clickhouse не очень хорош при обработке большого кол-ва запросов, НО у него из коробки есть возможность самостоятельно читать очереди в брокерах сообщений. Т.е. можно лить весь трафик в условный rabbit / kafka с удобной вам скоростью, а дальше Clickhouse будет самостоятельно стягивать необходимую информацию с комфортной ему скоростью
Есть ощущение, что это будет эффективнее, чем размазывать запросы через round robin
Идея хорошая, но нам нужно разложить каждый спан в JSON из топика Kafka в несколько таблиц, которыми оперирует Jaeger UI и выполнить ряд преобразований полей, которые делает Jaeger Ingester (например, он превращает пары ключ-значение с тегами в JSON в два отдельных массива - один с ключами, второй со значениями тегов в таблице).
Да, учитывая нюансы, это выглядит как +1 ETL сервис в цепочке поставок.
Но в свою очередь он:
Решает проблему скейлинга кликхауса
Сам элементарно скейлится
Позволяет гибко крутить-вертеть данные, буквально в полёте и маршрутизировать поток данных как и куда хотите.
Пишется на любом удобном языке меньше, чем за 1 спринт
Не требует регулярных доработок (сделал и забыл)
Распределенная трассировка с Jaeger и Clickhouse