Максимальный внешний мониторинг

Эта статья является сводной по теме 12-й D2 Front-end Conference "Сделаем Front-end мониторинг на вершину", вы также можете просмотреть ее напрямуюживое видеоилиPPT.

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

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

Небольшое благосостояние

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

Идея реализации описана во вступительном вопросе.Все неперехваченные исключения собираются через window.onerror, а через новое изображение создается HTTP-запрос 404. Наконец, совпадающие запросы в access.log фильтруются и подсчитываются в режиме реального времени на серверная часть. .

Фактический эффект операции выглядит следующим образом:

Побочные эффекты браузера

эффект сервера

коллекция

Script Error

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

Обработка ошибки сценария в исходном коде Webkit

Проще говоря, если ваша страница и файлы JavaScript, на которые ссылается страница, имеют разное происхождение (несовместимый протокол, доменное имя, порт), то все ошибки, выдаваемые этими сценариями, являются междоменными ошибками. Итак, когда мы выполняем внешний мониторинг, чтобы зафиксировать эти ошибки, как нам избежать сбора Script Error?

Crossorigin требует поддержки как на стороне сервера, так и на стороне браузера, чтобы перекрестное происхождение вступило в силу. Поддержка на стороне сервера относительно проста, то есть сервер, возвращающий междоменный скрипт (обычно сервер CDN), корректно выводит заголовок ответа CORS — Access-Control-Allow-Origin:* — то есть текущий общий Все сервисы CDN поддерживают эту функцию. Ситуация с поддержкой на стороне браузера не столь оптимистична.

Интерфейсная поддержка атрибута перекрестного происхождения

Преодолейте ограничения на отчеты об ошибках между доменами

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

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

const prevSetTimeout = window.setTimeout;

window.setTimeout = function(callback, timeout) {
  const self = this;
  return prevSetTimeout(function() {
    try {
      callback.call(this);
    } catch (e) {
      // 捕获到详细的错误，在这里处理日志上报等了逻辑
      // ...
      throw e;
    }
  }, timeout);
} 

Точно так же мы можем исправлять и другие нативные методы, такие как Array.prototype.forEach, setInterval, requestAnimationFrame и т. д.

Это правда, что этот метод может помочь нам поймать как можно больше исключений, но из-за исправленного нативного метода JavaScript всегда возникает ощущение, что будет много неопределенности.

Здесь я также хотел бы упомянуть основанное на Babel автоматическое добавление try...catch...метод, Заинтересованные студенты могут пойти посмотреть глубже, будет много вдохновения.

Решение на уровне фреймворка

Во многих современных интерфейсных фреймворках предусмотрены решения для обработки исключений на уровне фреймворка, такие как ErrorHandler AngularJS и Vue.config.errorHandler Vue. Здесь мы берем компонентDidCatch React 16 в качестве примера, чтобы проиллюстрировать, как использовать возможности фреймворка для захвата ошибок.

Вот пример с официального сайта React:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  componentDidCatch(error, info) {
    this.setState({ hasError: true });

    // 在这里可以做异常的上报
    logErrorToMyService(error, info);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Something went wrong.</h1>;
    }
    return this.props.children;
  }
}

<ErrorBoundary>
  <MyWidget />
</ErrorBoundary>

обработка данных

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

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

В процессе обработки данных стоит упомянуть о функциональном оформлении частоты дискретизации данных.

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

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

1. Низкий журнал Написать расходы
2. Механизм поворота гарантирует, что хранение не будет потрачено впустую
3. Понять реальный объем данных запроса RBI
4. Избегайте обхода ограничения частоты дискретизации на стороне сбора данных

анализировать

После решения проблемы сбора и обработки данных, как нам приступить к анализу? Сначала рассмотрим реальный случай:

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

Является ли большое количество ошибок обязательно нестабильным?

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

Как показано на рисунке выше, хотя приложение взорвало десятки тысяч исключений JavaScript за один день, в ходе анализа мы обнаружили, что 95% ошибок были сосредоточены на 3 userId. Углубленное исследование этих трех userId найти несложно. Это три учетные записи сканера для сканирования данных. К сожалению, скрипт для сканирования данных имеет ошибки, которые точно фиксируются внешней системой мониторинга.

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

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

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

Вызовите полицию

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

Эпилог

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

Если вам интересно, чем мы занимаемся, добро пожаловать в Alibaba и создавайте свои собственные информационные продукты вместе с нами Пожалуйста, отправьте свое резюмеshuangyang.ys@alibaba-inc.com