Обзор системы внешнего мониторинга за 2017 г.

задний план

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

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

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

Зачем мониторить производительность? Потому что для любой интернет-компании производительность часто напрямую связана с прибылью. Опрос данных показывает, что когда Google задерживает400 мс,Количество запросов падает0.59%, Задержка Bing2s, выручка упала4,3%,задержка Yahoo400ms, поток падает5-9%,Поэтому, когда многие компании проводят анализ пользовательского опыта, первое, на что они смотрят, — это показатели мониторинга производительности.Во фронтенде производительность — это не что иное, как следующие эталонные показатели:

• время белого экрана;
• первое экранное время;
• время взаимодействия с пользователем;
• общее время загрузки;
• время TCP-соединения;
• время HTTP-запроса;
• время ответа HTTP;

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

мониторинг исключений

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

• Пользователь A: страница становится белой после нажатия кнопки XX
  
• Пользователь Б: После расходования купона сумма платежа отображается некорректно
• Пользователь C: На недавней странице есть специальная карточка, требуется много времени, чтобы нажать на вкладку, чтобы ответить.

Сталкиваясь с отзывами пользователей, разработчики часто путаются: сколько карт и на каком шаге карта? Это индивидуальное явление или затронута большая территория? Каков код возврата запроса страницы, когда экран пуст? Его угнал перевозчик или что-то пошло не так с CDN? Могут ли пользователи использовать Чарльза для совместной работы над захватом пакета? Как сделать целевую оптимизацию? Как измерить результаты оптимизации?

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

Мониторинг данных

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

1. Страница PV, UV может напрямую влиять на коэффициент конверсии
2. Привычки использования майнинга из порядка, в котором пользователи посещают страницы (и т. д.)

Эта часть данных мониторинга в основном используется PM / PD, а бизнес-данные могут стимулировать рост самого бизнеса Кто-то однажды сказал: «Есть только два способа уменьшить вероятность предпринимательской неудачи: один — предсказать, а другой — другой — провести бережливый анализ данных.» , который показывает важность анализа данных.

Традиционные решения и подводные камни

Уже есть несколько front-end решений для мониторинга: Sentry, Badjs, jsTracker, GrowingIo и т.д. Также внутри компании есть системы мониторинга собственной разработки. Все они пытаются решать задачи фронтенд-мониторинга с разных сторон.Идеи реализации у всех очень похожи.Для достижения мониторинга в первую очередь необходимо собрать индикаторы:

Представление

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

Вот в качестве примера первое экранное время: в хромированных браузерах высокой версии время загрузки можно получить напрямую через интерфейс firstPaintTime, но большинство браузеров его не поддерживают, и для мониторинга необходимо найти другие методы. Имейте в виду, что при выполнении измерений, связанных со временем, никогда не используйте методы setTimeout и setInterval, потому что в однопоточном механизме выполнения выполнение асинхронной очередиВремя выполнения не гарантируетсяиз. Вот возможная схема измерения с точностью более 99%.

<doctype html>
<html>
    <head>
        <script type="text/javascript">
            var timerStart = Date.now();
        </script>
        <!-- 加载其他资源，执行代码blabla -->
    </head>
    <body>
        <!-- 路由框架挂载节点 -->

        <script type="text/javascript">
             $(document).ready(function() {
                 console.log("DOMready 时间 ", Date.now()-timerStart);
             });
             $(window).load(function() {
                 console.log("所有资源加载完成 时间: ", Date.now()-timerStart);
             });
        </script>
    </body>
</html>

Еще одно элегантное решение — напрямую использовать интерфейс window.performance:

connectEnd                 Time when server connection is finished.
connectStart               Time just before server connection begins.
domComplete                Time just before document readiness completes.
domContentLoadedEventEnd   Time after DOMContentLoaded event completes.
domContentLoadedEventStart Time just before DOMContentLoaded starts.
domInteractive             Time just before readiness set to interactive.
domLoading                 Time just before readiness set to loading.
domainLookupEnd            Time after domain name lookup.
domainLookupStart          Time just before domain name lookup.
fetchStart                 Time when the resource starts being fetched.
loadEventEnd               Time when the load event is complete.
loadEventStart             Time just before the load event is fired.
navigationStart            Time after the previous document begins unload.
redirectCount              Number of redirects since the last non-redirect.
redirectEnd                Time after last redirect response ends.
redirectStart              Time of fetch that initiated a redirect.
requestStart               Time just before a server request.
responseEnd                Time after the end of a response or connection.
responseStart              Time just before the start of a response.
timing                     Reference to a performance timing object.
navigation                 Reference to performance navigation object.
performance                Reference to performance object for a window.
type                       Type of the last non-redirect navigation event.
unloadEventEnd             Time after the previous document is unloaded.
unloadEventStart           Time just before the unload event is fired.

Совместимость интерфейса:

Индикатор аномалии

Схемы исключений активного захвата в основном включают onError и addEventListener.OnError поддерживается начиная с IE6, поэтому большинство систем используют onError для активного захвата. Обратите внимание здесьПолитика гомологии браузеров (CORS),В продвинутых браузерах, если браузер фиксирует сообщение об ошибке, если доменное имя, в котором находится JS-файл (например, meituan.com), и текущий адрес страницы (например, dianping.com) являются междоменными, тогда движок автоматически поместите параметр onError. Параметр заменяется ошибкой скрипта, и количество строк и столбцов, а также сведения об ошибке не могут быть получены в настоящее время. Решение состоит в том, чтобы добавить поле перекрестного происхождения при введении тега.

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

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

Индикаторы данных

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

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

новое решение

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

1. полная коллекция: Надежные индикаторы мониторинга, сквозной сбор полных индикаторов производительности, ключевых методов выполнения, бизнес-показателей и охват более 2,9 девяток.
2. Не нужно хоронить: Полная отчетность, разработчикам не нужно вручную закапывать точки, а также принципиально исключать неправильное захоронение и отсутствующее захоронение.
3. Легко сделать запрос: он может запрашивать данные в соответствии с несколькими измерениями, такими как регион, модель, операционная система, версия браузера и состояние сети. Лучше всего поддерживать полнотекстовый поиск и агрегацию классификации.
4. Восстановление сцены: В соответствии с информацией управления, восстановить пользователя, чтобы начать серию операций с момента входа в систему, и создать диаграмму последовательности, основанную на поведении пользователя.
5. Сильный в реальном времени: запрос второго уровня, вы можете увидеть эффект оптимизации сразу после выхода в интернет и провести следующую оптимизацию.
6. Умное оповещение: используется комбинация статического порога и динамического порога с учетом высоких и низких пиков для уменьшения ложных положительных и ложных отрицательных результатов. И установите индикаторы тревоги для бизнес-данных, чтобы найти глубокие проблемы в системе.

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

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

В начальном процессе исследования мы использовали метод загрузки пакета плагина webpack + npm, но из-за двух частей логики отчетов в случае крайне плохой сети возникнет проблема конфликта кеша записи, что приведет к повторным отчетам или отчеты об ошибках.С учетом введения единого тега script и некоторых зарезервированных активных интерфейсов отчетов разработчики могут повторно инкапсулировать их в бизнес-код в соответствии со своими потребностями:

...
moduleClick(options) {
        const { name, ...otherOptions } = options;
        M.moduleClick(name, otherOptions);
    },
    /**
     * 曝光事件
     * @param options
     */
    moduleView(options) {
        const { name, ...otherOptions } = options;
        M.moduleView(name, otherOptions);
    },
    /**
     * 编辑事件
     * @param options
     */
    moduleEdit(options) {
        const { name, ...otherOptions } = options;
        M.moduleEdit(name, otherOptions);
    },
...

После доступа какие изменения в новой версии системы по сравнению с предыдущей версией?

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

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

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

При хранении журналов объем данных представляет собой проблему. Мы используем кластерную архитектуру. Однако для сайта с большим количеством пользователей количество зарегистрированных журналов очень велико. APP может пробить .3000 qps, что является большой проблемой для параллелизма и стабильности системы логов. Мы выбрали метод полных узлов master+data и установили сегмент реплики данных равным 1. Если какой-либо узел умирает, реплика выбирает новый первичный сегмент, что не приведет к потере журнала. Что касается записи, мы выбрали массовый метод для пакетной записи.Путем проб и ошибок размер потока пакетной записи составляет от 5 МБ до 15 МБ. Так как лог-система предназначена в основном для записи, то запрос _all закрыт, а производительность записи оптимизирована в 1 раз, при этом распределение нового и старого gc составляет 1:4, что обеспечивает стабильность пакетной записи.

Резюме и планы на будущее

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

В дальнейшем мы сосредоточимся на следующих вопросах:

3. Оптимизируйте опыт анализа данных

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