Інструмент моніторингу API для перевірки ендпоінтів і аналізу тексту
Інструмент моніторингу API від HostTracker дозволяє задавати політики перевірки вмісту, який отримується з ваших ендпоінтів. Спершу він перевіряє, що тип вмісту коректний, а потім шукає задані значення всередині відповіді.
Перевіряйте не лише доступність - переконайтесь, що ваші API справді працюють
HostTracker перевіряє ваші API-ендпоінти за розкладом, контролюючи код статусу, тип вмісту та значення у відповіді - а не лише факт відповіді сервера.
Чому важливий моніторинг API
Моніторинг API дуже важливий. Він допомагає стежити за продуктивністю, доступністю та коректністю роботи ваших сервісів. А також гарантує відповідність стандартам продуктивності, що допомагає уникнути потенційних проблем
Доступність і продуктивність в одній перевірці
Моніторинг доступності - це, по суті, регулярна перевірка API-ендпоінта, щоб переконатись, що він доступний і працює справно. Моніторинг продуктивності вимірює, наскільки швидко й надійно API відповідає на запити.
Вплив надійних API на бізнес
Від того, наскільки добре працюють API, суттєво залежить досвід користувачів, загальна робота застосунків і навіть фінансові показники бізнесу.
Що перевіряє монітор API під час кожного запуску
Моніторинг REST API зовні виглядає як моніторинг доступності, але за суттю це інша робота. API споживає код, а не людина, а код невблаганний там, де браузер поблажливий. Людина-відвідувач терпить сторінку, що трохи неправильно відрендерилась; інтеграція, яка отримала поле неправильного типу, просто ламається. Тож моніторинг API має перевіряти більше рівнів, ніж просто "чи відповів сервер", і HostTracker перевіряє їх по черзі, проваляючись на першому ж, що не витримує.
| Рівень | Що перевіряється | Який збій виявляє |
|---|---|---|
| 1 · Доступність | DNS резолвиться, TCP-з’єднання відкривається, TLS-рукостискання завершується | Ендпоінт зник, сертифікат прострочено, хост недоступний з частини світу |
| 2 · Статус | HTTP-код стану, звірений з кодами, які ви приймаєте чи явно трактуєте як помилки | 500 після релізу, 401 через прострочені облікові дані, 429, якого ви не очікували |
| 3 · Час | Загальний час відповіді та його розкладка по з’єднанню, TLS, заголовках і тілу | Ендпоінт, що досі працює, але тихо перейшов з 200 мс на чотири секунди |
| 4 · Форма | Тип вмісту й заголовки - це справді JSON, чи HTML-сторінка помилки під виглядом 200 | Сторінка помилки чи редирект на вхід там, де має бути payload. Класичний тихий збій API |
| 5 · Вміст | Значення, вибране з payload, або вільні перевірки над усією відповіддю | Поле зникло після зміни схеми, порожній набір результатів, рядок версії, що відкотився назад, член помилки, що з’явився всередині успішної відповіді |
Рівні з першого по третій - те, що дає звичайна перевірка доступності. Четвертий і п’ятий роблять це моніторингом API - і саме на цих рівнях живе більшість реальних інцидентів з API.
Налаштування запиту
Перш ніж щось можна буде перевірити, монітор має виконати той запит, якого очікує ваш API. На моніторі API доступна повна поверхня запиту:
| Налаштування | Що з ним можна зробити |
|---|---|
| HTTP-метод | GET, HEAD, POST, PUT, PATCH або DELETE |
| Власні заголовки | Будь-які потрібні пари ім’я-значення - bearer-токен, API-ключ, ідентифікатор орендаря, версійний заголовок Accept. Заголовки переадресовуються лише на той самий хост при редиректі, тож облікові дані ніколи не витечуть до третьої сторони, на яку перенаправляє ваш ендпоінт. |
| Тіло запиту | Сире тіло для POST, PUT і PATCH, або параметри у форматі форми |
| HTTP-автентифікація | Ім’я користувача та пароль, зі схемою, яку вимагає сервер, узгодженою на з’єднанні |
| Редиректи | Слідувати за ними чи ні, обмежити кількість переходів, або трактувати будь-який редирект як збій - корисно для ендпоінта, що має відповідати напряму |
| Тайм-аут | До 100 секунд, за замовчуванням 40 - і тайм-аут вважається проваленою перевіркою, а це саме те, чого ви очікуєте від ендпоінта з SLA |
| Обмеження розміру відповіді | За замовчуванням 1 МБ, можна підвищити, тож нестримна відповідь не поглине перевірку |
| Прийняті й відхилені коди статусу | Списки кодів, які ігнорувати, і кодів, які трактувати як помилки, - інструмент для ендпоінта, що законно відповідає 401 чи 404 як частиною свого контракту |
| Контроль DNS | Резолвити через конкретні резолвери, обходити DNS-кеш чекпоінта та перевіряти, на які IP-адреси резолвиться хост |
| Суворість TLS | Опційно вимагати дійсний ланцюжок сертифіката, TLS 1.2 чи новіший, шифри понад 128 біт і перевірку відкликання - плюс відстеження закінчення терміну дії сертифіката на тому самому з’єднанні |
Перевірки (assertions): опис того, як виглядає здорова відповідь
Найвиразніший спосіб перевірити відповідь - написати для неї правила. Кожне правило - один рядок, правила поєднуються через AND, і монітор може нести до двадцяти таких правил. Ось перевірений стартовий набір для JSON API:
status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5sЧотири рядки, і разом вони покривають чотири рівні, що мають значення: ендпоінт відповів кодом 2xx, він відповів JSON, а не сторінкою помилки, payload містить реальний результат, а не порожній, і все це вклалося в бюджет часу. Серед окремо корисних правил з того самого каталогу -
body.json.path("$.status") eq "ok" для власного вердикту здоров’я API,
body.json.path("$.error") absent для члена помилки, що з’явився в інакше успішній відповіді,
body.json.path("$.version") eq "2.4.1", щоб виявити ненавмисний відкат,
redirects.count eq 0 для ендпоінта, що має відповідати напряму, і
cert.days.left gt 14 для сертифіката на тому самому з’єднанні.
Про що може говорити правило
Правила зчитують суб’єкти з відповіді й порівнюють їх. Суб’єкти покривають код статусу; загальний час відповіді та його складові з’єднання, TLS, DNS, заголовків і тіла; сире тіло разом із його розміром і хешем; структуровані запити в payload у форматі JSON, XML, HTML чи YAML; окремі заголовки відповіді; кінцеву й початкову URL-адреси та їхні частини; ланцюжок редиректів, крок за кроком; кількість днів до закінчення терміну дії сертифіката, видавця й імена; погоджений протокол TLS і шифр; адреси, які повернув DNS; і Set-Cookie. Порівняння охоплюють очевидні - рівно, менше, більше - а також contains, startsWith, endsWith, matches для регулярного виразу, containsAny і containsAll для набору, in для списку прийнятних значень, а також exists, isNumber і unique.
Є й вісь виявлення змін: правило може порівняти значення цього запуску з попереднім, тож можна перевірити, що лічильник ніколи не йде назад або що хеш тіла не змінився, - це форма правила, яка виявляє тихий відкат чи несанкціоновану зміну вмісту, а не простій.
Отримання одного значення з payload
Поряд із мовою правил є простіший шлях для одного значення, який давно є частиною моніторингу API тут і часто це все, що потрібно перевірці. Ви вказуєте монітору, як розібрати тіло, як вибрати з нього одне значення, і яким це значення має бути:
- Розібрати як JSON, і селектор - вираз JSONPath.
- Розібрати як XML, і селектор - вираз XPath, - саме це робить перевірку SOAP та інших XML-сервісів простою.
- Трактувати як звичайний текст, і селектор - багаторядковий, нечутливий до регістру регулярний вираз.
Предикат, застосований до вибраного значення, охоплює рівно й не рівно, менше й більше у строгій та включній формах, входження в список прийнятних значень чи виключення з нього, входження в числовий діапазон чи вихід за нього, а також перевірку, чи значення є null або взагалі відсутнє.
Некоректний селектор відхиляється під час збереження, а не о третій ночі. Селектор компілюється на етапі валідації, тож одруківка в JSONPath чи XPath - це помилка форми, а не монітор, що тихо провалюється - або тихо проходить - з моменту створення.
Збої, яких перевірка коду статусу не бачить
Кожен збій у цій таблиці повертає HTTP 200. У цьому вся проблема моніторингу API лише за кодом статусу: транспорт спрацював успішно, тож транспорт і повідомляє про успіх.
| Що пішло не так | Як виглядає відповідь | Що це виявляє |
|---|---|---|
| Сторінка помилки подається там, де має бути payload | 200, з HTML | Перевірка типу вмісту, або правило, що тіло розбирається як JSON |
| Пошуковий індекс перестав перебудовуватись | 200, з порожнім масивом результатів | Правило, що кількість результатів щонайменше одна |
| Поле перейменували при зміні схеми | 200, дійсний JSON, поле відсутнє | Правило, що поле існує |
| Реліз відкотили, і ніхто цього не помітив | 200, старіший рядок версії | Правило, що фіксує поле версії |
| Член помилки з’являється всередині успішної обгортки | 200, з встановленим членом помилки | Правило, що член помилки відсутній |
| Залежність нижче за течією дає збій, і API м’яко деградує | 200, з частковими чи застарілими даними | Правило на власному полі здоров’я API, або значення свіжості в payload |
| Ендпоінт тепер відповідає за чотири секунди замість двохсот мілісекунд | 200, зрештою | Правило часу відповіді |
| Автентифікація тихо перестала застосовуватись | 200, повертає дані, яких не мала б | Окремий негативний монітор - неавтентифікований запит, що має повернути 401 |
Останній рядок вартий того, щоб зробити його свідомо. Другий монітор, що не надсилає облікових даних і перевіряє 401, - найдешевший спосіб дізнатися, що рівень авторизації випадково вимкнули, - збій, який жодна кількість позитивного тестування ніколи не виявить.
Перевірка з 300+ локацій, без хибних тривог
Монітори API виконуються з публічної мережі чекпоінтів HostTracker - 300+ точок у 158 містах, - і ви обираєте, які локації використовує конкретний монітор. Географія має більше значення для API, ніж для сайту: ендпоінт, що стоїть за CDN чи гео-маршрутизованим балансувальником навантаження, може бути справним у Франкфурті й давати збій у Сан-Паулу, а перевірка з однієї локації не має жодного способу це побачити. Те саме стосується DNS - застарілий чи неправильно налаштований запис часто поширюється нерівномірно, що зсередини виглядає як переривчастий збій, а ззовні - як регіональний.
Виконання з багатьох місць породжує очевидний ризик: більше чекпоінтів - більше шансів, що один нестабільний мережевий шлях підніме хибну тривогу. HostTracker вирішує це кворумом підтвердження. Коли чекпоінт повідомляє про збій, перевірка повторюється на додаткових незалежних чекпоінтах, і зміна стану підтверджується лише тоді, коли вони погоджуються, - за замовчуванням це мажоритарний вердикт серед максимум семи агентів, мінімум трьох. Ви можете зробити це суворішим, вимагаючи певної кількості агентів, що повідомляють про збій, або повної згоди серед них, - для ендпоінта, де хибне сповіщення гірше за повільну відповідь.
Після підтвердження сповіщення надходять із затримкою, яку обрав кожен контакт, - одразу, або через 3, 5, 15, 30 чи 60 хвилин, або через 3, 6, 12 чи 24 години безперервного збою, - дев’ятьма каналами сповіщень: електронна пошта, SMS, голосовий дзвінок, webhook, Slack і месенджери Telegram, Discord, Viber, Facebook Messenger і Google Chat. Канал webhook - це те, як сповіщення доходять до менеджера інцидентів чи інструменту командного чату.
REST, GraphQL, SOAP і приймачі webhook
Перевірка - це налаштовуваний HTTP-запит плюс аналіз відповіді, тож те, що вона покриває, випливає напряму з цього.
- REST і JSON API - найпоширеніший випадок, і моніторинг REST API - те, що більшість акаунтів налаштовує першим: GET чи POST, заголовки для облікових даних, і правила JSONPath чи assertion над payload.
- GraphQL працює як POST із запитом у тілі, а потім JSONPath у
data, - і варто перевіряти, що членerrorsвідсутній, адже GraphQL відомий тим, що відповідає 200 з помилками всередині. - SOAP і XML-сервіси - це POST із конвертом як тілом і XPath як селектором, що дістається до відповіді точно так, як передбачає специфікація.
- Приймачі webhook і callback-ендпоінти можна перевіряти на доступність і на відповідь, яку вони дають на добре сформований запит, - це цінно, бо приймач, що тихо перестав приймати доставки, не видає жодної помилки ніде у вашій власній системі.
- Ендпоінти health і readiness - найцінніша ціль з усіх, якщо вони у вас є: ваш застосунок уже знає, чи здорові його залежності, і перевірка цього вердикту перетворює його власне знання на сповіщення.
Що не підходить - це послідовність: отримати токен, використати його, а потім видалити ресурс. Монітор API робить один запит за запуск. Для справжнього багатокрокового сценарію інструмент - це керована браузером перевірка транзакції; для часу завантаження сторінки, а не ендпоінта, див. моніторинг доступу браузера й часу завантаження.
Налаштування першого монітора API
- Спершу спробуйте ендпоінт за допомогою безкоштовної миттєвої HTTP-перевірки - без входу в акаунт, - щоб побачити статус, час і відповідь, для якої ви збираєтесь писати правила.
- Додайте монітор і оберіть тип моніторингу API. Задайте метод, додайте заголовки чи тіло, потрібні ендпоінту; видайте монітору власні облікові дані, а не чужі особисті.
- Напишіть правила перевірки. Почніть із чотирирядкового набору вище - статус, тип вмісту, одне значуще значення з payload і бюджет часу відповіді, - справді хороший варіант за замовчуванням майже для будь-якого JSON API.
- Оберіть інтервал від однієї хвилини до 24 годин. Три хвилини - значення за замовчуванням і розумна відправна точка; одну хвилину лишіть для ендпоінтів, збій яких - інцидент.
- Оберіть локації. Два чи три регіони, де реально живуть ваші споживачі, кращі за один, і саме це робить регіональний збій видимим.
- Додайте контакти й задайте затримку сповіщення для кожного. Не всім потрібно чути про це на першій хвилині.
- Дайте попрацювати день, а потім погляньте на історію часу відповіді, перш ніж посилювати правило часу. Бюджет, заданий на реальних даних, тримається; заданий на здогадці - глушать.
Моніторинг API проти APM і observability
Це взаємодоповнювальні речі, які часто плутають. Платформа observability чи APM інструментує ваш код і повідомляє, що сталося всередині запиту. Зовнішній моніторинг API стоїть поза вашою інфраструктурою й повідомляє, що насправді отримує споживач. Обидва варті наявності; жоден не замінює іншого.
| Зовнішній моніторинг API | APM / observability | |
|---|---|---|
| Точка спостереження | Поза вашою інфраструктурою, через публічний інтернет | Усередині процесу вашого застосунку |
| Потребує змін у коді | Ні - нічого нікуди не встановлюється | Агент чи SDK у кожному сервісі |
| Бачить проблеми DNS, маршрутизації, TLS і CDN | Так - вони на шляху, яким він іде | Ні - вони стаються до того, як запит прибуде |
| Все ще звітує, коли вся платформа лежить | Так - хоститься не вами | Часто ні - те, що звітує, теж лежить |
| Пояснює, чому запит був повільним усередині вашого коду | Ні - бачить розкладку часу, а не ваш стек | Так - у цьому вся його мета |
| Покриває ендпоінт, який сьогодні ніхто не викликав | Так - викликає його за розкладом | Ні - немає трафіку, немає телеметрії |
Патерн, до якого приходить більшість команд, - зовнішній моніторинг для виявлення й внутрішня телеметрія для діагностики: HostTracker повідомляє вам, що ендпоінт зламався, звідки й проти якого правила, а власний трейсинг повідомляє чому. Поряд із цим монітор запитів до бази даних часто пояснює API, що почав повільно відповідати, а моніторинг навантаження сервера пояснює хост, на якому він працює.
Обмеження, про які варто знати
- Один запит за запуск. Жодного обміну токенами, жодних ланцюжків викликів. Спрямуйте монітор на ендпоінт, чия автентифікація не спливає, і використовуйте перевірку транзакції, коли потрібно довести саме послідовність.
- Двадцять правил перевірки на монітор. На практиці достатньо - чотирирядковий набір покриває більшість ендпоінтів, - але варто знати це перед плануванням контрактного тесту на сотню правил.
- Режим assertion замінює старіші налаштування ключових слів і статусу. Дві моделі не можна поєднати на одному моніторі; оберіть мову правил або застарілий режим ключових слів, не обидва.
- Немає валідації OpenAPI чи JSON-схеми. Ви перевіряєте конкретні значення й структури, а не цілий документ схеми.
- Тіло запиту має обмеження довжини, тож дуже великий POST-payload - не той формат, під який побудована ця перевірка.
- Це моніторинг, а не тестування. Правильна ціль - доступний лише для читання чи ідемпотентний ендпоінт. Монітор, що змінює дані кожні три хвилини з кількох локацій, зрештою стане причиною інциденту, а не тим, що його виявляє.
Часті запитання
Інструмент моніторингу API надсилає запити до ваших ендпоінтів за розкладом і перевіряє відповідь за правилами, які ви задали, а не просто фіксує факт відповіді сервера. Моніторинг API від HostTracker спершу перевіряє, що ендпоінт доступний і повертає очікуваний HTTP-статус, потім - що тип вмісту відповіді відповідає заданому (JSON, XML, звичайний текст тощо), і нарешті шукає в тілі відповіді конкретні значення чи патерни, які ви налаштували. Такий багаторівневий підхід виявляє проблеми, які проста перевірка "чи працює сайт" повністю пропустить: ендпоінт може повертати звичайний статус 200, водночас віддаючи пошкоджені, неповні або застарілі дані через помилку на бекенді, невдалий запит до бази даних чи розірвану інтеграцію далі в ланцюжку. Чіткі політики валідації одразу дають монітору розуміння, як насправді виглядає здорова відповідь саме для вашого API.
Моніторинг доступності сайту зазвичай перевіряє лише, чи завантажується сторінка і чи повертається нормальний HTTP-статус, - це добре працює для сторінок, призначених для перегляду в браузері. Моніторинг API йде далі, адже API споживає код, а не людина, тож "робоча" відповідь має відповідати суворішим вимогам: правильний тип вмісту, коректна структура і правильні значення всередині даних, а не просто успішний статус. Ендпоінт може повертати HTTP 200, водночас маючи неправильні, відсутні чи пошкоджені дані, і звичайна перевірка доступності цього не виявить, оскільки дивиться лише на код відповіді. Моніторинг API від HostTracker перевіряє обидва рівні - доступність і статус, як і класичний uptime-моніторинг, плюс валідацію типу вмісту та пошук очікуваних значень у тілі відповіді, - даючи набагато точнішу картину того, чи справді API працює коректно.
Так, саме це і відрізняє моніторинг API від простої перевірки доступності. HostTracker дозволяє задавати політики валідації, які виходять за межі простого підтвердження відповіді ендпоінта: ви можете вказати очікуваний тип вмісту, щоб перевірка провалювалась, якщо ендпоінт раптово почне повертати HTML замість JSON (типова ознака сторінки помилки замість реальних даних), а також шукати у вмісті відповіді конкретні значення, наявність яких означає, що відповідь є здоровою. Це означає, що перевірка може провалитися навіть тоді, коли HTTP-статус виглядає абсолютно нормальним, - виявляючи випадки, коли помилка на бекенді чи розірвана інтеграція далі по ланцюжку дає технічно успішну, але функціонально неправильну відповідь. Саме перевірка реального вмісту, а не лише з’єднання, робить моніторинг API справді значущим для ендпоінтів, від яких залежать інші системи.
Після підтвердження того, що ендпоінт відповідає і тип вмісту збігається з очікуваним, моніторинг API від HostTracker шукає в отриманому вмісті конкретні значення чи текстові патерни, які ви задали в політиці валідації перевірки. Це дозволяє переконатись, що відповідь містить певне поле, значення статусу чи інші дані, які свідчать про коректну роботу ендпоінта, - наприклад, перевірити, що відповідь health-check ендпоінта містить очікуване значення статусу, а не повідомлення про помилку, загорнуте у відповідь зі статусом 200. Якщо очікуваний вміст не знайдено, перевірка позначається як невдала, навіть якщо саме з’єднання відбулося успішно, і ви отримуєте сповіщення через налаштовані канали. Такий контроль з урахуванням вмісту особливо корисний для виявлення часткових збоїв, коли API технічно доступний, але непомітно повертає неповні чи некоректні дані.
Частота перевірок налаштовується, а платні тарифи HostTracker підтримують інтервали до однієї хвилини для всіх типів моніторингу, тож критично важливі для роботи вашого застосунку API-ендпоінти можна перевіряти майже безперервно. Безкоштовний тариф без обмеження в часі виконує перевірки кожні 30 хвилин для до двох моніторів - цього достатньо для менш пріоритетних чи внутрішніх API, де невелика затримка у виявленні проблеми не критична. Для бізнес-критичних API - тих, що живлять робочий застосунок, платіжний процес чи інтеграцію, від якої залежать ваші клієнти, - коротші інтервали означають, що проблеми виявляються й усуваються ще до того, як переростуть у масштабний збій, помітний користувачам. 30-денний повнофункціональний тестовий період із перевірками щохвилини та без потреби вказувати платіжну картку дозволяє перевірити, наскільки швидким має бути виявлення проблем саме для вашого API.
Так. Монітор API може надіслати все, що вимагає ендпоінт, аби прийняти запит: довільні власні заголовки - саме так передається bearer-токен, заголовок API-ключа чи ідентифікатор орендаря - плюс ім’я користувача та пароль для HTTP-автентифікації, тіло запиту для POST, PUT чи PATCH, і будь-який HTTP-метод від GET і HEAD до POST, PUT, PATCH і DELETE. Практична порада та сама, що й для будь-якого автоматизованого клієнта: видайте монітору власні облікові дані, а не використовуйте чужі особисті, надайте якомога вужчий обсяг прав, що все ж змістовно перевіряє ендпоінт, і надавайте перевагу доступному лише для читання ендпоінту чи виділеному маршруту перевірки стану перед будь-чим, що змінює дані. Якщо ваші токени короткоживучі, спрямуйте монітор на ендпоінт, чия автентифікація не спливає, - маршрут стану чи здоров’я, захищений довгоживучим ключем, - а не намагайтеся змусити монітор виконувати обмін токена, якого він виконати не може.
Перевірки API виконуються з інтервалом від однієї хвилини до 24 годин - 1, 2, 3, 5, 10, 15, 30 і 45 хвилин, потім 1, 2, 4, 6, 12 і 24 години, - і новий монітор за замовчуванням отримує три хвилини. Вони виконуються з публічної мережі чекпоінтів HostTracker, яка охоплює 300+ точок у 158 містах, і ви обираєте, які локації використовує конкретний монітор. Виконання з кількох регіонів має більше значення для API, ніж для сайту: ендпоінт, що стоїть за CDN чи гео-маршрутизованим балансувальником навантаження, може бути цілком справним в одному регіоні й давати збій в іншому, а перевірка з однієї локації просто не здатна цього побачити. Це також визначає контроль хибних тривог - коли одна локація повідомляє про збій, перевірка повторюється з інших незалежних локацій, і зміна стану підтверджується лише тоді, коли кворум погоджується, тож один нестабільний мережевий шлях між дата-центром і вашим хостом нікого не потурбує.
Коли перевірка моніторингу API не проходить - через те, що ендпоінт не відповів, повернув неочікуваний тип вмісту або не містив значень, яких вимагає ваша політика валідації, - HostTracker надсилає сповіщення через будь-який із 9 налаштованих каналів, зокрема email, SMS, голосовий дзвінок, webhook, Slack і месенджери на кшталт Telegram, Discord та Viber. Це дозволяє вашій команді дізнатись про несправний чи деградований API одразу в момент виявлення, а не з тікета підтримки після того, як інтеграція вже кілька годин тихо не працювала. Оскільки перевірка оцінює і доступність, і вміст, сповіщення відображає реальну функціональну проблему з API, а не просто короткий збій зв’язку, що допомагає уникнути як пропущених інцидентів, так і зайвого шуму.
Продовжуйте вивчати моніторинг HostTracker
Симулюйте багатокрокові сценарії оформлення замовлення та входу
Моделюйте реальні користувацькі сценарії - вхід, пошук, оформлення замовлення - і отримуйте сповіщення в момент, коли крок сценарію ламається або сторінка перестає відповідати коректно.
Відстежуйте реальну швидкість завантаження сторінок із 300+ локацій
Автоматизуйте реальне відвідування вашої сторінки браузером і вимірюйте час завантаження відповідно до заданої вами політики, щоб уповільнення виявлялися раніше, ніж відвідувачі почнуть залишати сайт.
Перегляньте всі можливості моніторингу HostTracker
Порівняйте всі 8 типів моніторингу поруч і комбінуйте перевірки, що підходять саме вашому сайту.
Моніторте свої API-ендпоінти 24/7
Почніть безкоштовний тест і отримуйте сповіщення миттєво, щойно ендпоінт поверне неправильний статус, порушить контракт даних або почне сповільнюватись.