Comments 6
А если не хватит какой-то функции
Собственно, на первый взгляд, больше всего не хватает функционала "локации", потому что доступность публичного сервиса надо измерять минимум с двух (а лучше трех) удаленных друг от друга локаций: Если сервис "недоступен в Москве" - это далеко не всегда значит что он недоступен в Новосибирске (и наоборот)
Ну в рамках одной страны наверняка результаты будут идентичными по доступности и недоступности.
И я вот мониторю Инстаграм
и тут есть намёк что недоступен он может быть только из РФ
в рамках одной страны
не факт. Все таки чеки ходят через интернет, а там набор провайдеров со своими проблемами. Даже у самих PingZen могут быть проблемы с доступом в интернет из того датацентра где они чеки гоняют - а вам прилетит алёрт, что у вас сервис недоступен.
Много лет жил на пингдоме где собственно и есть механика, что недоступность должна быть подтверждена из другой локации - иначе алерт о недоступности не шлём. При этом другой сервис (монитис) имел какие-то проблемы с логикой такого алерта, и когда у него фейлилось на одной ноде - алерт прилетал, несмотря на то что проблемы часто были у того датацентра где размещена чекер (или вообще даже у самого чекера!)
Transaction-мониторинг интересная идея, но на практике есть один нюанс, который легко упустить: headless Playwright из коробки имеет характерный fingerprint, и многие сайты его обнаруживают. В результате сценарий «проходит», страница открывается, форма видна, но сайт отдаёт другой контент, показывает капчу или просто блокирует сессию. Монитор видит 200 OK, а реальный пользователь в это время видит стену с капчей.
Особенно актуально для e-commerce и SaaS, где Cloudflare и аналоги стоят почти везде. Для таких случаев стоит запускать Playwright через браузер с патченным fingerprint - иначе результаты transaction-проверок будут ненадёжными именно на тех сайтах, где мониторинг важнее всего.
Stealth-патчи — это гонка вооружений, которую мониторинг-сервис проиграет в долгую. Думаю тут стоит в такого рода проверках настраивать Cloudflare чтоб не вредничал.
Согласен, что поддерживать собственные JS-патчи для мониторинг-сервиса - это действительно гонка вооружений. Но суть в том, откуда берётся патч.
JS-патчи (puppeteer-extra-stealth и аналоги) работают поверх уже запущенного движка. Между стартом процесса Chromium и моментом, когда патч перехватывает управление, есть окно - антифрод замеряет fingerprint именно там, до загрузки вашего JS. Это и есть та самая гонка.
Если патч зашит в сам бинарник Chromium на уровне C++ до компиляции - движок просто никогда не отдаёт "нечеловеческие" значения. Нет окна, нет гонки. Видел такой подход в CloakBrowser - они именно так и сделали. Устойчиво между обновлениями, потому что детект-сигнатуры привязаны к поведению stock Chromium, а не к вашей сборке.
Вариант с "настроить Cloudflare чтоб не вредничал" рабочий, но только если сайт ваш. Для мониторинга сторонних сервисов это не вариант.
22 протокола мониторинга в PingZen: от пинга до Playwright-сценариев