предисловие
Разработчики перед видео, всем добрый день!
Сегодня я поделюсь темой: «Как реализовать многотерминальную платформу мониторинга ошибок». Позвольте мне сначала кратко представиться.Я Аллан из Beibei-большой группы архитектуры внешнего интерфейса.В настоящее время я вношу свой вклад в поддержку системы контроля ошибок группы и инженерной стандартизации. В то же время я также являюсь автором «Практики фронтенд-разработки на React+Redux». Без лишних слов, сегодня я поделюсь с вами тем, как Beibei разработала и внедрила эту платформу мониторинга ошибок. Я надеюсь, что этот обмен может заставить всех «понять, использовать и забрать».
Мой сегодняшний репост продлится около часа, надеюсь все не будут торопиться и будут морально готовы.
содержание
Ценность технологий заключается в решении бизнес-задач. Поэтому в первых двух главах я объединю реальную ситуацию на стороне Beibei, чтобы объяснить, почему мы это делаем, и ценность, приносимую этой платформой мониторинга ошибок. В третьей главе объясняется техническая реализация, а в последней главе подводятся итоги.
Глава 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 проектов рассчитывается простая учетная запись, как показано на следующем рисунке:
Глава 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 предоставляет интерфейс для визуализации, и, наконец, отображаются данные об ошибках. Во всем этом процессе кажется много незнакомых слов, не бойтесь, не паникуйте, мы абстрагируемся от этой картинки.
Предыдущая схема общей архитектуры также состоит из следующих шести частей:сбор ошибокприбытьотчет об ошибкеприбытьОчистка данныхприбытьсохранение данных, и, наконец, к даннымвизуализацияа такжемонитор. Это все еще выглядит немного сложно, не так ли? Неважно, начнем с реализации минимального замкнутого цикла. Поскольку каждый является фронтенд-разработчиком, давайте начнем с реализации фронтенд-мониторинга ошибок! Давайте сначала смоделируем онлайн-ошибку:
1. SDK - сбор/отчет об ошибках
1. Как устроен SDK?
Нет сомнения, что источник данных визуализации собирается с помощью SDK в источнике ошибки, поэтому начнем с SDK.
2. Механизм перехвата ошибок
Далее проанализируем несколько часто используемых механизмов перехвата ошибок (выделены на рисунке ниже).
[1] Окно монитора.onerror
Когда возникает ошибка времени выполнения JavaScript (включая синтаксические ошибки и исключения, возникающие в обработчиках), событие ошибки с использованием интерфейса ErrorEvent будет запущено в окне и вызвано методом window.onerror() .
[2] Прослушивание события необработанного отклонения
Событие unhandledrejection запускается, когда обещание отклонено и не обработано. Следовательно, это событие можно отслеживать, а информацию об ошибке можно записывать и сообщать.
[3] Ошибка междоменного сценария: ошибка сценария.
Поскольку мы обычно храним статические ресурсы на сторонних доменных именах, таких как cdn, window.onerror в текущем имени бизнес-домена будет единообразно отображать такие ошибки, как Script error . Таким образом, для решения этой проблемы обычно есть два решения:
- Серверная часть настраивает Access-Control-Allow-origin, а внешняя часть настраивает crossorigin в теге скрипта.
- Взламывать нативные методы, использовать try/catch для обхода, выдавать ошибки
这里我们来讲讲第二种，由于浏览器不会对 _try-catch _起来的异常进行跨域拦截，所以我们采用劫持原生方法，将原生方法用 try/catch 的函数包裹来处理。 Пример кода выглядит следующим образом:
Это шаблон проектирования АОП (аспектно-ориентированное программирование).Когда возникает ошибка, мы повторно выбрасываем ошибку в catch и, наконец, выбрасываем собственный addEventListener для выполнения. Чтобы облегчить понимание, мы покажем этот процесс решения:
Как показано на рисунке выше, если бизнес находится на a.com, а статические ресурсы — на b.com, и в это время не выполняется обработка, отчет об ошибках js для доменного имени b будет отображаться как: Script ошибка. Но мы хотим получить полный стек ошибок, поэтому мы перехватываем нативное событие, пытаемся/перехватываем его, а затем выбрасываем ошибку генерации исключения.Когда исключение выдается снова, выполняется тот же код домена, поэтому мы можем получить полный сообщение об ошибке стека. Это позволяет фиксировать ошибки и создавать отчеты.
[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. Экологический сбор
3.1 Принципы сбора экологической информации
Чтобы получить информацию об окружающей среде, нам сначала нужно увидеть, попадает ли он в активные отчеты. Если да, то используйте информацию об окружающей среде, о которой активно сообщают; если нет, то посмотрите, попадает ли она в отчеты гибридного интерфейса (используя возможности клиента для захвата экологических данных). Если он попадает в информацию об окружающей среде, собранную клиентом, то используйте информацию об окружающей среде, собранную клиентом; если нет, мы проверим, попадает ли информация об окружающей среде, собранная UA (UserAgent). Это 3 способа сбора информации об окружающей среде.
Давайте посмотрим на предыдущую классификацию среды, бизнес-информация: через активные отчеты, отчеты о возможностях клиента и отчеты UA; информация об устройстве: с использованием отчетов о возможностях клиента и отчетов UA; информация о сети: с использованием отчетов о возможностях клиента и отчетов UA; информация о версии может можно получить непосредственно в SDK, запросив ('./package.json').version.
4. Зачем проводить сбор?
На самом деле, мы смогли определить местонахождение ошибки с помощью предыдущей информации об ошибке и информации об окружающей среде, так зачем нам собирать данные о поведении? Взгляните на скриншот ниже (с нашей платформы мониторинга ошибок):
4.1 Классификация коллекции поведения
Мы просто классифицируем поведение на: поведение пользователя, поведение браузера и поведение печати в консоли.
4.2 Объяснение механизма сбора данных о поведении
Далее мы объясним случаи этих поведений отдельно.
Case1, поведение при клике (поведение пользователя)
Используйте addEventListener для глобального прослушивания событий кликов и сбора действий пользователя (щелчок, ввод) и имен элементов dom. При возникновении ошибки сообщите об ошибке вместе с поведением.
Случай 2: поведение отправки запроса (поведение браузера)
Слушайте функцию обратного вызова onreadystatechange объекта XMLHttpRequest и собирайте данные при выполнении функции обратного вызова. Независимо от того, используете ли вы axios или fetch, нижним уровнем на самом деле является XMLHttpRequest, поэтому не беспокойтесь о том, что поведение запроса, которое вы используете, не может быть зафиксировано!
Case3: переход на страницу (поведение браузера)
Монитор Window.onpopState, когда страница прыжка запускает этот метод, информация собирается.
И режим АОП здесь, каждый обнаружит, что АОП, который мы не используем в повседневном бизнесе, используется в SDK несколько раз! Я пытаюсь узнать, пошли.
Case4: консольная печать (поведение консоли)
Здесь мы собираем информацию, когда консоль выполняется, переопределяя методы **info, warn и error** объекта консоли.
5. Отчетность по данным
На данный момент у нас есть информация об ошибке, окружении и поведении, а затем нам нужно сообщить о них.Здесь мы используем GET gif, чтобы сообщить об этом.
Как показано на снимке экрана выше, мы сообщаем об ошибке, запрашивая изображение с именем n4.gif.
5.1 Зачем использовать 1 x 1 gif?
Причина в следующем:
1. Отсутствие междоменных проблем
2. После отправки GET-запроса нет необходимости получать и обрабатывать данные, а серверу не нужно отправлять данные
3. Файл cookie текущего доменного имени не будет сохранен!
4. Это не будет блокировать загрузку страницы и не повлияет на работу пользователя, просто новый объект изображения.
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. Поэтому нашей фронтенд-разработке нужно только вызвать его, как мы обычно разрабатываем интерфейсы бизнес-вызовов.
Получите почти минуту информации об ошибке от ES через запрос GET (ниже)
Для установки порога (механизма пикового сбрасывания), при возникновении большого количества ошибок, чтобы "не дать серверу вынести нагрузки, которые он не должен выносить", мы используем следующие два метода, чтобы сделать механизм пикового сбрасывания:
Верхний предел сбора данных в минуту — 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 для мониторинга онлайн-ошибок сначала проверьте, в норме ли объем данных и потребление времени в единицу времени, стабильно ли количество потерянных данных на временной шкале и составляет ли количество данных, извлеченных в минуту, 10 000 (мы говорили о снижение пиковых цен ранее).механизм)
Во-первых, проверьте, являются ли нормальными объем данных и потребление времени в единицу времени, стабильно ли количество потерянных данных на временной шкале и составляет ли количество данных, извлеченных в минуту, 10 КБ (механизм пикового бритья упоминался ранее, и 10 КБ фрагменты данных находятся в сети каждую минуту).
3. Мониторинг
В последнем разделе, посвященном мониторингу веб-ошибок, давайте рассмотрим мониторинг. Когда за короткий промежуток времени возникает большое количество ошибок, нам нужно как можно скорее сообщить разработчикам информацию об ошибках, чтобы эти маленькие дети могли как можно скорее справиться с онлайн-ошибками. Это сводит к минимуму влияние онлайн-ошибок. Модель предупреждения об ошибке проще:
То есть, когда ошибка соответствует определенным условиям, об ошибке будут уведомлены разработчики, подписавшиеся на проект, через DingTalk, электронную почту, телефон, текстовое сообщение или веб-перехватчик. Условие можно понимать как: определенная ошибка, в течение 2 минут подряд, когда количество ошибок, сообщаемых в минуту, больше или равно 100, срабатывает сигнал тревоги. Затем обратитесь к разработчику с сообщением об ошибке!
Как показано на рисунке выше, мы делим тревоги на обычные тревоги и тревоги эскалации. В апгрейде будильника к обычному будильнику добавятся дополнительные текстовые сообщения и рабочие группы.Полагаю, что разработчики перед видео будут везде носить с собой мобильный телефон, даже если в туалет ходят, как вы думаете [ косая улыбка]? Эти оповещения будут иметь заголовки и содержание. Заголовок содержит источник ошибки, уровень ошибки, название компании; содержание ошибки будет включать описание ошибки и количество затронутых пользователей и т. д.
Хорошо, пока мы завершили мониторинг ошибок на веб-стороне, реализовав минимальный замкнутый цикл многотерминального мониторинга ошибок! Затем подумайте, как реализовать мониторинг ошибок на других концах? Давайте сначала рассмотрим, как реализован мониторинг ошибок на веб-стороне в соответствии с общей архитектурной схемой Skynet:
Давайте подумаем о картинке выше, какие процессы мы можем разделить между концом и концом? И какие процессы отличаются от конца к концу?
Да, вы угадали. За исключением сбора ошибок и отчетов, которые различаются от начала до конца, другие процессы могут быть общими! Мы принимаем это как точку входа, а затем анализируем, как собираются и сообщаются ошибки на других терминалах или платформах.
Обратите внимание, что основная идея здесь такова: дифференцированный сбор, форматированная отчетность!
Это будет использоваться позже в объяснении, пожалуйста, запомните приведенное выше предложение!
4. Node статьи о реализации SDK
1. Инициализация
Когда приложение Node запускается, оно обращается к ZooKeeper, чтобы получить соответствующий бизнес-идентификатор для инициализации Skynet.
Q: Зачем получать id от ZK?
О: Скайнет инициализируется в базовом пакете узла, а не из бизнеса, поэтому бизнес-идентификатор динамически получается через zk для позиционирования бизнеса.
2. Механизм перехвата ошибок
Использование на стороне узлаprocessпрослушиватель объектовuncaughtException,unhandledRejectionсобытие, поймать необработанноеJSисключение иPromiseаномальный.
3. Сбор неверной информации
После отлова объекта ошибки используется сторонняя библиотекаstack-traceДля анализа библиотека преобразует стек ошибок в массив и получает исходный код файлов внутри приложения в цепочке вызовов стека.
5. Статьи Weex, реализованные sdk
1, многосторонняя совместимость
1) Пакет проекта Weex состоит из двух наборовWebpackконфигурация, но единая ссылка в бизнесе@weex/skynet
2) Использовать при упаковке для Интернетаreplace-loaderэтоloaderзаменить пакет на@fe-base/skynet
Для Векс:@weex/skynet; для Интернета:@fe-base/skynet.
Основная идея: добиться совместимости с несколькими терминалами с помощью инженерных возможностей веб-пакета.
2. Механизм перехвата ошибок
1) Имя модуля, который интерфейс предоставляет услуги клиенту
2) Передать имя модуля клиенту через гибридный интерфейс
3) Клиент сообщает, когда ошибка weex обнаружена
Основная идея: источник внешнего тега,Возможности клиентасообщить об ошибке
6. Небольшая программа внедрения sdk
1. Механизм перехвата ошибок
В апплете WeChat есть глобальная функция onError, которая здесь используется для перехвата ошибок.
2. Сбор экологической информации
В: Апплет WeChat не предоставляет общего API для получения информации об окружающей среде?
A: На этапе жизненного цикла запуска апплета информация об окружении может быть смонтирована в globalData, а SDK получает глобально уникальный экземпляр приложения с помощью метода getApp, чтобы получить объект globalData.
7. Отчеты об ошибках клиента (без sdk)
1. Механизм сообщения об ошибках Android
Используйте предоставляемые системой механизмы для достиженияThread.UncaughtExceptionHandlerинтерфейс, черезuncaughtExceptionМетод получает информацию об ошибке сбоя и заменяет обратный вызов сбоя по умолчанию при инициализации приложения.
Чтобы облегчить понимание фронтенд-разработки:
uncaughtException: аналогично интерфейсуwindow.onerror; Thread.UncaughtExceptionHandler: Перезвоните.
2. Механизм сообщения об ошибках iOS
С помощью механизма перехвата ошибок, предоставляемого системой, регистрируются перехватчики обработки исключений Objective-C и сигналов POSIX.При возникновении сбоя информация о сбое может быть записана с помощью функции перехватчика.
На данный момент система мониторинга ошибок Skynet охватывает: Web, Node, Weex, апплет, клиент!
Основная идея: дифференцированный захват, форматированная (унифицированная) отчетность.
Суммировать
Мы начали с веб-мониторинга ошибоквизуализацияОтображение и получение источников данных. затем пройтиСоздайте SDKсообщить данные. Далее используйте два скрипта для обработки отчетных данных: скрипты очистки (вытягивание данных из ЭП для очистки) и тревожные задачи. наконецСохранение данных MysqlХранилище через Node.js длявизуализацияПредоставление интерфейсных услуг.
Наконец, SDK постоянно расширяется для реализации кросс-платформенного/кросс-конечного мониторинга.
над.