1. Предпосылки

Мониторинг больших экранов в режиме реального времени, как классическое приложение в области больших данных, широко используется в случаях применения крупными интернет-компаниями, такими как двойной 11 продаж в реальном времени большой экран Taobao, географическое распределение пользователей Didi и другие сценарии, а затем в будущем TAL В бизнес-системе также есть много основных сценариев, которые требуют унифицированного мониторинга с помощью больших экранов в реальном времени. В этой статье в основном представлены решения для мониторинга в реальном времени для больших экранов, представленные в «Будущем облачном мониторинге бизнеса». ";

2. Ключевые моменты

Построение всего большого экрана в реальном времени разделено на две части: техническую и продуктовую.Вот некоторые ключевые моменты и трудности в проекте:

1. Технически

• Расчет индикатора второго уровня в реальном времени для массивных бревен
• Гарантия расчетов при приливном трафике журналов
• Выбор хранилища различных типов индикаторов

2. О товаре

• Каким предприятиям нужны большие экраны в реальном времени
• Какие показатели нужно отображать на большом экране
• Как определить ценность большого экрана в реальном времени

3. Техническая архитектура

1. Детальная архитектура

• Исходный уровень. Исходный уровень в основном включает в себя всю основную информацию журнала и бизнес-данные, связанные с целевым бизнесом, в том числе:
  • Журналы клиентов: скрытая пользователем информация, операции поведения, сетевые запросы, исключения сбоев и т. д.;
  • Журнал ссылок: журнал ключевых шагов, связанных с запросом ссылки на вызов, включая DCDN, исходный сайт, трассировку сервера и т. д.;
  • Бизнес-журналы: ключевая информация журнала о бизнес-событиях, сопоставленная с отслеживанием ключевых бизнес-поведений;
  • Бизнес-данные: многомерная базовая бизнес-информация в структурированной базе данных, такая как пользователи, курсы, заказы и т. д.
• Транспортный уровень: транспортный уровень в основном полагается на канал сбора будущего облачного центра журналов для сбора и распространения исходных данных исходного уровня унифицированным образом.Он должен быть зарегистрирован на платформе центра журналов, чтобы соответствовать спецификациям метаданных. для сбора и доставки;
• Уровень обработки: уровень обработки в основном основан на распределенных вычислительных механизмах в реальном времени для обработки данных.В настоящее время задачи в основном распределены в кластерах Flink и Spark:
  • Flink: механизм обработки потоков с низкой задержкой обработки потоков, поддерживает SQL и в настоящее время имеет два режима развертывания: на K8s и на Yarn.
  • Spark: пакетный движок, микропакет, относительно низкие требования к задержке, поддержка SQL, в настоящее время развернуты на Yarn.
• Уровень хранения: Уровень хранения в основном поддерживает сценарии OLAP в реальном времени с высоким приливным трафиком.После выбора мы строим на основе следующих двух типов компонентов:
  • ClickHouse: СУБД, ориентированная на столбцы, распределенная архитектура, эффективное обновление данных в режиме реального времени, поддержка SQL, богатые функции, но не поддерживает обновление и транзакцию, необходимо обратить внимание на выбор сцены, текущий агент выбирает chproxy, чтобы избежать мульти- распределение данных узлов таблицы сегментов Неравномерное, разделение чтения и записи, повышение доступности;
  • Redis: база данных в памяти с отличной производительностью и атомарной операцией. Она может быстро поддерживать чтение и запись данных в сценариях второго и миллисекундного уровня. Она не поддерживает SQL и крупномасштабные агрессивные запросы индикатора данных в реальном времени.
• Уровень отображения: внутренняя служба и уровень хранения логически взаимодействуют, собирают данные и отображают данные в интерактивном режиме с внешним интерфейсом.Основные протоколы взаимодействия с внешним интерфейсом:
  • Http: инициируется клиентом, частота обновления данных составляет несколько минут и выше, подходит для сценариев с небольшим объемом запросов и частотой запросов;
  • Websocket: отправка на стороне сервера, частота обновления в течение нескольких секунд или меньше, например, продажи второго уровня, онлайн-номер второго уровня, отправка сигнала тревоги второго уровня и т. д.;

2. Обмен опытом

• Гарантия стабильности расчетов в реальном времени в сценариях с большими приливами

  В настоящее время большинство бизнес-моделей, которых мы можем достичь, являются приливными.Взяв в качестве примера онлайн-школы, ежедневные пики живого онлайна в основном сосредоточены в фиксированные периоды времени в течение дня.Когда нет курсов, пики и пики журналов Разница во времени очень велика, и из-за частых итераций версий каждого терминала и сервисного модуля наша оценка объема журнала не может быть просто линейно связана с бизнес-данными.В настоящее время стабильность вычислительных задач может быть улучшена в следующем направления:

  1. стресс тест

     ​ Существуют определенные различия между стресс-тестированием в сценариях вычислений в реальном времени и стресс-тестированием бизнеса.При потоковых вычислениях данных на стабильность влияют число запросов в секунду для данных в реальном времени, размер отдельного фрагмента данных и тип ключевых полей. вычислительных задач Простое моделирование Стандартизированное давление журналов может быть не в состоянии по-настоящему подавить узкие места и проблемы вычислительных задач Поэтому во время стресс-тестирования мы выберем реальные журналы в часы пик онлайн в сочетании со сценариями задач, чтобы создать различные перекосы данных в разумных сценариях.Помимо стресс-тестирования в периоды низкой пиковой нагрузки, мы также будем использовать наименьшую единицу вычислительных ресурсов для тестирования производительности задач в периоды пиковой нагрузки в пределах контролируемого диапазона мощностей в часы пиковой нагрузки.Результаты совпадают.

  2. планирование задач

     ​ Когда бизнес-трафик невелик, многие из наших задач в реальном времени работоспособны. Когда наступает пик бизнес-журналов, часто возникает ситуация пикового пересечения. В это время вычислительные задачи должны быть сосредоточены не только на логике, но и в физической среде развертывания.Мы должны убедиться, что сетевые накладные расходы задачи минимальны, хорошо обмениваться данными с восходящим и нисходящим потоками, гарантировать, что поток данных закрыт в разумной физической компьютерной комнате, и стараться не выполнять длительную передачу данных по сети. Это перекрестное использование, и это может вызвать проблемы с суставами и привести к более крупным авариям.

  3. Масштабирование ресурсов

     В случае достаточного измерения стресса и разумного развертывания задачи всегда будут сценарии, превышающие «расчетный» пик.Для таких сценариев мы можем использовать возможности уровня вычислительного движка, чтобы помочь решить проблему, основываясь на динамическом ресурсов spark на Yarn Mechanism, мы можем реализовать расширение ресурсов задач в наших собственных ресурсах очереди, а также мы тестируем собственный режим на основе flink на k8s для достижения динамического расширения ресурсов. На основании вышеизложенного мы по-прежнему будем резервировать определенный буфер ресурсов для пиков ресурсов для избыточности и не будем полностью полагаться на масштабирование ресурсов, чтобы противостоять пикам.Необходимое расширение ресурсов впереди обязательно.

• Выбор хранилища различных индикаторов

  На большом экране в реальном времени будет несколько измерений и несколько своевременностей данных индикатора.Для разных индикаторов также должны быть разумные варианты хранения:

  1. Показатели второго уровня: ClickHouse и Redis имеют достаточную производительность записи для поддержки показателей второго уровня, таких как qps второго уровня, reqTime, частота ошибок и т. д., но при чтении мы будем различать сценарии, если задействованы страницы. большой объем сбора данных, частые и простые запросы, а также отсутствие сложной статистики или корреляции измерений, мы выберем Redis, например, мониторинг сов.Если необходимо выполнить запрос корреляции ссылок, сложный алгоритм, годовой анализ, и т. д., мы выберем ClickHouse Complete, чтобы вы могли использовать SQL и его собственные богатые функции для поддержки бизнес-потребностей.
  2. Индикаторы минутного уровня +: показатели минут и более, частота записи и частота чтения не высоки, большинство этих показателей для анализа, мы выберем ClickHouse для хранения, если источником данных является mysql, для пикового бизнеса. не высока, мы напрямую читаем бизнес, чтобы получить индикаторы из библиотеки.Для пикового давления MySQL мы будем выполнять инкрементный расчет через сбор бинлога в реальном времени и писать в ClickHouse для чтения.

продуктовое мышление

Мы также накопили много размышлений и опыта в создании продуктов с большим экраном.Мы представим ключевые моменты, упомянутые во втором разделе:

• Каким предприятиям нужны большие экраны в реальном времени

  Большой экран реального времени имеет две наиболее важные особенности:

  Первый - в режиме реального времени. Данные, которые вы видите, меняются со временем. Ожидается, что пользователи будут обращать внимание на последнюю ситуацию, информацию и проблемы через большой экран. Поэтому предприятия, которые очень чувствительны к своевременности, подходят для построения мониторинг больших экранов в режиме реального времени.Например, в живом классе, во время живого урока весь пользовательский опыт сосредоточен в течение 1-2 часов, и в это время необходимо быстро и точно находить проблемы, чтобы выносить суждения и операции. Другим примером является продление курса. Будет временное окно для активности продления. При открытии временного окна будет сформирован короткий пик запросов, что вызовет большую нагрузку на систему. Проблемы будут напрямую влиять на реальную покупку курса пользователем опыта, и будет потеря пользователей.риск, то необходим мониторинг процесса обновления и качества в режиме реального времени.

  Второй особенностью является высокая степень абстрагирования бизнеса и продуктизации.Позиционирование большого экрана в режиме реального времени используется не для анализа проблем и поиска причины проблемы, а для быстрого захвата проблемы и получения последней информации в режиме реального времени. . Когда есть много модулей, вызовов и деловых взаимодействий, а также задействовано много ролей партнеров, ценность большого экрана может быть отражена. Он быстро улучшит координацию и эффективность работы в крупномасштабных операциях. Вам нужно только обратите внимание на живые изменения ваших собственных основных индикаторов, краткие и освежающие.
  Основываясь на вышеуказанных характеристиках, бизнес, который соответствует этим двум характеристикам, должен построить большой экран мониторинга в реальном времени, чтобы удовлетворить потребности мониторинга.

• Какие показатели нужно отображать на большом экране

  Если понятно, что бизнесу нужно мониторить большой экран в режиме реального времени, то как мы судим, какие показатели нужно брать и выводить на большой экран?Исходя из реального опыта, у нас есть следующие критерии:

  Во-первых, это бизнес-показатели, быстро понять его бизнес-структуру, построить четкую основную связь от стороны взаимодействия с пользователем до уровня обслуживания, уровня компонентов и уровня ресурсов, разобрать его на модули и разобрать весь целевой бизнес на несколько. Для основной блок, для бизнес-подразделения нам нужно отобразить индикаторы Полярной звезды этого бизнеса, такие как количество заказов, количество онлайн-людей, количество сообщений и т. д., а для блока технической архитектуры мы необходимо отображать давление, уровень воды и качество этого устройства в режиме реального времени, например интерфейс QPS, производительность системы, индикаторы SLA и т. д., чтобы можно было интуитивно сопоставить бизнес-индикаторы и технические индикаторы во времени, чтобы помочь в анализе проблем. .

  ​ Второй - индекс жалоб клиентов.В дополнение к основной бизнес-ссылке необходимо учитывать отзывы пользователей, такие как изменения в платформе жалоб клиентов, платформе помощи пользователям и другие показатели, а также мониторинг в реальном времени рост числа пользователей, сообщивших о различных проблемах, также может быть интуитивно понятным.Понимание текущего пользовательского опыта и качества, чтобы помочь в оценке проблем.

  Последним является будильник.Для дизайна будильника на большом экране мы контролируем объем будильника в рамках индикаторов, отображаемых на большом экране, так что пользователи видят то, что они получают.Индикаторы, которые необходимо быть предупреждены делятся на раннее предупреждение и тревогу в соответствии с порогом.Она отличается оранжевым и красным цветом в верхней части.При срабатывании тревоги индикатор дисплея изменит цвет, а тревога появится в модуле тревоги, чтобы сохранить будильник.Все пользователи, которые одновременно откроют большой экран, получат один и тот же тревожный толчок, который будет продолжать накапливаться, и страница будет обновляться после обновления страницы.Больше не сохраняется, переведена в фоновое хранилище.

• Как определить ценность большого экрана в реальном времени

  Как измерить ценность большого экрана в реальном времени, после того как были реализованы некоторые бизнес-практики, мы суммировали несколько показателей:

  Прежде всего, это количество активных онлайн-пользователей в критические периоды, такие как пики прямых трансляций, пики непрерывных отчетов и другие сценарии, есть ли внимание пользователя, включая несколько типов внимания роли пользователя, а также может напрямую измерять ценность больших экранов в реальном времени;

  Во-вторых, может ли он прямо или косвенно помочь пользователям найти проблемы.Если произошла авария или проблема, а на большом экране нет отображения и отражения, то этот продукт, несомненно, является неудачным, и большой экран должен охватывать сцену. , Несомненно, важно иметь большой экран, который может постоянно помогать пользователям находить эффективные проблемы в режиме реального времени и помогать пользователям следить за деталями, помогать аварийным сигналам или ранним предупреждениям в реальном времени, а также продолжать помогать пользователям находить эффективные проблемы в реальном времени. в реальном времени.

бизнес-кейс

1. Онлайн-школа в прямом эфире

Большой класс онлайн-школы в прямом эфире, несомненно, является одним из основных бизнес-сценариев онлайн-школы.Участвующие модули также сложны для вызова.С зимних каникул 20 лет мы начали строительство онлайн-школы в реальном времени, отслеживая большие экран.

• Модуль мониторинга разделен, как показано на следующем рисунке.

Как показано на рисунке выше, тройка прямого эфира в основном состоит из прямых трансляций, новостей и взаимодействия.После того, как пользователь войдет в комнату для прямых трансляций, чтобы получить прямую трансляцию, будут частые сцены взаимодействия новостей и взаимодействия.Эти три основных блока глубоко влияет на опыт пользователя в классе.Если есть проблема в какой-либо среде, пользовательский опыт будет ухудшен или даже поведение класса будет прекращено. Ссылка предназначена для мониторинга инфраструктуры всего живого класса, от запроса клиента до ссылки вызова сервера, благодаря хорошей наблюдаемости карты работоспособности вы можете быстро получить представление о том, какой модуль имеет проблему, и что восходящий поток и последующие совместные зависимости. Бизнес-модуль в основном предназначен для помощи в анализе и наблюдении за общей ситуацией.Посещаемость и предполагаемая посещаемость могут оценить общую тенденцию класса за день, а жалобы клиентов могут напрямую отразить реальный опыт живого класса.

• Список индикаторов мониторинга, в основном вокруг индикаторов Полярной звезды и индикаторов, связанных со стабильностью каждого модульного бизнеса.

  модуль

  показатель

  прямая трансляция

  Количество людей, которые живут онлайн, топ-рейтинг прямых трансляций, скорость заморозки, доля людей, которые застряли, и качество прямых трансляций в каждом регионе.

  Информация

  Количество онлайн-чатов, количество сообщений, скорость прибытия, задержка сообщений, количество чатов на каждом конце, частота отбрасывания

  интерактивный

  Популярность взаимодействия на месте, вероятность успеха каждого шага интерактивного вопроса, вероятность успеха каждого конца интерактивного вопроса и распространение клиентской версии интерактивного номера.

  ссылка на сайт

  Карта состояния бизнеса (количество запросов в секунду/коэффициент успеха), ранжирование интерфейсов по количеству запросов в секунду

  бизнес

  Расчетное количество посещаемости, количество людей, которые должны прийти, чтобы купить курс, количество жалоб и отзывов клиентов

  После определения каждого модуля мы провели углубленное общение и сотрудничество с бизнес-группой по сценарию и технической архитектуре каждого модуля, а также разработали несколько проектов мониторинга для многомерного демонтажа и уточнили индикаторы бизнес-путешествий и индикаторы стабильности.

• Эффект большого экрана (основные данные были десенсибилизированы)

  

2. Бизнес по обновлению Peiyou

• Разделение индикатора модуля, как показано на следующем рисунке.
  

  Как показано на рисунке выше, обновление бизнеса Peiyou осуществляется в каждом филиале по всей стране.Каждый филиал будет обновлять отчет в назначенное время в соответствии с сформулированным планом обновления.Когда план обновления филиала с большим количеством людей перекрывается, формирование Пик отчета об обновлении окажет давление на систему.Что касается бизнес-показателей, мы будем отображать план прямой трансляции каждого филиала по стране в этот день, чтобы пользователи могли четко видеть, какой филиал школы будут участвовать в отчете об обновлении в этот день. Перед отчетом об обновлении будут прямые трансляции мероприятий. Мы также будем наблюдать за количеством людей, участвующих в прямой трансляции, и замораживанием ситуации прямой трансляции в каждом филиале. Когда отчет обновляется, мы будем наблюдать в реальном времени давление и качество в реальном времени общей системы обновления, кривую SLA дня, интерфейс в реальном времени QPS Top и RT Top в режиме реального времени на основе карты работоспособности. , бизнес будет отображать пик платежей в режиме реального времени, уровень успеха и количество повторно зарегистрированных участников, чтобы увидеть тенденцию и качество с точки зрения бизнеса.

• Эффект большого экрана (основные данные были десенсибилизированы)

  

будущий план

В настоящее время мы обеспечили мониторинг в режиме реального времени услуг с большим экраном для нескольких бизнес-направлений онлайн-школы Xueersi, Xueersi Peiyou, Xueersi 1v1 и других бизнес-подразделений, а также сформировали ряд классных вещаний в прямом эфире, отчеты о последующих транзакциях, и т. д. Шаблон решения основного сценария может быстро поддерживать сервисы мониторинга большого экрана многих бизнес-направлений.В следующей работе мы сосредоточимся на двух направлениях:

• Предоставьте более полные возможности самообслуживания и обобщите зрелые решения для мониторинга бизнеса, чтобы пользователи могли самостоятельно настраивать большие экраны и реализовывать сборку большого экрана с помощью простой настройки и перетаскивания.
• Расширяйте больше бизнес-сценариев и создавайте больше сценарных решений, надеясь накопить опыт за счет большего количества реальных бизнес-боев, создавайте больше сценарных решений, расширяйте возможности аналогичных предприятий, сокращайте расходы и повышайте эффективность.

Компания Future Cloud-Business Monitoring стремится предоставлять комплексные решения для мониторинга Преподаватели в области обработки данных в реальном времени, OLAP и продуктов для обработки данных могут присоединиться к нам, чтобы расширить возможности будущего бизнеса с помощью данных!