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

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

Стадия сбора: собрать аномальные журналы, выполнить определенную обработку локально и сообщить на сервер, приняв определенный план.

Этап хранения: серверная часть получает журнал исключений, о котором сообщил внешний интерфейс, и после определенной обработки он сохраняется в соответствии с определенной схемой хранения.

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

Стадия тревоги: делится на тревогу и раннее предупреждение. Тревога срабатывает автоматически по определенному уровню и осуществляется по определенным правилам срабатывания по заданному каналу. Раннее предупреждение заключается в том, чтобы заранее прогнозировать и предупреждать до того, как возникнет аномалия.

1 исключение внешнего интерфейса

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

1.1 Классификация внешних исключений

По степени последствий аномального кода производительность интерфейсных исключений делится на следующие категории:

а. ошибка

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

б) вялый

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

в. Поврежден

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

г. Подвешенная смерть

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

е. авария

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

1.2 Классификация причин аномальных ошибок

Причины аномалии передка в основном делятся на 5 категорий:

причина	кейс	частота
логическая ошибка	1) Условие оценки бизнес-логики неверно 2) Неверная последовательность привязки событий 3) Ошибка синхронизации стека вызовов 4) Неправильная работа js объекта	часто
неправильный тип данных	1) Рассматривайте нуль как объект для чтения свойства 2) Рассматривать undefined как массив для обхода 3) Используйте числа в виде строк непосредственно для операций сложения 4) Параметры функции не передаются	часто
синтаксическая ошибка синтаксиса		меньше
Ошибка сети	1) медленный 2) Сервер не возвращает данные, но по-прежнему 200, а внешний интерфейс обрабатывает данные как обычно. 3) Прерывание сети при отправке данных 4) Внешний интерфейс не обрабатывает ошибки, когда на сервере возникает ошибка 500.	Иногда
системная ошибка	1) Недостаточно памяти 2) Диск заполнен 3) Шелл не поддерживает API 4) Несовместимость	меньше

2 Ненормальная коллекция

2.1 Содержание коллекции

Когда возникает исключение, нам нужно знать конкретную информацию об исключении и решить, какое решение принять в соответствии с конкретной информацией об исключении. При сборе аномальной информации можно следовать принципу 4W:

WHO did WHAT and get WHICH exception in WHICH environment?

а. Информация о пользователе

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

б. Поведенческая информация

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

в. Аномальная информация

Информация о коде, создающем исключение: узел элемента DOM, управляемый пользователем, уровень исключения, тип исключения, описание исключения, информация о стеке кода и т. д.

г. Экологическая информация

Сетевое окружение, модель устройства и идентификационный код, версия операционной системы, версия клиента, версия интерфейса API и т. д.

поле	Типы	объяснять
requestId	String	Интерфейс генерирует requestId
traceId	String	Этап генерирует traceId, который отслеживает все записи журнала, связанные с исключением.
hash	String	Уникальный идентификационный код этого журнала, который эквивалентен logId, но генерируется в соответствии с конкретным содержимым текущей записи журнала.
time	Number	Время, когда текущий журнал был сгенерирован (сэкономить время)
userId	String
userStatus	Number	В это время информация о статусе пользователя (доступна/отключена)
userRoles	Array	На тот момент список ролей бывшего пользователя
userGroups	Array	В то время текущая группа пользователя, права группы могут повлиять на результат
userLicenses	Array	В это время лицензия может истечь
path	String	путь, URL
action	String	что было сделано
referer	String	Предыдущий путь, исходный URL
prevAction	String	предыдущее действие
data	Object	Состояние и данные текущего интерфейса
dataSources	Array<Object>	Какие данные дает upstream api
dataSend	Object	какие данные были отправлены
targetElement	HTMLElement	Элементы DOM, которыми манипулирует пользователь
targetDOMPath	Array<HTMLElement>	путь узла этого элемента DOM
targetCSS	Object	пользовательская таблица стилей для элемента
targetAttrs	Object	Текущий атрибут и значение элемента
errorType	String	тип ошибки
errorLevel	String	уровень исключения
errorStack	String	Информация о стеке ошибок
errorFilename	String	файл ошибок
errorLineNo	Number	строка ошибки
errorColNo	Number	позиция столбца ошибок
errorMessage	String	Описание ошибки (определяется разработчиком)
errorTimeStamp	Number	отметка времени
eventType	String	тип события
pageX	Number	Координата по оси X события
pageY	Number	Координата события по оси Y
screenX	Number	Координата по оси X события
screenY	Number	Координата события по оси Y
pageW	Number	ширина страницы
pageH	Number	высота страницы
screenW	Number	ширина экрана
screenH	Number	высота экрана
eventKey	String	Ключ, вызвавший событие
network	String	Описание сетевой среды
userAgent	String	описание клиента
device	String	Описание устройства
system	String	Описание ОС
appVersion	String	Версия приложения
apiVersion	String	версия интерфейса

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

2.2 Перехват исключения

Исключения перехвата внешнего интерфейса делятся на глобальные перехваты и одноточечные перехваты. Глобальный код захвата централизован и прост в управлении, в качестве дополнения используется одноточечный захват для захвата некоторых особых случаев, но он разбросан и не способствует управлению.

а. Глобальный захват

Через глобальный интерфейс код захвата пишется в одном месте.Интерфейсы, которые можно использовать:

• window.addEventListener («ошибка») / window.addEventListener («необработанное отклонение») / document.addEventListener («щелчок») и т. д.
• Глобальный мониторинг на уровне фреймворка, такой как перехватчик в aixos, vue и react, имеют свои собственные интерфейсы сбора ошибок.
• Инкапсулируя глобальную функцию, исключение автоматически перехватывается при вызове функции.
• Например, переписывание метода (Patch), перенос слоя на основе исходной функции, такой как переписывание console.error, и захват исключений также может выполняться, когда метод использования остается неизменным.

б. Захват одной точки

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

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

2.3 Исключение междоменного сценария

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

Решение ошибки сценария:

Вариант первый:

• Встроить js в HTML
• Поместите файл js и HTML в один и тот же домен

Вариант 2:

1. Добавьте атрибут crossorigin в тег скрипта на странице.
2. Добавлено в заголовок ответа сервера, на котором находится скрипт, с добавлением Access-Control-Allow-Origin для поддержки совместного использования ресурсов между доменами.

2.4 Аномальная запись

Для исключения просто иметь информацию об исключении недостаточно, чтобы полностью понять суть проблемы, потому что местоположение исключения не обязательно является местоположением источника исключения. Нам нужно восстановить аномальную сцену, чтобы восстановить полную картину проблемы и даже предотвратить возникновение подобных проблем в других интерфейсах. Здесь необходимо ввести понятие «аномальная запись». Запись фиксирует весь процесс от момента до возникновения аномалии до ее возникновения в двух измерениях «времени» и «пространства», что более полезно для поиска основной причины аномалии.

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

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

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

2.5 Уровень исключения

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

Когда мы отслеживаем возникновение аномалий, аномалии можно разделить на четыре уровня A, B, C и D в модели «важно-срочно». Некоторые исключения, хотя и возникают, но не влияют на нормальное использование пользователя. Пользователь фактически этого не воспринимает. Хотя это должно быть исправлено в теории, на самом деле, по сравнению с другими исключениями, с этим можно разобраться позже.

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

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

3 Организуйте и сообщите план

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

3.1 Журналы внешнего хранилища

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

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

В настоящее время существует множество вариантов схем персистентности, в основном: Cookie, localStorage, sessionStorage, IndexedDB, webSQL, FileSystem и т. д. Итак, как выбрать? Для сравнения используем таблицу:

способ хранения	cookie	localStorage	sessionStorage	IndexedDB	webSQL	FileSystem
Типы		key-value	key-value	NoSQL	SQL
Формат данных	string	string	string	object
емкость	4k	5M	5M	500M	60M
обработать	Синхронизировать	Синхронизировать	Синхронизировать	асинхронный	асинхронный
забрать		key	key	key, index	field
представление		Читайте быстро и пишите медленно		Читайте медленно, пишите быстро

После синтеза IndexedDB является лучшим выбором.У него есть преимущества большой емкости и асинхронности.Асинхронные характеристики гарантируют, что он не будет блокировать отрисовку интерфейса. Кроме того, IndexedDB разделен на базы данных, каждая база данных разделена на хранилища и может быть запрошена в соответствии с индексом.Он имеет полное представление об управлении базой данных и больше подходит для управления структурированными данными, чем localStorage. Но у него есть недостаток в том, что API очень сложный, не такой простой и понятный, как localStorage. В ответ на это мы можем использовать инструмент hello-indexeddb, который использует Promise для инкапсуляции сложных API, упрощая операции и делая использование IndexedDB таким же удобным, как и localStorage. Кроме того, IndexedDB — широко поддерживаемый стандарт HTML5, совместимый с большинством браузеров, так что не беспокойтесь о перспективах его развития.

Далее, как мы должны разумно использовать IndexedDB, чтобы обеспечить рациональность нашего внешнего хранилища?

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

3.2 Журналы внешней сортировки

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

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

• Храните все записи журналов в области архива во временных рядах и добавляйте вновь введенные журналы в индекс.
• BatchIndexes: отчеты об индексах пакетами (включая другие журналы, такие как производительность), которые могут сообщаться пакетами по 100 за раз.
• MomentIndexes: мгновенный отчет об индексах, все одновременно
• FeedbackIndexes: Индексы отзывов пользователей, по одному за раз.
• BlockIndexes: индекс блочного отчета, разделенный на блоки по исключениям/ошибкам (traceId, requestId), по одному блоку за раз
• После завершения отчета индекс, соответствующий отчетному журналу, удаляется.
• Бревна старше 3 дней поступают в зону переработки
• Журналы старше 7 дней удаляются из области переработки.

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

traceId: трассировка связанных журналов до и после возникновения исключения. При запуске приложения создается traceId, пока не произойдет исключение, traceId обновляется. Сбор requestId, связанного с traceId, и объединение журналов, связанных с этими requestId, — это, наконец, все журналы, связанные с исключением, которые используются для просмотра исключения.

На приведенном выше рисунке показан пример использования traceId и requestId для поиска всех журналов, связанных с исключением. На приведенном выше рисунке hash4 — это журнал исключений.Мы видим, что traceId, соответствующий hash4, — это traceId2.В списке журналов есть две записи с этим traceId, но запись hash3 не является началом действия, потому что requestId, соответствующий hash3, равен reqId2, а reqId2 начинается с hash2, поэтому мы действительно хотим добавить hash2 ко всей записи восстановления исключения. Подводя итог, нам нужно найти записи журнала, соответствующие всем идентификаторам запроса, соответствующим одному и тому же идентификатору трассировки.Хотя это немного запутанно, вы можете понять причину с небольшим пониманием.

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

3.3 Журнал отчетов

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

По частоте отчетов (критической срочности) отчеты можно разделить на четыре типа:

а. Немедленная отчетность

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

б. Пакетный отчет

Собранные журналы хранятся локально, и когда собирается определенное количество, они упаковываются и сообщаются за один раз или упаковываются и загружаются с определенной периодичностью (интервалом времени). Это эквивалентно объединению нескольких отчетов в один для снижения нагрузки на сервер.

в. Заблокировать отчетность

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

г. Активно отправлено пользователями

Обеспечьте кнопку на интерфейсе, пользователи активно сообщают об ошибках. Это упрощает взаимодействие с пользователями.

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

	мгновенный отчет	Пакетный отчет	Блок сообщил	отзывы клиентов
старение	немедленно	выбор времени	небольшая задержка	задерживать
Количество баров	После того, как все отправленные	100 за раз	Единый отчет о связанных элементах	1 за раз
емкость	маленький	середина	-	–
Срочный	срочно важный	не срочно	Не срочно, но важно	не срочно

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

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

Информация об отзывах, представленная пользователями, может сообщаться медленно.

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

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

3.4 Сжатие данных и создание отчетов

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

Для случая комбинированной отчетности количество данных за один раз может быть больше десяти килограммов, для сайтов с большим дневным pv генерируемый трафик все равно значителен. Поэтому необходимо сжимать и сообщать данные. lz-string — очень хорошая библиотека классов сжатия строк, с хорошей совместимостью, меньшим количеством кода, высокой степенью сжатия, коротким временем сжатия и удивительной степенью сжатия 60%. Но он основан на сжатии LZ78.Если серверная часть не поддерживает распаковку, вы можете выбрать сжатие gzip.Вообще говоря, серверная часть по умолчанию предварительно установит gzip.Поэтому вы также можете выбрать gzip для сжатия данных.Инструментарий pako поставляется со сжатием gzip можно попробовать использовать.

4 Прием и хранение журнала

4.1 Уровень доступа и очередь сообщений

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

На приведенном выше рисунке показана архитектурная схема Tencent BetterJS, в которой «уровень доступа» и «центр push-уведомлений» являются упомянутыми здесь уровнем доступа и очередью сообщений. BetterJS разделяет каждый модуль всего фронтенд-мониторинга, а push-центр берет на себя роль проталкивания логов в центр хранения для хранения и в другие системы (например, в систему сигнализации).Сделайте переход между уровнем доступа и хранилищем слой.

4.2 Система хранения журналов

Хранение журналов — грязная работа, но ее нужно делать. Для небольших приложений с этим справится одна база данных и одна таблица плюс оптимизация. Если крупномасштабное приложение хочет предоставить более стандартную и эффективную службу мониторинга журналов, ему часто приходится работать над архитектурой хранения журналов. В настоящее время в отрасли существуют относительно полные решения для хранения бревен, в основном в том числе: система Hbase, система Dremel, система Lucene и т. д. В целом основными проблемами, с которыми сталкиваются системы хранения журналов, являются большие объемы данных, нерегулярные структуры данных, высокий уровень параллелизма записи и требования к большим запросам. Как правило, система хранения журналов должна решать вышеуказанные проблемы, решая проблему буферизации записи, выбирая носитель данных в соответствии со временем регистрации и разрабатывая разумную систему индексации для удобного и быстрого чтения.

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

4.3 Поиск

Конечной целью журнала является использование, потому что объем общего журнала очень велик, поэтому, чтобы найти нужные записи журнала в огромном массиве данных, вам нужно полагаться на более качественную поисковую систему. Splunk — зрелая система хранения журналов, но ее использование платное. Согласно структуре Splunk, Elk — это реализация Splunk с открытым исходным кодом, Elk — это комбинация ElasticSearch, Logstash и Kibana, ES — поисковая система, основанная на хранилище и индексировании Lucene; logstash — конвейер стандартизации журналов, который обеспечивает ввод, вывод и плагины для обработки конверсий; Kibana предоставляет визуализацию и пользовательский интерфейс для запроса статистики.

5 Статистика и анализ журналов

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

5.1 Пользовательская широта

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

5.2 Измерение времени

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

5.3 Параметр производительности

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

5.4 Размер рабочей среды

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

5.4 Детальная трассировка кода

Информация о стеке кода исключения, найдите расположение кода, в котором произошло исключение, и стек исключений.

5.6 Возврат сценария

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

6 Мониторинг и уведомление

Статистика и анализ аномалий — это только основа, и когда аномалия обнаружена, ее можно отправить и предупредить, и даже автоматическая обработка — это способность, которой должна обладать система мониторинга аномалий.

6.1 Тревоги с пользовательскими условиями срабатывания

а. Контроль за осуществлением

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

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

б. Пользовательские условия срабатывания

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

• Когда что в журнале
• Какой степени и объема достигает статистика логов?
• Оповещение пользователей, которые соответствуют каким условиям

6.2 Push-каналов

Есть много способов выбора, таких как электронная почта, текстовое сообщение, WeChat, телефон.

6.3 Частота толчка

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

6.4 Автоматический отчет

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

6.5 Автоматически генерировать сообщения об ошибках

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

7 Исправить исключение

7.1 sourcemap

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

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

Но здесь есть проблема, то есть исходная карта должна соответствовать версии официальной среды, а также она должна соответствовать ноде коммита в git, чтобы обеспечить корректное использование информации стека при проверке исключения и код версии, в которой обнаружена проблема. Этого можно достичь, установив задачи CI и добавив процесс развертывания в интегрированное развертывание.

7.2 От предупреждения к раннему предупреждению

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

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

7.3 Умный ремонт

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

8 Тестирование исключений

8.1 Активное тестирование исключений

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

8.2 Проверка случайных аномалий

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

Определите исключения, например, когда всплывающее окно содержит определенное содержимое, это исключение. Запись результатов этих тестов и кластерный статистический анализ также очень полезны для предотвращения аномалий.

9 Развертывание

9.1 Несколько клиентов

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

9.2 Простота интеграции

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

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

9.3 Расширяемость системы менеджмента

Вся система является масштабируемой, не только обслуживая одно приложение, но и поддерживая несколько приложений, работающих одновременно. Всеми приложениями одной команды можно управлять с помощью одной платформы.

9.4 Разрешения системы регистрации

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

10 других

10.1 Мониторинг производительности

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

• Производительность во время выполнения: уровень файла, уровень модуля, уровень функции, уровень алгоритма
• скорость сетевых запросов
• Производительность системы

10.2 API Monitor

Back-end API также оказывает большое влияние на front-end.Хотя front-end код также контролирует логику, данные, возвращаемые back-end, являются основой.Поэтому мониторинг API можно разделить на :

• Мониторинг стабильности
• Форматы и типы данных
• Мониторинг ошибок
• Мониторинг точности данных

10.3 Десенсибилизация данных

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

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

Эпилог

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