Як налаштувати моніторинг API в HostTracker

Main Settings

Для типу API скриншота цього розділу немає, але він використовує ті самі спільні елементи керування, що й будь-який інший тип перевірки. Monitoring enabled - головний перемикач увімкнено/вимкнено. Interval schedule (від 1 хвилини до 24 годин, повзунок чи розкривний список) або конструктор Cron schedule (кожні N хвилин/годин, щодня, щотижня, щомісяця, або власний вираз, лише платний план) визначають, як часто виконується перевірка. Timeout - від 1 до 100 секунд; час резолвінгу DNS не враховується. Tags - мітки через кому для групування й фільтрування. Full Log зберігає кожен результат замість групування однакових послідовних, а Open Stats публікує статистику й лог завдання за публічним посиланням. На відміну від HTTP, форма API не має перемикача DNSBL (DNSBL зберігається лише для Http/Ping/Port); зате в ній ті самі картки Domain Expiration, Certificate Expiration і Web Risk, кожна працює раз на 12 годин - нагадування про закінчення терміну дії йдуть за вашими підписками Up нижче, поганий результат - за Down/Repeat.

Request Configuration

• HTTP Method - GET, HEAD, POST, PUT, DELETE чи PATCH. GET (за замовчуванням) потрібен, щоб читати й аналізувати тіло відповіді; HEAD отримує лише заголовки.
• Request body (лише для POST/PUT/PATCH) - Raw body надсилає точно те, що ви ввели (додайте власний заголовок Content-Type, щоб описати json/xml/plaintext); POST parameters приймає по одному KEY=VALUE на рядок і надсилається як тіло form-urlencoded.
• Redirect behavior - Immediate response оцінює першу відповідь як є; Follow redirects (за замовчуванням) проходить весь ланцюжок, з повзунком Max redirects to follow (1-20); Redirect is error провалює перевірку на будь-якому редиректі (недоступно в режимі тверджень).
• HTTP Headers - власні пари ім'я/значення, з підказками зі списку для типових імен і значень заголовків API (Content-Type, Authorization, X-API-Key, префікси Bearer/Basic та інше). Якщо залишити порожнім, зонд надсилає типові заголовки (User-Agent, Accept, Accept-Language, Referer).
• Request authentication - розкриває ім'я користувача й пароль для власної HTTP-автентифікації сервера (Basic, Digest, NTLM, Kerberos, Negotiate). Для токена-носія чи ключа API натомість додайте заголовок Authorization вище.
• DNS Server Selection - Default DNS servers at locations; Public DNS servers of location's country; або Manually defined DNS servers (ваші власні IP-адреси резолвера). Останні два варіанти потребують платного плану.
• Disable DNS cache - примушує свіжий DNS-пошук при кожній перевірці замість повторного використання кешу агента.

Response Validation

За замовчуванням перевірка успішна, коли DNS резолвиться, з'єднання і TLS-рукостискання (для https) завершуються, сервер повертає статус HTTP Ok, а відповідь розбирається як обраний нижче формат.

• Assertion mode - на скриншоті він вимкнений, із банером, що запрошує увімкнути його для правил коду статусу, часу відповіді, заголовків чи вмісту тіла. API і HTTP - єдині два типи перевірки з робочим редактором тверджень; повний перелік правил дивіться в детальному розборі режиму тверджень. Поки він вимкнений, вердикт визначають класичні поля нижче.
• Ignore HTTP Errors - коди статусу, які НЕ мають провалювати перевірку, наприклад 401, 403, 500; порожнє поле означає, що кожен код 400+ - це помилка.
• Error on these HTTP statuses - навпаки: коди, які мають провалити перевірку, навіть якщо зазвичай не провалюють.
• Response format - як тіло розбирається перед запуском селектора: JSON analysis (JSONPath чи селектор властивості, обрано на скриншоті), XML analysis (запит XPath), чи String analysis (регулярний вираз із захопленням). Для читання тіла потрібен GET.
• Selector - обирає значення з розібраної відповіді; лишіть порожнім, щоб як значення використовувалася вся відповідь.
• What to check - за замовчуванням умова нижче оцінює саме обране значення (Check the obtained value itself); перемкніть на Check the value change between checks, або на швидкість зміни за секунду/хвилину, щоб замість цього оцінювати, наскільки значення змінилося.
• Condition - порівнює значення: any (no validation) (за замовчуванням, показано на скриншоті), equal to, not equal to, in set of, out of set, less than, less or equal, greater than, greater or equal, in range, out of range, absent in content чи json null. Кожна умова, крім двох останніх, потребує значення для порівняння, введеного під нею.
• HTTP Policies - ті самі опційні перевірки заголовків/кукі/вмісту, що й для типу HTTP-перевірки: Enforce HTTPS, заголовок HSTS, заборона пониження з https до http, CSP, захист від clickjacking, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, заборона розкриття версії, твердження Cache-Control, заголовки відповіді CORS, безпека кукі й змішаний вміст. Пресети Baseline, Strict і API замінюють увесь набір; порушення завершує перевірку як Down, як і будь-яка інша відмова.
• TLS Handshake - чотири перемикачі суворості (платний план): вимагати дійсний ланцюжок SSL-сертифіката, вимагати TLS 1.2 чи вище, блокувати слабкі (128-бітні чи нижче) шифри й перевіряти відкликання сертифіката.
• Expected IPs validation - підтверджує, що DNS резолвить ваш хост в одну з перелічених вами IP-адрес при кожній перевірці, ловлячи перехоплення чи застарілий запис, навіть якщо якийсь сервер усе ще відповідає.
• Max response size - зупиняє читання тіла після цього розміру, тож парсер і селектор бачать лише завантажену частину. За замовчуванням 1 МБ, максимум 10 МБ; 0 не читає тіло взагалі.

Примітка щодо скриншотів вище: їх зроблено на акаунті, пакет якого не включає тип перевірки API, тож поле вибору типу там показувало "not in your package". Це артефакт тестового акаунта, а не те, що побачите ви - кожне поле й типове значення, описані тут, в іншому відповідають саме тому, що показує форма.

Alert Subscriptions

Спільна для кожного типу перевірки. Down = ендпоінт провалив перевірку, Up = він відновився, Repeat = нагадування, поки він лишається в Down. Subscribe all contacts to Up/Down events - швидкий шлях; таблиця дає контроль по кожному контакту, окремо або через перевикористовувані пресети груп контактів. Завдання без жодної підписки на сповіщення все одно виконується й записує результати - воно просто нікого не сповіщає.

Report Subscriptions

Періодичні звіти про аптайм, лише електронною поштою. Оберіть Daily, Weekly чи Monthly для кожного контакту; Monthly також додає підсумки Quarterly і Yearly. Перемикач "підписати всіх" працює так само, як і в Alert Subscriptions.

Monitoring Locations

• Location picker - шукайте чи переглядайте дерево регіон/країна і позначайте локації для перевірки; кожен рядок показує доступних агентів проти обраних. "Copy locations from another task" перевикористовує вже наявний набір.
• Recheck strategy - під час переходу стану (наприклад, з Up у Down) кілька локацій перепідтверджують його, перш ніж новий стан буде прийнято, захищаючи від хибного спрацювання в одному регіоні. Варіанти: default - голосування більшості; specified number of locations, що підтверджують Down (додає повзунок 1-7); no recheck; full agreement усіх локацій повторної перевірки; або full agreement for Down, majority vote for Up.
• If selected locations are unavailable - Selected locations only (за замовчуванням) чекає, а не ризикує хибним сповіщенням; Closest locations використовує найближчу доступну локацію; Any location відкочується на весь світ.

Розібраний приклад

Моніторинг ендпоінта статусу JSON: перевірка API, інтервал 5 хвилин, тайм-аут 40 с, GET, Follow redirects (макс. 20). Response format - JSON analysis, Selector $.status, What to check - "the obtained value itself", Condition - "equal to" зі значенням порівняння ok. Ignore HTTP Errors лишено порожнім. Monitoring Locations лишено на All world зі стратегією повторної перевірки за замовчуванням. Email чергової команди підписано на Down, Up і Repeat, а також на щотижневі звіти.

Діагностика

• Перевірка завжди проходить, навіть коли ендпоінт явно зламаний - Condition за замовчуванням стоїть на any (no validation), що оцінює лише розбір і транспорт, а не саме значення. Оберіть справжню умову й значення порівняння, щойно знатимете, як виглядає здорова відповідь.
• Selector нічого не повертає - переконайтеся, що Response format відповідає тому, що повертає ендпоінт (JSON проти XML проти простого тексту); селектор JSONPath ніколи не збігається з тілом XML. Спершу лишіть Selector порожнім, щоб підтвердити, що вся відповідь доходить, а тоді звужуйте.
• Числова Condition (greater than, in range тощо) видає помилку - їй потрібно, щоб обране значення перетворювалося на число. Селектор, що вказує на рядок, чи обчислення в режимі зміни без попередньої перевірки, не дає їй чого порівнювати.
• Пішло в Down одразу після увімкнення HTTP Policies (особливо Strict) - Strict очікує заголовки, які багато API не налаштували. Виправте заголовки, знизьте до Baseline, або спершу запустіть політики окремим завданням.
• Селектор перестає знаходити значення на великій відповіді - Max response size обрізає тіло, тож нічого після обрізу не доходить до парсера чи селектора. Підніміть цей ліміт.

Пов'язане

• Моніторинг і перевірка API - сторінка продукту для цього типу перевірки.
• Безкоштовна миттєва перевірка HTTP/API - запустіть разову перевірку без акаунта.
• Правила перевірки відповіді в режимі тверджень - повна мова правил, що стоїть за Response Validation.
• API HostTracker - автоматизуйте керування моніторами з власного коду.
• Документація API v2 - повний довідник API, що використовується для побудови інтеграцій.
• 429 Too Many Requests - статус, який API повертає, коли викликача обмежено за швидкістю, і що з цим робити.
• Усі посібники з моніторингу - посібник з налаштування для кожного іншого типу перевірки.