Завдання зі збору даних може не вдатися з багатьох причин. Цільова сторінка може блокувати запит. Опції запиту можуть бути неправильними. У обліковому записі може не бути кредитів. З'єднання з сервісом також може бути недоступним на короткий час. Просте перевірка статусу допомагає вам відокремити ці випадки.
URL статус API ScraperFly є легким перевіркою стану. Ваша система може викликати його за розкладом, зберігати результат і створювати невелику історію доступності сервісу та часу відповіді.
Ця сторінка пояснює простий спосіб використання перевірки статусу. Мета не в тому, щоб замінити журнали запитів. Мета полягає в тому, щоб додати один чіткий сигнал: чи може ваша система зараз досягти ScraperFly, і як швидко відповідає перевірка?
Для чого потрібен URL статус API
URL статус API є невеликою перевіркою сервісу. Він повідомляє вашій програмі, чи можна досягти ScraperFly з місця, де виконуються ваші власні завдання. Якщо перевірка відповідає здоровим результатом, ваша програма знає, що основний шлях сервісу працює.
Це не означає, що кожен збір даних буде успішним. Здорова перевірка сервісу не виправляє поганий URL, заблоковану цільову сторінку, неправильний API ключ, відсутній баланс кредитів або сторінку, яка потребує рендерингу JavaScript. Вона лише відповідає на одне просте питання: чи доступний сервіс ScraperFly прямо зараз?
Як перевіряти стан сервісу кожні кілька хвилин
Практичний монітор може викликати URL статус API кожні п'ять хвилин. Для кожної перевірки зберігайте час, HTTP результат і час відповіді. Це дає вашій команді простий огляд доступності з часом.
Не сповіщайте про один повільний або невдалий зразок занадто швидко. Мережі можуть мати короткі затримки. Кращий монітор чекає повторних невдач або чіткої схеми повільних часів відповіді перед відправкою сповіщення.
| Значення для зберігання | Чому це допомагає |
|---|---|
| HTTP результат | Показує, чи успішно відповіла перевірка статусу. |
| Час відповіді | Показує, скільки часу зайняла перевірка сервісу з вашого середовища. |
| Час перевірки | Показує, коли був зібраний зразок. |
| Кількість невдач | Допомагає уникнути шумних сповіщень від однієї короткої проблеми з мережею. |
Приклад журналу статусу
Невелика таблиця достатня для багатьох команд. Ви можете зберігати останні кілька годин або днів перевірок і показувати їх на внутрішній панелі. Таблиця нижче є лише прикладом типу даних, які ви можете зберігати.
| Час | URL перевірки | Результат | Час відповіді | Примітка |
|---|---|---|---|---|
| 09:00 | /api/v1/status | 200 OK | 142 ms | Перевірка сервісу пройшла. |
| 09:05 | /api/v1/status | 200 OK | 156 ms | Перевірка сервісу пройшла. |
| 09:10 | /api/v1/status | 200 OK | 149 ms | Перевірка сервісу пройшла. |
Як читати статус разом з журналами запитів
Використовуйте перевірку статусу разом з нормальними журналами збору даних. Якщо перевірка сервісу є здоровою, але збір даних не вдався, подивіться на сам запит: цільовий URL, цільовий код статусу, фінальний URL, розмір відповіді, формат виходу, опцію рендерингу, історію повторних спроб і стан облікового запису.
Якщо перевірка сервісу не вдається багато разів підряд, розглядайте це як сигнал про проблеми з підключенням до сервісу. Призупиніть шумні повторні спроби, зберігайте невдалі завдання в черзі та повторюйте їх після стабільної перевірки стану.
Що не доводить перевірка статусу
Перевірка статусу не є гарантією того, що цільовий веб-сайт поверне придатні дані. Вона не тестує ваш цільовий URL. Вона не підтверджує, що сторінка дозволяє доступ. Вона не підтверджує, що потрібен рендеринг JavaScript. Вона також не замінює діагностику на рівні облікового запису, виставлення рахунків або запитів.
Думайте про це як про один маленький операційний сигнал. Це допомагає відповісти на питання, чи доступний ScraperFly. Після цього ваші журнали запитів пояснюють, що сталося з кожним запитом на збір даних.
Часті запитання
Як часто я повинен викликати URL статус API ScraperFly?
Для невеликого монітора стану перевірка кожні п'ять хвилин зазвичай достатня. Ви можете використовувати коротший інтервал, якщо ваша система потребує швидших сповіщень.
Чи означає здоровий статус, що кожен запит на збір даних спрацює?
Ні. Здоровий статус лише означає, що сервіс доступний. Помилки цілі, неправильні опції запиту, проблеми з обліковим записом, обмеження швидкості та блокування доступу все ще потребують діагностики на рівні запиту.
Чи повинен я зупинити всі завдання збору даних після одного невдалого статусу?
Зазвичай ні. Один невдалий статус може бути короткою проблемою з мережею. Краще почекати повторних невдач перед призупиненням завдань або відправкою сповіщення.