предисловие
Эта статья от 25 апреля 2020 г., интерфейсный чат в начале пятого сеанса специального гостя совместного сеанса «Фронтальный мониторинг» - руководитель группы мониторинга внешнего интерфейса Dingding.Свеча Слон (slashhuang)Совместное использование записи«Antic Front End - Как проектировать фасадный анализ в реальном времени и аварийной сигнализации».
текст начинается
Привет всем, я Candlexiang из DingTalk, и моя сегодняшняя тема: «Как команда DingTalk Front-End создает систему мониторинга трафика уровня миллиарда».
представление о себе
Сначала позвольте мне представиться. Я закончил учебу в 2013 году и пришел в DingTalk в 2017. Когда я присоединился к DingTalk, я был P6. Затем я получил некоторые возможности продвижения по службе, выполняя мониторинг внешнего интерфейса, некоторые модульные пакеты кода, эффективность и другие инструменты.
О внешнем интерфейсе DingTalk
DingTalk развивался чрезвычайно быстро с момента своего создания в конце 2014 года, и внешний мониторинг DingTalk также развивается соответствующим образом. У нас 100 миллионов пользователей и 10 миллионов корпоративных пользователей. Интерфейсные продукты включают Android, iOS, настольные компьютеры, апплеты, H5 и т. д. Выпуск интерфейсных приложений также охватывает полную версию и выпуск в оттенках серого.
Вызов сто миллионов движения
Я считаю, что для такой платформы стоимостью в миллиард долларов, в дополнение к системе мониторинга внешнего интерфейса, у многих мелких партнеров также есть чувство тела.Чтобы обеспечить стабильность общего интерфейса DingTalk, некоторые средства технической эксплуатации необходимо, включая некоторые ситуации людей. Теперь у нас в целом более 100 разработчиков интерфейса, а затем в наших технологических модулях есть IM, адресная книга, прямая трансляция, обучение, документация, оборудование и другие услуги, которые являются атрибутами стороны B.
достижение
Позвольте мне сначала рассказать о наших достижениях: на сегодняшний день он покрывает 100% всех наших h5 и апплетов и поддерживает потребности в мониторинге более чем 100 человек переднего плана. Количество журналов, отслеживаемых внешним интерфейсом, достигло 10 миллиардов, а количество отслеживаемых больших дисков превышает 100. Он может обнаруживать онлайн-проблемы за одну минуту и обнаруживать нечеткие проблемы за одну минуту. С точки зрения человеческого вклада, он всегда поддерживается двумя ответственными лицами.В большинстве случаев я в основном отвечаю за общую ситуацию мониторинга.Поэтому, с точки зрения человеческого вклада, наши затраты относительно низки.
Две диаграммы тенденций на приведенном выше рисунке представляют собой основные структуры продуктов, которые мы отслеживаем, одна — наша диаграмма тенденций мониторинга, а другая — наша бизнес-папка на большом диске для ведения различных предприятий.В то же время у нас есть унифицированная производственная среда. программы, Н5 мониторят рынок.
Эволюция
Далее я расскажу о том, как мы развивали систему для фронтенд-мониторинга DingTalk и получили хороший результат.
Учитывая, что есть много мелких партнеров, которые не занимаются фронтенд-мониторингом, здесь я сначала расскажу о некоторых базовых знаниях, чтобы расширить, как спроектировать систему фронтенд-мониторинга.
Давайте посмотрим на приведенный выше код, const создает объект, а foot.a.b = c. можно увидетьЭто очень классический код NPE, который является исключением с нулевой точкой., который очень легко появляется во внешнем коде. Это вызовет ошибку: ** Uncaught TypeError: Cannot set property 'b' of undefined**.
Для такой ошибки, как наша система внешнего мониторинга фиксирует эту ошибку и находит ее в течение минуты после того, как она произошла на стороне пользователя? Давайте посмотрим, как делается традиционный подход:
- Сначала напишите SDK внешнего интерфейса для сбора данных.
- Выберите схему уведомления, чтобы уведомить передовой журнал на сервер
Здесь я демонстрирую использование тега изображения для создания тега изображения и настройки его src для указания на соответствующий сервер журналов для отправки соответствующего журнала.
Мы используем window.onerror для захвата глобальных ошибок. Затем перехваченные ошибки отправляются на внешний сервер мониторинга в правой части рисунка выше путем создания тега изображения.
Приведенный выше код — просто демонстрация псевдокода, я написал его относительно просто.
Для традиционной системы мониторинга, основанной на анализе журналов, вы должны сначала знать, откуда поступает журнал.Поэтому, когда мы собираем каждый журнал во внешнем интерфейсе, у нас есть идентификатор приложения, который я называю здесь spmId.Источник журнала идентифицируется spmId, а затем журнал сохраняется на соответствующем сервере мониторинга, таким образом завершая очень простую прямую связь.
отЗамкнутый цикл генерации, сбора и хранения логов.,очень простой. На самом деле, увидев микрознание, увидев такую простую реализацию, а затемРасширьте типы записей и увеличьте возможности сбора и хранения.По сути, вы можете построить относительно простую систему внешнего мониторинга.
Вообще говоря, простая система внешнего мониторинга и анализа должна включать следующие три измерения:
- Первая — это ошибка js, связанная со стабильностью.
- Второй связан с производительностью
- Третий связан с коэффициентом успеха API
В платформе мониторинга нам нужно сделать некоторое хранилище журналов, предоставить журнал мониторинга серверу платформы визуализации и нарисовать приведенную выше картину, предоставив некоторые службы API. Например, первый — это показатель успешности интерфейса.
Я думаю, что с точки зрения выбора технологии для многих студентов, изучающих интерфейс, у которых есть небольшая база Node или серверной части, они могут в основном сделать простую демонстрацию. Однако для такой, казалось бы, целостной системы есть ли какие-либо проблемы с внешним мониторингом? Может ли он удовлетворить потребности в мониторинге платформы с миллиардным трафиком, такой как DingTalk?
В левой части рисунка выше показан процесс доступа наших разработчиков к внешнему мониторингу, включая этап разработки, этап тестирования и этап запуска. При реализации фронтенд-мониторинга мы требуем от всех разработчиков активно наблюдать и мониторить рынок не менее 30 минут после итеративного запуска приложения, и наблюдать за тремя показателями:
- js error
- performance
- процент успеха API
Для текущего размера команды, состоящей из более чем 100 студентов, работающих на переднем крае, стоимость труда составляет 100 раз по 30 минут.В то же время для Dingding, продукта корпоративного уровня, у нас очень высокие требования к онлайн-стабильности.Отказоустойчивость чрезвычайно низкая, поэтому также требуются ежедневные проверки онлайн-приложений, поэтому стоимость рабочей силы очень высока.
С точки зрения опыта разработчика, когда разработчик проверяет мониторинг: сначала он заходит на платформу визуального анализа, чтобы посмотреть, есть ли какие-либо журналы ошибок. Здесь есть очень важный момент, а именно: является ли журнал, который мы видим на платформе мониторинга и анализа, журналом «страницы внешнего интерфейса»?
Не обязательно. Почему? Потому что для пользователя открывается не только внешняя страница, но и веб-просмотр контейнера, контейнера приложения, оператора и т. д. за внешней страницей.
Например, нашу страницу можно открыть в контейнере WeChat, контейнере Toutiao или контейнере DingTalk. так что выСобранный источник логов — это не просто страница интерфейса, и веб-просмотр контейнера, и при этом мы столкнемся с множеством операторов. Например, мы часто видим рекламу, вставленную на главную страницу, а также некоторые производители мобильных телефонов, такие как vivo, Huawei и т. д., также вставляют соответствующие скрипты на наши страницы. Таким образом, журналы, собираемые платформой мониторинга и анализа, представляют собой не только журналы внешнего интерфейса, но фактически журналы пользовательского терминала, соответствующие страницам внешнего интерфейса.
Как правило, мы сталкиваемся со следующими тремя журналами помех:
- Первый — это внедрение сторонних скриптов.
- Второй — внедрение скрипта контейнера
- Третий вводится скриптом производителя телефона
Например, выше показано одно из наших онлайн-приложений. Частота ошибок js составляет около 0,08%. Для такого размера, как Dingding, эта частота ошибок влияет на количество пользователей.
Давайте посмотрим, что на самом деле представляет собой соответствующая ошибка?Ошибка скрипта, WeixinJSBridge не определен, toutiaoJSBridge не определен, 20 vivoNewsDetailPage, об этих вещах в основном можно судить по информации об ошибках, и они не имеют ничего общего с бизнес-ошибками.
Таким образом, мы можем прийти к первому выводу, что некоторые ошибки, генерируемые фронтенд-мониторингом, на самом деле не связаны с бизнесом, что может противоречить познанию многих людей.
Давайте рассмотрим другой вопрос. На рисунке слева показана кривая выпуска нашей настольной версии. DingTalk — одна из немногих платформ с очень большим количеством настольных компьютеров в Китае и даже в мире. Рабочий стол DingTalk в основном представляет собой итерацию одной или двух недель.Поскольку интерфейсный код на рабочем столе представлен в виде автономного пакета, его трудно обновлять и исправлять, а требования к стабильности внешнего интерфейса очень высоки.
Для нашего настольного терминала сегодня уже существует более 100 онлайн-версий, и журналы, сообщаемые таким количеством версий, используют один и тот же идентификатор приложения. Как мы осуществляем многоуровневый мониторинг? Какова неравномерность онлайн-трафика? мониторинг, чтобы предотвратить перегрузку мониторинга выпуска небольшого трафика?
Эти проблемы часто встречаются в бизнес-сценариях DingTalk.Наша степень детализации мониторинга должна быть совместима с интерфейсной версией, а отслеживаемые журналы должны поддерживать больше измерений. Например, мониторинг осуществляется в единицах приложения и версии выпуска, этих двух переменных.
Давайте посмотрим на другой случай. DingTalk имеет сотни клиентских приложений. Было бы преувеличением сообщать о тревоге один раз для каждого приложения. В основном, в группе тревог более 500 журналов в день. Феномен прокрутки экрана очень серьезный , и много ошибок в сети. ошибка длинного хвоста. То есть он хоть и имеет будильник, но его не нужно дорабатывать и так далее. Причина ошибки длинного хвоста в том, что хотя я исправил проблему, у пользователя может не быть полного доступа к последней версии.
Таким образом, вывод 3 заключается в том, что трудозатраты на нашу операцию мониторинга очень высоки.Требование для внешнего мониторинга состоит не только в том, чтобы сообщать о тревоге, но и в том, чтобы ваша тревога была интуитивно понятной и работала в режиме реального времени, а также поддерживала некоторые короткие -срочное отключение и фильтрация ошибок и т.п. средства.
Прочитав приведенные выше три случая, давайте посмотрим, как спроектировать систему мониторинга, которая сможет обслуживать 300 миллионов человек.
Прежде всего, давайте определим цели дизайна мониторинга.То, что DingTalk должен сделать для внешнего мониторинга на уровне предприятия, это: восприятие за одну минуту, позиционирование за пять минут и восстановление за десять минут. Назовем эту систему мониторинга системой 2.0.
Мы определяем следующие уровни возможностей для внешнего мониторинга 2.0 на основе 1.0.
Во-первых, быть ближе к реальному бизнесу, снизить затраты на оплату труда и позволить деловым сторонам вмешиваться с низкими затратами. В то же время для системы сигнализации требуется обеспечить быструю тревогу, квази-тревогу и поддержку пользовательской тревоги. Мы установили внутреннюю планку, то есть точность внешнего мониторинга должна достигать более 90%, трудозатраты должны быть сокращены на 20 минут на человека, а сигнализация и большой диск должны поддерживать индивидуальную конфигурацию.
На приведенном выше рисунке показана общая схема оркестровки компонентов мониторинга. Слева находится легенда, синяя часть представляет компоненты мониторинга версии 1.0, а темно-зеленая часть представляет новые компоненты мониторинга версии 2.0.
индивидуальная коллекция
Первый находится на стороне сбора журналов, который поддерживает пользовательский сбор в дополнение к сбору обычных бизнес-данных и данных мониторинга.
Аналитика Интеллект
Аналитическая аналитика добавляет возможности настройки анализа.
Тревоги в реальном времени
В реальном времени тревога увеличила требования к 1-минутной тревоге и 5-минутному позиционированию.
Реализация наиболее критической технологии
Точно так же синяя часть — это система оригинальной версии 1.0, а темно-зеленая — наша новая система. Мы обнаружим, что на стороне сбора и потребления журналов мы добавили модуль с именемжурнал двойной записи.
Журнал используется двумя системами, одна для оповещения в реальном времени, а другая для анализа:
- После того, как сервер получит журнал, он вместе проведет анализ хранилища, чтобы выполнить некоторые службы отчетов по мониторингу;
- Второй блок знакомит с системой расчета лог-минут для оповещения в реальном времени.
Многие студенты подумают, что двойное написание журналов на самом деле является пустой тратой очень большой системы, а журнал потребляется двумя системами. На самом деле внешний мониторинг Dingding опирается на очень зрелую систему и инфраструктуру потребления журналов Alibaba. Благодаря двустороннему распределению журналов он быстро потребляется, поэтому планирование минутной вычислительной системы во всей системе мониторинга заранее подготовлено для удовлетворения требования 1-минутной тревоги Это наша основная техническая идея в этой области. .
Под пунктирной фиолетовой линией на изображении выше находится точка зрения пользователя. Сторона пользователя касается двух частей.Первая часть-это внешний SDK для мониторинга.У нас есть SDK H5 и апплет.Вторая часть-это платформа, включая платформу анализа и платформу сигнализации.
сценарий реального случая
Давайте рассмотрим реальный случай. Пользователь столкнулся с двумя ошибками js. Эти две ошибки js являются классическими ошибками NPE во внешнем интерфейсе.
Первый происходит на iPad + браузер Baidu. Второй происходит на веб-просмотре Android + Toutiao , В результате мы обнаружим, что наш клиент сообщает об ошибках двух типов:
- Истинная ошибка: Uncaught TypeError: невозможно установить свойство «b» неопределенного.
- Хост вводит много информации о помехах, например, браузер Baidu будет вводить MyAppHrefLink, который не определен.
Многие студенты, возможно, не заметили этого. Мы тщательно проверили. Браузер Baidu будет внедрять MyAppHrefLink не определен. Toutiao также внедрит немного Toutiao jsBridge.
После того, как журнал достигает сервера, мы сначалаЖурнал очищается, чтобы отфильтровать все журналы помех хоста., чтобы убедиться, что наша система оповещения использует ошибки журнала, которые происходят в реальном бизнесе. Это первый модуль в желтой области:очистка журнала
Далее мы выполняем группировку журналов, группируя журналы приложения A spmId=A и приложения B и группируя их по идентификаторам приложений A и B. Отфильтрованные журналы рассчитываются в режиме реального времени.
После этого шагаПоток журнала передается в элемент индикатора тревоги для расчета в реальном времени., обработчик правил сигналов тревоги отправляет соответствующие инструкции машине, соответствующей Map Reduce, для выполнения некоторой обработки.
Например, частота сбоев JS Error = номер журнала ошибок JS, разделенный на номер PV. Когда результат расчета журнала превышает 6%, будет выдана групповая тревога DingTalk, а когда частота отказов превысит 15%, будет выдана тревога SMS.
Интерфейсный мониторинг DingTalk 2.0
Журналы мониторинга
Применяя один и тот же процесс к разным показателям, таким как показатель успешности API, уровень ошибок js, данные pv и т. д., мы можем построить систему мониторинга, которая удовлетворяет 1-минутному восприятию в минутной вычислительной системе.
Архитектура системы сигнализации
Что касается системы сигнализации, на приведенном выше рисунке показана очень классическая система мониторинга от нашего отдела Ali R & D. Заинтересованные студенты могут выполнить поиск sunfire на infoQ, чтобы увидеть более подробное введение в архитектуру.
Общая сводка по архитектуре журнала
По сути, это то, чем я хочу поделиться сегодня, как мы думаем и как реализовать интерфейсный мониторинг DingTalk в процессе перехода от версии 1.0 к версии 2.0. Здесь, позвольте мне дать вам краткое резюме:
- Самая важная техническая идея заключается в том, чтобы предварить расположение компонентов журнала сигнализации.Наша реализация заключается в двойной записи журнала в систему анализа и в систему сигнализации.
- Поддержите механизм правил тревог на платформе тревог, по-настоящему реализуйте настройку тревог, тревогу можно классифицировать и так далее.
- Для внешнего интерфейса мы не только страница внешнего интерфейса, мы больше обращены к пользовательскому терминалу.
заключительные замечания
Что ж, это то, чем я хочу поделиться сегодня, как внешний мониторинг DingTalk обеспечивает онлайн-стабильность DingTalk с объемом 100 миллионов, более чем 100 интерфейсами и более чем 600 интерфейсными страницами.
Ниже приведена техническая колонка передней части Dingding, есть колонка Zhihu и колонка Nuggets,Мы набираем таланты, добро пожаловать, чтобы связаться со мной.