
Комментарии 4
А если не хватит какой-то функции
Собственно, на первый взгляд, больше всего не хватает функционала "локации", потому что доступность публичного сервиса надо измерять минимум с двух (а лучше трех) удаленных друг от друга локаций: Если сервис "недоступен в Москве" - это далеко не всегда значит что он недоступен в Новосибирске (и наоборот)
Ну в рамках одной страны наверняка результаты будут идентичными по доступности и недоступности.
И я вот мониторю Инстаграм

и тут есть намёк что недоступен он может быть только из РФ
в рамках одной страны
не факт. Все таки чеки ходят через интернет, а там набор провайдеров со своими проблемами. Даже у самих PingZen могут быть проблемы с доступом в интернет из того датацентра где они чеки гоняют - а вам прилетит алёрт, что у вас сервис недоступен.
Много лет жил на пингдоме где собственно и есть механика, что недоступность должна быть подтверждена из другой локации - иначе алерт о недоступности не шлём. При этом другой сервис (монитис) имел какие-то проблемы с логикой такого алерта, и когда у него фейлилось на одной ноде - алерт прилетал, несмотря на то что проблемы часто были у того датацентра где размещена чекер (или вообще даже у самого чекера!)
Transaction-мониторинг интересная идея, но на практике есть один нюанс, который легко упустить: headless Playwright из коробки имеет характерный fingerprint, и многие сайты его обнаруживают. В результате сценарий «проходит», страница открывается, форма видна, но сайт отдаёт другой контент, показывает капчу или просто блокирует сессию. Монитор видит 200 OK, а реальный пользователь в это время видит стену с капчей.
Особенно актуально для e-commerce и SaaS, где Cloudflare и аналоги стоят почти везде. Для таких случаев стоит запускать Playwright через браузер с патченным fingerprint - иначе результаты transaction-проверок будут ненадёжными именно на тех сайтах, где мониторинг важнее всего.
22 протокола мониторинга в PingZen: от пинга до Playwright-сценариев