Posted:
Июн 1, 2023
Comments:
0 Comments

Javascript событие метрика: Цель «JavaScript-событие» — Метрика. Справка

Содержание

Настройка целей в Яндекс.Метрике: как настроить цель


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


Цель — это событие, которое посетитель сайта совершает на пути к полноценной конверсии. Могут выступать самые разнообразные события: от заполнения контактной формы до звонка в компанию. Другими словами — любое событие, которое должно привести к продаже. В «Яндекс.Метрике» настройка целей выполняется для конкретного счётчика.

Какие бывают цели в «Яндекс.Метрике»


Они работают исходя из выбранного условия. В «Яндекс.Метрике» доступны 11 типов условий:


Цель может быть конверсионной или ретаргетинговой.


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


Учитывайте, что использовать конверсионные цели для настройки аудиторий «Яндекс.Директ» — невозможно.

Как правильно выбрать цель в «Яндекс.Метрике»


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


Таким образом, уже первоначально вы должны выбрать — что именно нужно отслеживать. Что для вас наиболее ценно, именно с точки зрения аналитики данных — последний шаг воронки продаж (конверсия) или промежуточные шаги? Уже после ответа на этот вопрос, вы сможете спокойно выбрать конкретную цель из тех, которые предлагает «Яндекс.Метрика».


Ретаргетинговые цели предназначены для дальнейшей настройки показов в «Яндекс. Директ», а конверсионные — для аналитики показателей самого сайта.


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

Как настроить цель в «Яндекс.Метрике»


Открываем «Яндекс.Метрику» и выбираем раздел «Цели», который находится в меню слева:


Добавляем новую цель:


Второй способ — кнопка «Создать цель». Она находится напротив счетчика справа (дашборд «Мои счетчики»):


Чтобы создать цель, кликаем по этой кнопке и переходим к настройкам цели.

Настройка цели «Количество просмотров»


Эта цель пригодится, если вы хотите отследить суммарное количество страниц, которое открыл посетитель в течение одной сессии. Главным образом, этот тип целей используется для изучения общей вовлеченности аудитории. Настраивается цель элементарно — сразу после клика по кнопке «Создать цель», выбираем корректный тип условия:


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


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

Настройка цели «Посещение страниц»


Данная цель используется для отслеживания посещения выбранных веб-страниц. При помощи неё можно отслеживать не только единичные URL, но целые разделы сайта. Цель позволяет отслеживать и виртуальные URL (#param), а также — следить за страницами, которые связаны друг с другом какими-либо общими признаками.


Этот тип цели настраивается условием и его значением:


Условие, как видим, относится непосредственно к самой ссылке. Разберем разные типы условий цели посещение страниц подробнее.

Типы условий в «Яндекс.Метрике»



  1. Url содержит:


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




    Например: нужно отслеживать посещение всех страниц фильтров, которые есть на сайте. Значит, в поле значение, указываем: filter.




  2. URL совпадает


    Идеальный вариант, когда требуется отслеживать только одну страницу. Указывается один URL, соответственно.




  3. URL начинается с


    Этот тип условия пригодится, если вы хотите отслеживать только подкаталоги. Указывается, соответственно, только начальная часть ссылки, например — «/shop/iphones/».




  4. URL регулярное выражение


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


    Например: /shop/[0-99] – будет интерпретироваться как фильтрация страниц содержащих один из перечисленных символов в диапазоне 0-99, т.е. 0,1,2 … 99. Подробно ознакомиться с использованием регулярных выражений можно https://yandex.ru/support/metrica/general/regexp.html.

Настройка цели «JavaScript-событие»


Условие используется, если необходимо отследить нажатие кнопки (отправка формы, отправка товара в корзину, отслеживание кнопок соцсетей). Javascript-событие позволит отследить не только кнопки, но и вообще любое взаимодействие с элементами страницы — просмотр видео / фото, скачивание файла. С помощью этого условия можно и зафиксировать время просмотра страницы, например.


Чтобы настроить этот вид цели, необходимо знать основы JavaScript и HTML, так как понадобится добавить коды целей на сайт. При помощи него данные о совершении события на сайте сразу передаются в «Яндекс.Метрику»


Если вы не можете добавить код на сайт самостоятельно — обратитесь к разработчику. Кроме этого, цель JS-событие, в 90% случаев, можно заменить целью «Отправка формы».


Чтобы добавить цель JavaScript-событие, откройте «Метрику» и выберите пункт «Создать цель»:


Назовите цель и выберите её тип:


Указываем любой ID цели (только латиницей):


В качестве идентификаторов допустимо использовать только уникальные значения (они не должны повторяться в других URL вашего сайта). Кроме этого, запрещены символы: / \ & # ? = «\


После ввода идентификатора, строкой ниже, появится уникальный код цели:


Копируем код и завершаем создание цели:


Теперь добавленная цель должна выводиться в этом списке:


Прежде чем добавлять код на сайт, обязательно изучите справку «Яндекса» о reachGoal. Это метод, который используется «Метрикой» для отправки данных о достижении настроенной цели.


Код цели добавляем на ту страницу, которую нужно отслеживать (напоминаю, используем только reachGoal). Например — для отслеживания кнопки, код может выглядеть следующим образом:


Для отслеживания заполнения контактных форм:


Как видим, здесь у нас три параметра: ym(XXXXXX, ‘reachGoal’, ‘TARGET_NAME’. Рассмотрим их подробнее:



  1. Вместо ym(XXXXXX будет код вашего счётчика.



  2. Метод ‘reachGoal’ — остаётся неизменным.



  3. ‘TARGET_NAME’ — это имя вашей цели в интерфейсе «Метрики».

Настройка цели «Клик по email»


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


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


Добавляем новую цель:


Даём цели имя и выбираем клик по email:


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


Не забываем указать email и сохранить настройки цели. и добавляем цель:

Настройка цели «Клик по номеру телефона»


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


Как обычно добавляем новую цель и даём ей имя:


Если нужно отслеживать единственный номер, то выбираем этот пункт:


Номер вписываем так, как он прописан в теле URL (с учётом кодов / префиксов).


Сохраняем настройки новой цели:

Настройка цели «Клик по кнопке»


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


По аналогии с предыдущими целями, добавляем новую:


Даём ей имя и выбираем тип:


Выбираем кнопку. Вы можете самостоятельно скопировать URL «кнопки» на сайте:


Но такой способ работает не всегда. В этом случае — воспользуйтесь инструментом «Выбор элемента»:


Откроется окно «Выбора элемента»:


Наводим курсор на интересующую кнопку (или иной элемент страницы) и кликаем по нему, он выделится зеленым цветом:


Выбираем пункт «Отслеживать клики»:


Сохраняем настройки новой цели

Настройка цели «Отправка формы»


Цель, позволяющая отслеживать клик по кнопке «Отправить», а также — фиксировать само событие отправки. Цель позволяет следить как за одной формой, так и сразу за всеми, которые есть на сайте.


Эту цель можно настроить, чтобы она фиксировала как успешные (придётся добавить disabled-атрибут в код кнопки), так и неуспешные попытки отправки формы.


Добавляем новую цель и даём ей имя:


Кликаем по необходимому типу условия:


Допустим, мы хотим следить за одной формой. Выбираем этот пункт:


Теперь прописываем доменное имя сайта с интересующей вас формой. Кликаем по этой кнопке:


Все кликабельные элементы будут подсвечены. Выберите интересующую вас форму:


…и добавьте её в настройки цели:


Завершите настройку цели:


Внимание: цель «Отправка формы» будет работать корректно только в том случае, если ваша форма сформирована тегом form (у такого элемента должен быть уникальный идентификатор и название, соответственно). А вот div-форму и другие встраиваемые отследить не удастся.

Настройка цели «Переход в мессенджер»


Мессенджеры всё чаще используются на сайтах для обратной связи.


«Метрика» позволяет отслеживать переход в 7 разных мессенджеров. Поддерживаются: Telegram, «Яндекс.Мессенджер», VK, FaceBook, WhatsApp, Skype, Viber.


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


Добавляем новую цель:


Называем её:


Выбираем корректный тип условия:


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


Или отслеживать переходы в любой мессенджер:


После этого, остаётся завершить настройку новой цели:

Настройка цели «Cкачивание файла»


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


Эти расширения актуальны в том случае, если вы настраиваете отслеживание для любого файла. Условие «Скачивание файла» можно настроить и для отслеживания конкретного файла. Для конкретного файла можно прописывать даже неподдерживаемые типы расширений.


Создаем новую цель:


Называем её:


Выбираем корректный тип условия:


Теперь нужно выбрать, что отслеживать — любой или конкретный файл. Допустим, нужно отследить только определенный файл на сайте. Выбираем этот пункт и прописываем название файла:


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


Завершаем настройку цели:

Настройка цели «Поиск по сайту»


На вашем сайте есть поиск? Его использование можно отслеживать.


Чтобы «Метрика» корректно идентифицировала использование поиска, в URL должен быть соответствующий GET-параметр (например: search / q / query / text)


Даже если вы не используете указанные параметры, всегда можно добавить свой при настройке новой цели. Данные по использованию поиска на сайте, можно получить из отчётов метрики (например — по конверсиям).


Создаем новую цель:


Называем цель и выбираем её тип:


На этом этапе вы должны знать — какой именно параметр URL отвечает за поиск на вашем сайте. Узнать это просто: просто воспользуйтесь поиском и скопируйте полученную ссылку (страница результатов поиска). Например: /search/?q=telegram


В ссылке выше, мы видим, что для поиска задействуется GET-параметр q (он поддерживается «Метрикой» по умолчанию), значит можно просто завершить настройку цели:


Отслеживание использования поиска по сайту настроено. Если на вашем сайте для поиска применяется иной GET-параметр, то открываем этот пункт:


…и просто вписываем используемый на вашем сайте параметр в строке.


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


Чуть ниже, выбираем параметр, который используется для поиска на вашем сайте (в моём случае s):


. ..и получаем данные по конкретным поисковым фразам, которые пользователи вводили на вашем сайте:

Настройка составных целей


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


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


Выполнение составной цели будет засчитано только в том случае, если выполнены все заданные в ней шаги. Составная цель может включать до пяти отдельных шагов. В качестве подцелей можно использовать только «JS-событие» или событие «Посещение страниц». Все остальные типы событий — недоступны.


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


Создаем новую цель:


Даём ей любое удобное имя:


Выбираем тип условия:


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


Указываем ID цели — если выбираем тип условия «JS-событие»: (о том, как работать с условием цели JavaScript-событие, вы можете узнать в разделе «JS-событие», чуть выше):


…или добавляем URL-условие (см. раздел «Типы условий в «Яндекс.Метрике» выше):


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


Если всё верно — сохраняем составную цель, кликнув по жёлтой кнопке:

Как проверить цели в Яндекс Метрике?

Чтобы проверить работоспособность созданной цели, нужно использовать параметр _ym_debug=1. Его нужно добавить в самый конец ссылки.

Открываем страницу сайта с настроенной целью (например: страницу контактов) и в конец URL добавляем параметр _ym_debug=1.
Например: /contacts/?_ym_debug=1

Теперь запускаем режим разработчика в используемом браузере. В Google Chrome он вызывается сочетанием горячих клавиш Ctrl + Shift + I. Нас интересует раздел консоли:

Имитируем выполнение цели на открытой странице (совершаем клик по кнопке, например). После, находим строку Reach goal (если целевое действие является JS-событием) или строку PageView (если целевым действием является посещение URL).

Вот пример для события PageView:

Если Reach goal / PageView отображается на странице, значит цель настроена правильно.

Вывод:


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


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

Регулярные выражения + JS событие. Очередное обновление от Яндекс.Метрики — CMS Magazine

Яндекс.Метрика выкатила очередное обновление. Наконец-то возликуют те, кто не любит плодить по 100500 целей в интерфейсе! Теперь появилась возможность объединить js-события в одну цель, избегая настройки через составную цель. Ведь раньше приходилось задавать каждую цель через условие «или». Конечно, можно предварительно объединить все события в одном теге через GTM… Но что, если события для Метрики прописаны напрямую в коде сайта или частично настроены и в коде, и в GTM? В этом случае регулярные выражения упростят жизнь.

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

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

Пример сегментации:

Что соответствует любому вхождению символов, как в начале, так и в конце

Пример использования при настройке цели «Посещение страниц»:

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

Разберем пример на основе js-события

Давайте представим такую ситуацию: у вас есть три тега в GTM, в которых предварительно настроена передача событий в Метрику. Каждый тег содержит разные идентификаторы js-события. Например, Form_callback, Form_question, Form_calculator.

А также бывший подрядчик настроил для клиента передачу данных в Метрику напрямую через код сайта. В ID события он прописал произвольные названия: FormOrder, 1click_order. Но вы не хотите перенастраивать эти события через GTM.

Оптимальным вариантом объединить такие события раньше была составная цель:

Приходилось прописывать каждый шаг через условие «или»:

Как это выглядит сейчас:

Где в качестве условия мы выбираем «или», что соответствует вертикальной черте «|». Form — это соответствует FormOrder, FormCallback, FormFeedback, но не соответствует QuestionForm.

  • Знак доллара ($)

    Значит, что-то заканчивается на …

    Например: Click$ — это соответствует Click, Mail_Click, Phone_Click, но не соответствует Clicks, ClickPhone, ClickProduct.

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

    Подробнее можно узнать тут: Регулярные выражения

    Больше не нужно искать и обзванивать каждое диджитал-агентство

    Создайте конкурс на workspace.ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
    Создать конкурс →

    Подводя итоги

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

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

    Полезные материалы

    • Регулярные выражения в Google Analytics

    • Как использовать регулярные выражения в Google Analytics и Google Tag Manager

    • Google Analytics RegEx: Cheat Sheet, Tips, & Mistakes To Avoid

    • Использования регулярных выражений в гугл аналитикс

    • Как регулярные выражения упрощают работу в Google Analytics и Google Tag Manager

    Цикл событий Node.

    js и его показатели: все, что вам нужно знать

    Node.js — это платформа, основанная на событиях. Это означает, что все, что происходит в Node, является реакцией на событие. Транзакция, проходящая через Node, проходит каскад обратных вызовов.

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

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

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

    Распространенные заблуждения

    Libuv — это библиотека, которая обеспечивает цикл обработки событий для Node.js. В своем потрясающем программном докладе в Node Interactive Берт Белдер, один из ключевых людей, стоящих за libuv, начал с презентации поиска изображений в Google, который показал множество различных подходов, которые люди использовали для изображения цикла событий, и его разочаровывающее резюме заключалось в том, что большинство из них были неправы.

    Позвольте мне рассказать о (моих) самых популярных недоразумениях.

    Заблуждение 1: Цикл событий выполняется в отдельном потоке в коде пользователя

    Заблуждение

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

    Реальность

    Существует только один поток, выполняющий код JavaScript, и это поток, в котором выполняется цикл обработки событий. Выполнение обратных вызовов (знайте, что каждый пользовательский код в работающем приложении Node.js является обратным вызовом) выполняется циклом обработки событий. Мы рассмотрим это подробно чуть позже.

    Заблуждение 2: Все, что является асинхронным, обрабатывается пулом потоков

    Заблуждение

    Асинхронные операции, такие как работа с файловыми системами, выполнение исходящих HTTP-запросов или общение с базами данных, всегда загружаются в пул потоков, предоставляемый libuv.

    Reality

    Libuv по умолчанию создает пул потоков с четырьмя потоками для разгрузки асинхронной работы. Современные операционные системы уже предоставляют асинхронные интерфейсы для многих задач ввода-вывода (например, AIO в Linux).
    Когда это возможно, libuv будет использовать эти асинхронные интерфейсы, избегая использования пула потоков.

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

    Вкратце: Только если нет другого пути, пул потоков будет использоваться для асинхронного ввода-вывода.

    Заблуждение 3: Цикл событий похож на стек или очередь

    Заблуждение

    Цикл событий постоянно проходит через FIFO асинхронных задач и выполняет обратный вызов, когда задача завершена.

    Реальность

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

    Понимание фаз цикла цикла событий

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

    5 фаз выполнения цикла событий

    Давайте обсудим эти фазы. Подробное объяснение можно найти на веб-сайте Node.js.

    Таймеры

    Здесь будет обрабатываться все, что было запланировано через setTimeout() или setInterval().

    Обратные вызовы ввода/вывода

    Здесь будет обработано большинство обратных вызовов. Поскольку весь пользовательский код в Node.js в основном состоит из обратных вызовов (например, обратный вызов входящего http-запроса вызывает каскад обратных вызовов), это пользовательский код.

    Опрос ввода-вывода

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

    Set Immediate

    Запускает все обратные вызовы, зарегистрированные с помощью setImmediate().

    Close

    Здесь обрабатываются все обратные вызовы события on(‘close’).

    Мониторинг цикла событий

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

    Частота тактов

    Количество тактов за раз.

    Продолжительность тика

    Время, которое занимает один тик.

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

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

    Когда мы проводили наши первые тесты при разных нагрузках, результаты были неожиданными — позвольте мне показать вам пример:

    В следующем сценарии я вызываю приложение express. js, которое выполняет исходящий вызов на другой HTTP-сервер.

    Возможны четыре сценария:

    1. Бездействие
      Нет входящих запросов
    2. ab -c 5
      Используя скамейку apache, я создал 5 одновременных запросов за раз
    3. ab-c 10
      10 одновременно
    4. ab -c 10 (медленная серверная часть)
      Вызываемый http-сервер возвращает данные через 1 с для имитации медленной серверной части. Это должно вызвать нечто, называемое обратным давлением, поскольку запросы, ожидающие возврата серверной части, накапливаются внутри Node.

    Фазы выполнения цикла событий

    Если мы посмотрим на результирующую диаграмму, мы можем сделать интересное наблюдение:

    Продолжительность и частота цикла событий динамически адаптируются

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

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

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

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

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

    Задержка обработанной работы

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

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

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

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

    Задержка цикла событий

    Задержка цикла событий измеряет, сколько времени дополнительно требуется, чтобы задача, запланированная с помощью setTimeout(X), действительно была обработана.

    Высокая задержка цикла событий указывает на то, что цикл событий занят обработкой обратных вызовов.

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

    Запуск Apache Bench с 5 одновременными подключениями к этому маршруту с функцией Фибоначчи показывает, что теперь очередь обратного вызова занята.

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

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

    Настройка цикла обработки событий

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

    Исчерпан цикл событий

    Использовать все ЦП

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

    Настройка пула потоков

    Как уже упоминалось, libuv создаст пул потоков размером 4. Размер пула по умолчанию можно переопределить, установив переменную среды UV_THREADPOOL_SIZE.
    Хотя это может решить проблемы с нагрузкой в ​​приложениях, связанных с вводом-выводом, я бы рекомендовал чрезмерное нагрузочное тестирование, поскольку больший пул потоков может по-прежнему истощать память или ЦП.

    Передача работы службам

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

    Резюме

    Давайте обобщим то, что мы узнали в этом посте:

    • Цикл событий — это то, что поддерживает работу приложения Node.js
    • Его функциональность часто понимается неправильно — это набор фаз, которые непрерывно проходятся с конкретными задачами для каждой фазы
    • Нет готовых метрик, предоставляемых циклом обработки событий, поэтому собранные метрики различаются между поставщиками APM
    • Метрики явно дают ценную информацию об узких местах, но ключевое значение имеет глубокое понимание цикла обработки событий, а также выполняемого кода
    • В будущем Dynatrace добавит телеметрию цикла событий к обнаружению первопричин, чтобы сопоставлять аномалии цикла событий с проблемами

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

    Кредиты

    Наша звездная команда агентов Node.js приложила много усилий, чтобы правильно отслеживать цикл событий. Большая часть результатов, представленных в этом сообщении в блоге, основана на их глубоком знании внутренней работы Node.js. Я хотел бы поблагодарить Бернхарда Лидла, Доминика Грубера, Герхарда Штёбиха и Гернота Райзингера за всю работу и поддержку.

    Я надеюсь, что этот пост пролил свет на эту тему.

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

    Начните бесплатную пробную версию!

    Введение в создание метрических данных из неметрических данных

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

    В этом документе объясняется:

    • Причины использования этой функции
    • Доступные операции
    • Как использовать наш инструмент NerdGraph API для выполнения операций

    Зачем создавать метрики из других типов данных?

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

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

    Зачем использовать метрики?

    Комментарии

    Гибкость

    • Метрики являются размерными. Вы можете выбрать, какие метаданные (например, имя хоста или имя приложения) будут к ним прикреплены.
    • Общие метрические измерения, такие как среднее, сумма, минимум и максимум, уже рассчитаны.

    Сбор и хранение данных

    • Данные уже предварительно агрегированы в сегменты более длительного периода времени.
    • Срок хранения данных 13 месяцев.

    Возможности запросов

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

    Вот видео, показывающее, как генерировать метрические данные из неметрических данных (7:47 минут):

    Чтобы начать преобразование данных в показатели, создайте правило.

    Доступные операции

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

    Эти операции относятся к двум основным типам запросов:

    • Мутации , которые представляют собой операции, вносящие изменения в существующие правила или настройки (например, создание нового правила метрик).
    • Запросы для получения существующих данных (например, для получения существующих правил метрик).

    Все операции в NerdGraph основаны на ролях текущего пользователя New Relic.

    Мутации

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

    См. Создание метрик.

    Важно

    Эта операция изменяет производственные параметры, поэтому мы рекомендуем тщательно проверить ваши изменения перед запуском операции.

    Чтобы удалить правило, вам нужен идентификатор правила и идентификатор учетной записи New Relic.

    Пример Запрос: 

     
     Мутация {
     
     EventStometricsDeleTerule (Deletes: {RuleId: "12", AccountId: 123456}) {
     
     Успехи {
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    . 
     отправлено { 
     
     ruleId 
     
     accountId

    В этом запросе:

    Элемент

    Описание

    мутация

    Один из основных типов операций API.

    eventsToMetricsDeleteRule

    Метод, вызываемый для удаления правила.

    удаляет

    Принимает два параметра:

    • ruleId : идентификатор правила для метрик, протоколов или журналов для метрик, метрик.
    • accountId : идентификатор учетной записи New Relic.

    успехов и представленных блоков

    Здесь вы определяете данные, возвращаемые в случае успеха или неудачи. Available parameters for these blocks:

    • id (or ruleId for submitted )
    • name
    • description
    • nrql
    • включено
    • AccountId

    Пример ответа для запроса: 

     
     ": {
     2" EventstomTrics. успехов": [ 
     
     "id": "12", 
     
     "имя": "Правило тестирования", 
     
     "nrql": "выберите сводку (длительность) как "server.responseTime" из транзакции, где appName = "данные Имя фасета Points Staging, appName, host"
    Важно

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

    Чтобы включить или отключить существующее правило для событий в метриках, журналов в метриках или диапазонов в метриках, используйте ту же операцию eventsToMetricsUpdateRule . Единственная разница заключается в том, установлено ли для enable значение true или false .

    Пример запроса на включение существующего правила метрик: 

     
     Мутация {
     
     EventStometricsUpdaterule (обновления: {RuleId: "12", AccountId: 123456, включено: true}) {
     
     успехи {
     
    . {
     
     RuleID 
     
     AccountId

    В этом запросе:

    9999999999999999999999999999999999999999999999999999999999999999999999999999тели

    .0294 мутация

    Элемент

    Один из основных типов операций API.

    eventsToMetricsUpdateRule

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

    обновления

    Требуется три обязательных параметра:

  • accountId : идентификатор учетной записи New Relic.
  • включено : чтобы включить отключенное правило, установите для него значение true . Чтобы отключить правило, установите для него значение false .

    • успехов и представленных блоков

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

    • id (или ruleId for submitted )
    • name
    • description
    • nrql
    • enabled
    • accountId

    Queries

    Query operations include:

    You can list все правила в учетной записи New Relic или вернуть конкретное правило.

    Пример списка всех правил для учетной записи 123456 : 

     
     запрос { 
     
     Actor {
     
     Учетная запись (ID: 123456) {
     
     EventStometrics {
     
     Allrules {
     
     Правила {

    В этом запросе:

    4924592492492492492492492492492492492492492492492492462464924624646492446424646464646464642н.

    запрос

    Один из основных типов операций API. Используется для запроса, но не для внесения изменений.

    актер

    Указывает текущего пользователя New Relic.

    учетная запись(id: 123456)

    Укажите идентификатор учетной записи New Relic, откуда следует получать данные.

    eventsToMetrics

    Охватывайте данные только для правил «события-метрики», «журналы-метрики» или «промежутки-метрики».

    всеПравила

    Возвращает все правила для этой учетной записи.

    правила

    В блоке правил вы можете определить, какие данные вы хотите вернуть. Available fields include:

    • id
    • name
    • description
    • nrql
    • accountId
    • enabled

    Пример ответа: 

     
     "данные": { 
     
     "актер": { 
     
     "аккаунт": { 
     
     "eventsToMetrics": { 
     
     "allRules0": {
     
     "allRules0" [ 
     
     "description": "Метрика общего времени", 
     
     "включено": true, 
     
     "id": "1", 
     
     "name": "Общее время Tx", 
     
     "nrql": «выбрать summary(totalTime) как ‘server.totalTime’ из Transaction, где appName = ‘Data Points Staging’, имя фасета, appName, host» 
     
     "description": "Метрика длительности", 
     
     "enabled": true, 
     
     "id": "2", 
     
     "name": "Правило длительности", 
     
     "nrql": "выберите сводку (длительность) как 'server. responseTime' из Transaction, где appName = 'Data Points Staging' имя фасета, appName, host"

    Если вы знаете точный идентификатор правила, вы можете запросить конкретное правило. Например, вы только что создали правило и хотите просмотреть его содержимое, чтобы просмотреть его.

    Правило листинга примеров 36 для новой реликвической учетной записи 123456 : 

     
     Query {
     
     Actor {
     
     (ID: 123456) {
     
     {
     9000. 
     
     правила { 
     
     включено 
     
     описание 
     
     accountId

    Дополнительные сведения об элементах этого запроса см. в разделе Список всех правил.

    Пример ответа: 

     "данные": {
     "актер": {
     "аккаунт": {
     "eventsToMetrics": {
     "rulesById": {
     "правила": [
     "accountId": 123456,
    3 "описание": Метрика для общего времени»,
     «включено»: true,
     «id»: «36»,
     «имя»: «Общее время Tx»,
     «nrql»: «выбрать сводку (totalTime) как ' server.
    This entry was posted in Популярное