Конференция раннего чата по интерфейсу, новая отправная точка для развития интерфейса, была проведена совместно с Nuggets. Добавьте WeChat codingdreamer в эксклюзивную внутреннюю группу поддержки конференции и выиграйте на новой стартовой линии.

---

14-я сессия Front-end Growth and Promotion, 8-29 будет в прямом эфире, 9 лекторов (Ant Financial Services / Tax Friends и т. д.),Нажмите на меня, чтобы сесть в машину 👉 (Адрес регистрации):

---

Текст выглядит следующим образом

Эта статья является 5-й - Специальный лектор по созданию системы внешнего мониторинга - Делится Алланом - Краткая версия лекции (пожалуйста, смотрите записанное видео для полной версии):

предисловие

Разработчики перед видео, всем добрый день!

Тема, которой я делюсь сегодня, это "Как реализовать многотерминальную платформу мониторинга ошибок". Давайте сначала кратко представимся. Я Аллан из Beibei-Big Front-end Architecture Group. В настоящее время я участвую в обслуживании системы контроля ошибок группы и инженерной стандартизации. В то же время я Я также являюсь частью «Практики фронтенд-разработки React+Redux».

Без лишних слов, сегодня я поделюсь с вами тем, как Beibei разработала и внедрила эту платформу мониторинга ошибок. Я надеюсь, что этот обмен может заставить всех «понять, использовать и забрать». Мой сегодняшний репост продлится около часа, надеюсь все не будут торопиться и будут морально готовы.

содержание

Ценность технологий заключается в решении бизнес-задач. так что я пройдупервые две главы, чтобы объединить реальную ситуацию со стороны Beibei, чтобы объяснить, почему мы это делаем, и ценность, которую приносит эта платформа мониторинга ошибок.Глава 3Поговорим о технической реализации,последняя главаСуммировать.

Глава 1: Статус группы

Далее мы официально начинаем. Прежде всего, позвольте мне кратко представить бизнес-статус Beibei Group. В 2014 году Beibei основала Beibei.com, платформу для покупок для мам и малышей, в 2017 году Beidian, дисконтный торговый центр на основе участников, в 2018 году Beidai, платформу финансовых технологий, в первой половине прошлого года была основана Beichang. , и за полгода была создана провинция Бэйбэй. В то же время у Beibei также есть ряд предпринимательских бизнесов: прямые трансляции знаменитостей, новая розничная торговля Beichang и т. Д.

На приведенной выше временной шкале мы видим, что у Beibei Group вначале был один проект на три года, один проект в год, а затем более одного проекта в год, и бизнес Beibei диверсифицировался и быстро развивался. Что ж, это приводит к первому статус-кво группы: много дел!

После разговора о деловой ситуации внутри группы давайте взглянем на текущую ситуацию во всей отрасли. Я сам 14 лет занимаюсь фронтенд-разработкой и 15 лет занимаюсь фронтенд-разработкой. Комплексное развитие мобильного интернета произошло в 2014 году, так какие же изменения произошли с нашим фронтендом за последние 7 лет?

• До полного развития мобильного Интернета большинство приложений оставалось на стороне ПК;
• Когда появился мобильный интернет, приложения стали переходить с ПК на мобильные, то есть на нашу платформу iOS и платформу Android;
• Потом, чтобы не развиваться по обеим сторонам проекта, на вебвью появился H5;
• Однако производительность и возможности H5 не так хороши, как у родного приложения, поэтому в последние годы появились Hybrid, Weex, RN и Flutter;
• А с появлением различных небольших программ (апплет WeChat, апплет Alipay, апплет DingTalk, апплет Douyin);
• В то же время стек интерфейсных технологий также изменился с jQuery в начале на Angular, Vue, React и так далее.

Поэтому, как фронтенд-разработчики, мы должны каждый год изучать новые технологии. Это развитие всей нашей отрасли, и оно разделяет наш стек конечных/платформенных/технологических продуктов и становится все более и более запутанным. Я верю, что все чувствуют то же самое! Затем это приводит ко второму статус-кво нашей группы: Duoduo!

Диверсифицированное развитие бизнеса группыПривести кСтатус 1: Предприятий много, разделение отраслиПривести кСтатус 2: Терминалов много. И количество бизнеса и количество терминалов большев конечном итоге привести кКоличество проектов в нашей группе увеличивается! Согласно моей последней статистике, в настоящее время Beibei насчитывает более 80 онлайн-компаний! Что ж, если эти более 80 предприятий примут сторонние решения, сколько нам придется платить с точки зрения предприятия?

Давайте сначала рассмотрим несколько распространенных сторонних продуктов:

• Давайте сначала посмотрим на Fundebug: Платная версия 159 Каждый месяц данных этой версии нет у нас, поэтому мы точно не будем использовать ее с точки зрения безопасности данных, а локальная версия, где данные могут храниться на собственном сервере, стоит 300 000. Если платить такую ​​пошлину каждый год, то стоимость все равно довольно большая.
• Снова взглянем на FrontJS: FrontJS Premium — 899 в месяц, Pro — 2999 в месяц.
• Последний взгляд на Sentry: Sentry стоит 80 долларов в месяц. Затем мы используем FrontJS в качестве эталона для выставления счетов и вычисляем простую учетную запись для этих 80 проектов. 80 проектов, 12 месяцев, 299 в месяц за проект, стоимость 280 000 7 за год. И мы подсчитали, что на создание такой системы уйдет 180 человеко-дней, а это 150 000 юаней. А после разработки нет необходимости платить такую ​​плату каждый год.

Глава 2: Зачем выбирать собственные исследования и разработки

Конечно, мы не можем простоценаЭтот угол используется в качестве эталона измерения для нашей собственной разработки этой платформы мониторинга ошибок. В конце концов, в прошлом году Beibei также привлекла финансирование в размере 860 миллионов долларов, верно?

Итак, давайте кратко проанализируем конкурирующие продукты, в первую очередь Sentry. Sentry не поддерживает Weex, апплет. Да и стабильность не очень, 100% зависает, когда ошибка вылетает большими цифрами.

• [Короткая история 1] Бэйбэй фактически использовал Sentry до использования разработанной им платформы мониторинга ошибок.Поскольку Sentry имеет дело с большим количеством ошибок, веб-страница Sentry не может быть открыта, и почти 100% ошибок появляются, когда они достигают определенного количество ошибок. , появляется 504. Прежде чем вернуться в нормальное состояние, необходимо дождаться, пока Sentry обработает ошибку, что продлит время отклика на ошибку. Снова взглянув на Fundebug, Fundebug не поддерживает Weex, а статистика недостаточно подробная для нас. Давайте еще раз взглянем на Bugly.Bugly может быть известен студентам, изучающим клиентскую сторону, но студенты, работающие с внешним интерфейсом, могут быть не очень ясны. Bugly поддерживает только платформы Android и iOS, а также некоторые игровые сценарии (Cocos2d, Unity3D) и не поддерживает расширения.
• [Маленькая история 2] Но из-за ошибок мы можем узнать количество ошибок, неправильных моделей и другую базовую информацию, но неправильные модели/версии/версии системы разбросаны, и информация об ошибке только: ошибка при создании экземпляра weex, неправильная формат содержимого файла Weex. Но единственная информация не может найти и решить проблему! Наконец, давайте взглянем на FrontJS. FrontJS поддерживает только веб и небольшие программы. Количество событий мониторинга в минуту ограничено (расширенная версия), уведомление о тревоге ограничено, расширение не поддерживается, а выбор исторических событий для проблемы с фильтрацией также ограничены.

Поэтому мы сравниваем их с собственной платформой мониторинга ошибок (статистика отраслевых решений может быть ошибочной, только для справки). Можно обнаружить, что отраслевые решения имеют свои преимущества, но они не могут соответствовать требованиям Beibei. Нам нужны продукты, которые можно отследить в течение более длительного времени, более стабильные и применимые ко всем сторонам (интерфейс, клиент, узел) и т. д.

Поэтому после синтеза бизнес-решения мы, наконец, решили разработать его самостоятельно, учитывая такие параметры, как стабильность, согласованность, масштабируемость, безопасность и стоимость.

Глава 3: Анализ технологии Скайнет

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

Захватывайте и сообщайте об ошибках на уровне доступа к приложениям через SDK. Сообщенные данные передаются через kafka в ES для временного хранения. Затем перейдите в диспетчерский центр, чтобы выполнить сценарий очистки. После очистки данные сохраняются и хранятся в MySQL. Наконец, Node.js предоставляет интерфейс для визуализации, и, наконец, отображаются данные об ошибках. Во всем этом процессе кажется много незнакомых слов, не бойтесь, не паникуйте, мы абстрагируемся от этой картинки.

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

Это все еще выглядит немного сложно, не так ли? Неважно, начнем с реализации минимального замкнутого цикла. Поскольку каждый является фронтенд-разработчиком, давайте начнем с реализации фронтенд-мониторинга ошибок!

Давайте сначала смоделируем онлайн-ошибку:

Как показано на скриншоте выше, это проект vue, и мы выполняем метод this.foo(), который не объявлен в created. В сети обязательно будет ошибка, верно? Итак, через минуту или две мы подошли к платформе визуализации и видим, что эта ошибка появилась в списке главной страницы платформы мониторинга ошибок, вверху — тренд ошибки, по горизонтальной оси — время ошибки, по вертикали ось — это количество ошибок, а красный цвет внизу — список ошибок. Щелкнув по списку, мы попадаем на страницу сведений об ошибке. На среднем снимке экрана мы видим информацию о стеке ошибок. Фактически, мы можем с первого взгляда определить местонахождение ошибки. Однако, чтобы облегчить разработчикам поиск проблемы, мы также отображаем информацию о среде, в которой возникает текущая ошибка, справа. На нем есть информация об оборудовании и информация об окружающей среде!

Итак, от возникновения онлайн-ошибки до окончательной визуализации, что произошло посередине?

Имея в виду этот вопрос, мы объясним его подробно на блок-схеме архитектуры, которую мы абстрагировали ранее. Начнем с веб-стороны, с которой лучше всего знакомы наши студенты, изучающие фронтенд!

1. SDK – Сбор/отчет об ошибках

1. Как устроен SDK?

Нет сомнения, что источник данных визуализации собирается с помощью SDK в источнике ошибки, поэтому начнем с SDK.

Мы разделяем SDK на два типа: автоматический и ручной. Ручной обычно используется в пробе/улове бизнеса.Мы разделяем ручное сообщение об ошибках на три уровня: ошибка, предупреждение и информация. В случае, если ручной отчет не попадает, мы используем автоматический отчет, чтобы докопаться до сути!

2. Механизм перехвата ошибок

Далее проанализируем несколько часто используемых механизмов перехвата ошибок (выделены на рисунке ниже).

[1] Окно монитора.onerror

Когда возникает ошибка времени выполнения JavaScript (включая синтаксические ошибки и исключения, возникающие в обработчиках), событие ошибки с использованием интерфейса ErrorEvent будет запущено в окне и вызвано методом window.onerror() .

[2] Прослушивание события необработанного отклонения

когдаPromiseЗапускается, когда отклонено и не обработаноunhandledrejectionсобытие. Следовательно, это событие можно отслеживать, а информацию об ошибке можно записывать и сообщать.

[3] Ошибка междоменного сценария: Ошибка сценария.

Поскольку мы обычно храним статические ресурсы на сторонних доменных именах, таких как cdn, window.onerror в текущем имени бизнес-домена будет единообразно отображать такие ошибки, как Script error . Таким образом, для решения этой проблемы обычно есть два решения:

• Серверная часть настраивает Access-Control-Allow-origin, а внешняя часть настраивает crossorigin в теге script.
• Взламывать нативные методы, использовать try/catch для обхода, выдавать ошибки

Здесь мы поговорим о втором типе.Поскольку браузер не будет перехватывать исключение, вызванное _try-catch_, мы используем перехват нативного метода и оборачиваем нативный метод функцией try/catch для его обработки. Пример кода выглядит следующим образом:

Это шаблон проектирования АОП (аспектно-ориентированное программирование).Когда возникает ошибка, мы повторно выбрасываем ошибку в catch и, наконец, выбрасываем собственный addEventListener для выполнения. Чтобы облегчить понимание, мы покажем этот процесс решения:


Как показано на рисунке выше, если бизнес находится на a.com, а статические ресурсы — на b.com, и в это время не выполняется обработка, отчет об ошибке js для доменного имени b будет отображаться как: Ошибка сценария . Но мы хотим получить полный стек ошибок, поэтому мы перехватываем нативное событие, пытаемся/перехватываем его, а затем выбрасываем ошибку генерации исключения.Когда исключение выдается снова, выполняется тот же код домена, поэтому мы можем получить полный сообщение об ошибке стека. Это позволяет фиксировать ошибки и создавать отчеты.

[4] Другие технологические стеки — Vue.js

В проекте Vue есть собственный механизм захвата ошибок, Vue.config.errorHandler (errorCaptured).Здесь мы перехватываем Vue.config.errorHandler, чтобы сообщать о перехвате ошибок при возникновении ошибки в проекте Vue. Пример кода выглядит следующим образом:

Здесь по-прежнему используется режим АОП (непонятливые студенты могут поискать и понять). Сначала назначьте нативный метод Vue.config.errorHandler временной переменной, затем сообщите об этом в ней при возникновении ошибки и, наконец, продолжите выполнение оригинального errorHandler.

[5] Другие технологические стеки — React.js

React.js также имеет свой собственный набор механизмов захвата ошибок.Мы сначала объявляем компонент границы ошибки в SDK, а затем ссылаемся на этот компонент в SDK в бизнесе и позволяем ему оборачивать ваш тег реакции. Когда ошибка возникает в подкомпоненте, ошибка переходит к компоненту границы ошибки SDK, и ошибка может быть обнаружена и сообщена непосредственно в цикле объявления componentDidCatch внутри. Этот компонент границы ошибки на самом деле является компонентом более высокого порядка (что такое компонент более высокого порядка? Популярное понимание: компонент React, который обертывает другой компонент React).

3. Экологический сбор

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

3.1 Принципы сбора экологической информации

Чтобы получить информацию об окружающей среде, нам сначала нужно посмотреть, попадает ли она в активный отчет. Если да, то используйте активно сообщаемую информацию об окружающей среде; если нет, то посмотрите, попадает ли она в отчет гибридного интерфейса (используя возможность клиента захват информации об окружающей среде). Если он попадает в информацию об окружающей среде, собранную клиентом, то используйте информацию об окружающей среде, собранную клиентом; если нет, мы проверим, попадает ли информация об окружающей среде, собранная UA (UserAgent). Это 3 способа сбора информации об окружающей среде.

Давайте посмотрим на предыдущую классификацию среды, бизнес-информация: через активные отчеты, отчеты о возможностях клиента и отчеты UA; информация об устройстве: с использованием отчетов о возможностях клиента и отчетов UA; информация о сети: с использованием отчетов о возможностях клиента и отчетов UA; информация о версии может можно получить непосредственно в SDK, запросив ('./package.json').version.

4. Зачем проводить сбор?

На самом деле, мы смогли определить местонахождение ошибки с помощью предыдущей информации об ошибке и информации об окружающей среде, так зачем нам собирать данные о поведении? Взгляните на скриншот ниже (с нашей платформы мониторинга ошибок):

На приведенном выше снимке экрана мы можем четко распознать ссылку, по которой возникает ошибка «псевдоним» undefined. Сначала из браузера отправить поведение запроса, затем поведение щелчка пользователя, затем поведение печати консоли и, наконец, отображение этой ошибки. Мы можем полностью воспроизвести происхождение ошибки. Вот почему мы это делаем!

4.1 Классификация коллекции поведения

Мы просто классифицируем поведение на: поведение пользователя, поведение браузера и поведение печати в консоли.

Среди них поведение пользователя включает в себя наш обычный щелчок, прокрутку, фокусировку/расфокусировку, длительное нажатие и т. д.; поведение браузера включает инициирование запроса, переход, перемотку вперед/назад, закрытие, открытие нового окна и т. д.; поведение консоли. включает console.log/error/warn и т. д.

4.2 Объяснение механизма сбора данных о поведении

Далее мы объясним случаи этих поведений отдельно.

Case1, поведение при нажатии (поведение пользователя)

использоватьaddEventListenerГлобально прослушивайте события кликов и собирайте поведение пользователей (клики, ввод) и имена элементов dom.
При возникновении ошибки будетОшибкаиповедениесообщать вместе.

Случай 2: поведение отправки запроса (поведение браузера)

Слушайте функцию обратного вызова onreadystatechange объекта XMLHttpRequest и собирайте данные при выполнении функции обратного вызова.

Независимо от того, используете ли вы axios или fetch, нижним уровнем на самом деле является XMLHttpRequest, поэтому не беспокойтесь о том, что поведение запроса, которое вы используете, не может быть зафиксировано!

Case3: переход на страницу (поведение браузера)

мониторwindow.onpopstate, этот метод будет запущен, когда страница перейдет для сбора информации.

Здесь по-прежнему используется режим АОП Вы обнаружите, что АОП, который мы мало используем в нашей повседневной работе, много раз используется в SDK! Если вам интересно, пожалуйста, идите и узнайте ~ 🙂

Case4: консольная печать (поведение консоли)

Здесь мы проходимпереписатьМетоды **info, warn, error** объекта консоли собирают информацию при выполнении консоли.

5. Отчетность по данным

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

Как показано на снимке экрана выше, мы сообщаем об ошибке, запрашивая изображение с именем n4.gif.

5.1 Зачем использовать 1 x 1 gif?

Причина в том, что:
1. Отсутствие междоменных проблем
2. После отправки GET-запроса нет необходимости получать и обрабатывать данные, а серверу не нужно отправлять данные
3. Файл cookie текущего доменного имени не будет сохранен!
4. Это не будет блокировать загрузку страницы и не повлияет на работу пользователя.new Imageобъект
5. По сравнению с BMP/PNG, который имеет наименьший объем, он может сэкономить 41% / 35% сетевых ресурсов.

6. Сводка SDK

Мы резюмируем SDK в одном предложении:

❝

Подслушивание / угонОригинальный метод, получение данных, которые необходимо сообщить, и использование функции **триггера** при возникновении ошибки.gifотчет.

Для облегчения памяти извлекаются 3 ключевых слова: угон, оригинальный метод, gif! (Если не помнишь, то не бей меня)

2. Очистка данных

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

Необработанные данные, сообщаемые SDK, имеют следующие характеристики:

• Объем данных большой и объем большой: несколько мегабайт, десять мегабайт и даже десятки мегабайт.
• Нет классификации и агрегации: однотипные ошибки только в разных временных измерениях, и нет необходимости хранить их все
• Отсутствие фильтрации нелегальных данных: слишком много бесполезной информации не способствует агрегации, а также увеличивает нагрузку на сервер

1. Сравнение носителей информации

Итак, как нам очистить данные, сообщаемые SDK? Прежде всего, нам нужно найти место для хранения этих данных, так как же нам их хранить? Далее давайте рассмотрим несколько распространенных на рынке решений для хранения данных:
Первый — это MySQL, MySQL должен быть знаком каждому, и он используется в повседневном бизнесе. MySQL поддерживает вторичные индексы и транзакции.Хотя это не очень хорошо для полнотекстового поиска, его сценарии использования на самом деле не очень полезны для полнотекстового поиска, поэтому он больше подходит для основного бизнеса в Интернете.
Второй — HBase, который существует уже 10 лет и также является относительно зрелым проектом. Hbase естественно распределяется, хотя он и не поддерживает полнотекстовый поиск, вторичное индексирование и транзакции, он поддерживает онлайн-расширение и очень подходит для приложений с непредсказуемым ростом и огромным объемом записи.
Третий — ES.ES — это распределенная система поиска и анализа с открытым исходным кодом, которая стала очень популярной в последние годы.Благодаря простому развертыванию вы можете выполнять анализ журналов, полнотекстовый поиск и анализ структурированных данных. ES также имеет статистические функции и поддерживает вторичные индексы.В то же время ES также естественным образом распределяется. По сравнению с другими высокоуровневыми продуктами баз данных происхождение ES относительно диаоси. Создатель ES, бывший безработный диаоси-программист, создал ES, чтобы облегчить жене поиск рецептов, когда ему нечем заняться. Elastic получила финансирование на сотни миллионов долларов, а программист из Diaosi уже тогда стал генеральным директором и достиг вершины своей жизни.

Хорошо, тогда сравнив эти схемы хранения, мы можем, наконец, использовать Mysql в качестве схемы постоянного хранения данных для предоставления данных для визуализации и ES в качестве временной схемы хранения данных, в этой ссылке мы можем использовать эту часть данных.

2. Процесс очистки

2.1 Процесс очистки

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

2.2 Получить данные

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

1. Получите почти минуту информации об ошибке от ES через запрос GET (ниже)

2. Для установки порога (механизма пикового сбрасывания), при возникновении большого количества ошибок, чтобы "не дать серверу вынести нагрузки, которые он не должен выносить", мы используем следующие два метода, чтобы сделать механизм пикового сбрасывания:

• Верхний предел сбора данных в минуту составляет 10 000, и если он превышается, они будут отобраны и помещены в хранилище.
• Если количество ошибок одного типа больше 200, учитывается только количество

2.3 Предварительная обработка данных

Как показано на правом рисунке на снимке экрана ppt выше, это неправильное поле содержимого, перехваченное из ES.Поскольку данные в ES имеют строковый формат, а код был переведен, нам нужно JSON.parse(). А иногда будут объекты, которые не полностью обернуты в строки, поэтому нам нужно извлечь в них нужные нам поля. Кроме того, нам также необходимо удалить бесполезную информацию из исходных данных, чтобы уменьшить объем хранилища.

Скриншот выше — это данные, которые мы наконец сохранили в mysql. Видно, что данные здесь относительно четкие, и нет лишнего контента, который нельзя было бы понять.

2.4 Агрегация данных

Давайте сначала подумаем, зачем нам нужна агрегация данных.Есть две цели: 1. Производительность хранилища: хранилище мало 2. Производительность запросов: быстрый запрос.

Так как же нам агрегировать определенный класс ошибок?

Мы делаем это по трем параметрам: 1. Название компании 2. Тип ошибки 3. Сообщение об ошибке

В качестве примера возьмем ошибку в бизнес-линии Beibei, beibei — это название компании, SyntaxError — синтаксическая ошибка, а SyntaxError: Строка не соответствует ожидаемому шаблону… — это сообщение об ошибке. Соединяем их вместе и md5, чтобы получилось что-то вроде этого: ecf9f6d430bea229473782dc63407673.

Что ж, ошибки, о которых сообщается далее, будут агрегированы таким же образом, чтобы увидеть, совпадают ли их последовательности.Если они одинаковы, то мы идентифицируем их как ошибки одного типа и сохраним их как одну и ту же запись в MySQL. :

Как показано на рисунке выше, message_id — это агрегированная строка, а event_count указывает количество ошибок одного типа. Наконец, мы отображаем эти данные в визуализации следующим образом:

2.5 Мониторинг процесса очистки

С онлайн-мониторингом ошибок SDK, тогда g't
Во-первых, проверьте, являются ли нормальными объем данных и потребление времени в единицу времени, стабильно ли количество потерянных данных на временной шкале и составляет ли количество данных, извлеченных в минуту, 10k (механизм пиковой цены обсуждался ранее).

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

3. Мониторинг

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

То есть, когда ошибка соответствует определенным условиям, об ошибке будут уведомлены разработчики, подписавшиеся на проект, через DingTalk, электронную почту, телефон, текстовое сообщение или веб-перехватчик. Условие можно понимать как: определенная ошибка, в течение 2 минут подряд, когда количество ошибок, сообщаемых в минуту, больше или равно 100, срабатывает сигнал тревоги. Затем обратитесь к разработчику с сообщением об ошибке!

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

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

Затем подумайте, как реализовать мониторинг ошибок на других концах? Давайте сначала рассмотрим, как реализован мониторинг ошибок на веб-стороне в соответствии с общей архитектурной схемой Skynet:

Давайте подумаем о картинке выше, какие процессы мы можем разделить между концом и концом? И какие процессы отличаются от конца к концу?

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

В-четвертых, реализация SDK на стороне узла

Другой контент мы объясним в следующей статье. Продолжение следует...

В этой статье используетсяmdniceнабор текста