Перейти до основного вмісту

Посібники / Терміни моніторингу пояснено

Синтетичний моніторинг проти RUM: що ловить кожен

Синтетичний моніторинг виконує сценарні перевірки за розкладом з локацій, які ви обираєте; моніторинг реальних користувачів (RUM) записує показники з браузерів людей, що відвідують ваш сайт. Синтетичний моніторинг каже, чи сайт працює, а RUM каже, яким він був на дотик для людей, які там були.

Що робить кожен із них

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

Моніторинг реальних користувачів, зазвичай скорочено RUM, пасивний. Невеликий скрипт на ваших сторінках повідомляє, що виміряв браузер під час цього візиту: час навігації, завантаження ресурсів, помилки та Core Web Vitals так, як їх пережив відвідувач. Він дає дані лише пропорційно до вашого трафіку і не дає нічого, коли нікого немає.

Що ловить синтетичний моніторинг, а RUM пропускає

  • Збої о четвертій ранку чи на будь-якій сторінці з малим трафіком. Якщо ніхто не завантажує сторінку, RUM нема про що повідомляти, а повний збій - це якраз той випадок, коли маячок неможливо надіслати
  • Доступність із місць, де у вас ще немає користувачів, - саме так ви дізнаєтеся, що новий ринок не може до вас достукатися
  • Чисту базову лінію. Той самий скрипт, з тієї самої локації, з тим самим інтервалом, тож зміна числа - це зміна на сайті, а не в тому, хто саме зайшов
  • Багатокрокові сценарії, які ви не хотіли б випробовувати на реальних користувачах, як-от оформлення замовлення, що створило б справжнє замовлення, чи вхід, який можна прогнати на тестовому акаунті
  • Збої закінчення терміну дії й конфігурації, які взагалі не доходять до браузера: сертифікати, DNS-записи, внесення до чорних списків, відкриті порти
  • Першу відмову після деплою, ще до того, як прийде трафік, який би її виявив

Що ловить RUM, а синтетичний моніторинг пропускає

  • Реальний розподіл пристроїв, мереж і локацій. Синтетична перевірка з підключення дата-центру ніколи не відтворить бюджетний телефон на мобільному інтернеті
  • Сторонні скрипти, банери згоди й персоналізацію, які завантажуються лише для реальних сесій зі справжніми кукі
  • Проблеми, що зачіпають частину користувачів: одну версію браузера, один регіон, один варіант A/B-тесту
  • Які саме повільні сторінки насправді мають значення, зважено за кількістю людей, що їх бачать
  • Польові Core Web Vitals, саме те, що використовують пошукові системи, на відміну від лабораторних значень, які дає синтетичний запуск

Коли потрібне і те, і те

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

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

Практичне налаштування - це синтетичні перевірки, що керують сповіщеннями й записом аптайму, і RUM, що керує чергою на продуктивність. Якщо ви можете запустити лише щось одне, запускайте синтетичний моніторинг: непомічений збій коштує дорожче за невиміряну повільну сторінку, а RUM не може повідомити про сторінку, яка не завантажилася.

Де тут місце транзакційного моніторингу

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

Оскільки це синтетична перевірка, вона працює за розкладом без потреби в трафіку, а оскільки вона керує справжнім браузером, вона відпрацьовує JavaScript, сторонні залежності й редиректи, які проста HTTP-перевірка пропускає. Транзакційний моніторинг HostTracker працює саме так, а посібник із транзакційної перевірки описує, як записується сценарій і що повідомляє кожен крок.

Як перетворити вимірювання на сповіщення

Жоден із підходів не має користі, поки щось не діє за результатом. Синтетична перевірка варта того, бо вона працює незалежно від того, стежите ви за нею чи ні, і бо відмова може дійти до вас негайно: HostTracker виконує перевірки з понад 300 контрольних точок у 158 містах у 13 типах моніторів і надсилає сповіщення електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та інших каналах, коли результат змінюється. Поєднайте це з будь-яким RUM, який ви вже збираєте, і у вас є обидві половини: сповіщення, коли сайт ламається, і докази того, для кого саме він був повільним. Решта розділу про поняття моніторингу охоплює терміни, на яких тримаються обидва підходи.

Перевірити зараз

Запустіть безкоштовну перевірку власного сайту - обліковий запис не потрібен.

Transaction monitoring

Стежити за цим постійно

Отримуйте сповіщення в момент збою: HostTracker перевіряє з понад 300 локацій і повідомляє вас електронною поштою, SMS, у Slack, Telegram та інших каналах.

Можливості HostTracker

Ще в цьому розділі: Терміни моніторингу пояснено