WEBO Scout — все о производительности вашего сайта

В WEBO Pulsar теперь встроен новый аналитический инструмент, а по сути, отдельный продукт — WEBO Scout. Сейчас можно не только контролировать реальное время открытия страниц в браузере, но и регулярно получать сводку о текущих проблемах производительности и советами о том, как исправить ситуацию.

Для этих целей раньше служил небезызвестный сервис webo.in. К сожалению, этот сервис уже порядком устарел, да и кроме того, он строил отчеты на основе синтетических проверок, нередко допуская ошибки в оценке возможного ускорения.

WEBO Scout же оперирует реальными параметрами загрузки страниц в реальном браузере (пока это только Internet Explorer 8) и позволяет с высокой точностью узнать обо всех проблемах сайта, а также о возможном времени открытия страниц в случае ускорения сайта. Для оценки возможного ускорения мы автоматически применяем наш модуль WEBO Site SpeedUp, таким образом гарантируя максимальную точность полученного результата.

Все что нужно, чтобы получить эту информацию — перейти на страницу Отчеты в WEBO Pulsar, ввести имя сайта или страницы, которую вы хотите проверить и, выбрав нужный тип отчета, нажать кнопку Создать отчет. Отчет будет составлен в течение, буквально, пары минут, после чего будет доступен по постоянным ссылкам. При необходимости можно включить уведомления по e-mail о создании отчетов.

Типы отчетов

• Простой отчет (пример). Простая проверка времени открытия сайта с расчетом возможного ускорения — быстрые базовые цифры для тех, кто хочет получить измеряемые KPI. Подойдет для регулярного контроля скорости сайта, например, до и после проведения работ по ускорению или при смене дизайна сайта. Стоимость такого отчета минимальна и составляет около 5 рублей.
  
  
• Базовый отчет (пример). Этот отчет чуть сложнее, здесь больше технический данных: время ответа сервера из 4 точек без учета сетевых задержек, диаграмма загрузки файлов и ранжированные советы по увеличению скорости сайта. Такой отчет подойдет для более глубокого исследования проблем сайта и получения точного списка действий по ускорению сайта, причем все советы выстроены по приоритетам. Стоимость Базового отчета сейчас около 20 рублей.

В самое ближайшее время будет добавлен еще один тип отчетов — Расширенный. Включая все данные из Базового отчета он будет содержать информацию о наиболее подходящих способах реализации советов по ускорению, а также списки файлов, которые затрагиваются тем или иным советом. Этот тип отчетов появится уже в сентябре.

Планы на ближайшее будущее

У нас масса идей о том, как улучшить WEBO Scout и разделить с вами тот обширный опыт, что мы имеем в аудите и ускорении сайтов. Надеемся, что вы будете ждать обновлений WEBO Scout с тем же нетерпением, что и мы.

WEBO Scout существует совсем недолго, и мы будем рады любым комментариям по его функционалу или внешнему виду. Любые ваши высказанные соображения для нас исключительно ценны. И конечно, мы уже традиционно поощряем всех активных участников бонусными пополнениями баланса.

Вместе мы делаем сайты быстрее и надежнее!

Как измерить время ответа сервера?

Как измерить время ответа сервера? Конечно, для этого можно использовать команду ping. Но у этого способа есть два существенных минуса. Во-первых, очень часто по соображениям безопасности сервера на ICMP-пакеты не отвечают. Во-вторых, практическую ценность такое измерение имеет очень редко. В самом деле, какая посетителю разница, что ICMP-пакеты до сервера и обратно идут 20 миллисекунд, если страница с каталогом товаров все равно генерируется 15 секунд. Дальше мы покажем, как можно вычислить время отклика сервера на примере протокола HTTP с использованием библиотеки cURL.

Библиотека cURL предоставляет следующую информацию о времени выполнения операций:

• CURLINFO_REDIRECT_TIME — общее время, которое потребовалось для обработки всех перенаправлений. Каждое перенаправление в HTTP это по сути отправка запроса и получение данных. Таким образом для каждого перенаправления измерение времени лучше проводить отдельно. В дальнейшем будет предполагаться, что никаких перенаправлений не происходит (максимальное количество перенаправлений установлено в 0).
• CURLINFO_NAMELOOKUP_TIME — время, прошедшее с момента начала выполнения запроса до определения IP-адреса сервера по его доменному имени. Для URL заданных по IP-адресу сервера будет равно 0. В дальнейшем это время нас также интересовать не будет, т.к. оно может сильно зависеть от географического положения пользователя и множества других факторов, которые выходят за рамки данной статьи.
• CURLINFO_CONNECT_TIME — время, прошедшее с момента начала выполнения запроса до установления соединения с удаленным сервером (получение пакета TCP/ACK).
• CURLINFO_APPCONNECT_TIME — время, прошедшее с момента начала выполнения запроса до установления SSL-соединения (в рамках данной статьи рассматривается протокол HTTP без SSL).
• CURLINFO_PRETRANSFER_TIME — время, прошедшее с момента начала запроса до отправки HTTP-запроса.
• CURLINFO_STARTTRANSFER_TIME — время, прошедшее с момента начала запроса до получения первого байта ответа от сервера.
• CURLINFO_TOTAL_TIME — общее время выполнения запроса. Это время помимо прочего ззависит от пропускной способности канала пользователя, т.к. включает в себя время загрузки ответа сервера.

Что же из вышеперечисленного действительно представляет практическую ценность? Казалось бы, это STARTTRANSFER_TIME, но оно включает в себя все сетевые задержки. При переносе серверов или точки проверки это время может сильно измениться, но это не будет означать, что сервера стали хуже работать и дольше обрабатывать запросы пользователей.WEBO Pulsar позволяет измерять это время, и если вам интересно полное время, которое пользователь из конкретной географической зоны тратит на ожидание контента, нужно установить переключатель «Способ вычисления времени ответа» в положение «Полное время запроса» при редактировании проверки.

Временем, которое сервер затратил на генерацию ответа является STARTTRANSFER_TIME – PRETRANSFER_TIME, т.е. время, прошедшее между отправкой запроса и получением ответа. В случае с нулевыми сетевыми задержками это время и будет временем, затраченным сервером на генерацию ответа. WEBO Pulsar позволяет измерять и его. Для этого нужно установить переключатель «Способ вычисления времени ответа» в положение «Время обработки запроса сервером + время доступа».

А что же произойдет, если сетевые задержки ненулевые, как это обычно бывает? В этом случае между отправкой HTTP-запроса и получением его сервером пройдет какое-то время, например, t1. А между окончанием обработки запроса сервером и получением ответа пользователем — еще какое-то время t2. Тогда время, затраченное на генерацию ответа будет вычисляться по формуле (STARTTRANSFER_TIME – PRETRANSFER_TIME) – (t1 + t2). В случае, когда на генерацию ответа требуется значительно больше времени, чем на доставку ответа пользователю это некритично. Но если ваш сервер работает быстро и отдает ответ за 2-4 милисекунды, а сетевые задержки между серверами составляют 50 милисекунд, это может существенно повлиять на результаты проверки. Как же вычислить это самое (t1 + t2)?

В идеале для этого нужно использовать утилиту ping, которая покажет среднее RTT (round trip time — время, прошедшее между отправкой ICMP-пакета и получением ответа, которое будет очень близко к t1 + t2). Но в общем случае утилиту ping использовать нельзя, т.к. сервер может не отвечать на ICMP-пакеты. На самом деле, (t1 + t2) ~ (CONNECT_TIME – NAMELOOKUP_TIME). Почему? Потому что обычно между определением адреса сервера и установлением TCP-соединения нужно лишь отправить TCP/SYN пакет и дождаться TCP/ACK пакета.

На обработку TCP/SYN пакета тратится очень малое количество времени (иначе на сервере возникают серьезные проблемы), поэтому это время практически равно RTT. Если же в процессе установления соединения один из пакетов потерялся (на каком-нибудь из промежуточных узлов), то (t1 + t2) ~ (CONNECT_TIME – NAMELOOKUP_TIME)/2. Если потерялось 2 пакета - то делить нужно будет на 3 и т.д.

Чем больше пакетов было потеряно в процессе, тем меньше точность определения RTT. По умолчанию WEBO Pulsar определяет время ответа именно так. Если вычисленное время ответа оказалось отрицательным, это значит, что установление соединения заняло больше времени, чем обычный обмен TCP-пакетами. В этом случае, WEBO Pulsar предполагает, что для установления соединения понадобилось 2 обмена пакетами и делит (CONNECT_TIME – NAMELOOKUP_TIME) на 2. И так вплоть до 5, т.к. дальнейшее приближение уже не имеет смысла из-за сильного падения точности.

Не стоит забывать, что на любом из этапов RTT может отличаться (иногда достаточно сильно) от среднего. Получить точный результат, не имея доступа к серверу невозможно, но данный метод позволяет получить достаточно неплохие результаты. Именно этот метод, «Время обработки запроса сервером», по умолчанию использует WEBO Pulsar для всех проверок.

Проверки FTP, DNS, Ping и другие новые возможности

За прошедшие несколько недель в WEBO Pulsar появилось еще больше возможностей для проверки ваших сервисов.

Новые типы проверок

Теперь вы можете проверять ваш файл-сервер по протоколам FTP или FTPS, проверять DNS-сервер, контролируя его записи A, MX, CNAME, SOA а также проверять время отклика сервера с помощью команды Ping. Для всех новых типов проверок традиционно строятся удобные графики времени отклика, помимо этого, возможно создание детальных логов в случае недоступности проверок.

Для того, чтобы добавить проверку FTP-сервиса, достаточно указать соответствующий URL. Тип проверки можно уже не указывать: как и в случае с протоколами HTTP и HTTPS система сама определит тип проверяемого ресурса.

Если вы хотите проверять DNS, нужно выбрать соответствующий тип проверки (A, MX, CNAME, SOA) и указать контролируемый DNS-сервер, а для проверок записей A и CNAME еще и ожидаемый ответ, соответственно IP-адрес или каноническое имя сервера. Если по какой-то причине DNS-сервер будет отвечать на запросы неверно, вы сразу же об этом узнаете.

Ping — один из самых простых типов проверок, который, однако, позволяет контролировать процент потерянных пакетов. Если заданный порог будет превышен, проверка будет считаться недоступной.

Доступ к статистике ваших проверок и редактирование сайта

Это нововведение позволяет предоставлять доступ к данным ваших проверок другим пользователям WEBO Pulsar. Для того чтобы начать пользоваться этой возможностью достаточно добавить пользователей в Адресную книгу на странице Аккаунт. После этого при редактировании сайта вы сможете указывать пользователей, которые смогут просматривать ваши графики доступности.

В каких ситуациях это нужно? Например, тогда, когда вы хотите показать коллеге результаты ваших проверок, но не хотите, чтобы он имел возможность изменить или удалить какие-то проверки. Конечно, можно отправить ему HTML-отчет или скриншот, но иногда гораздо удобнее предоставить ему возможность самому получать необходимую информацию.

Кнопка редактирования сайта теперь находится там, где была кнопка удаления. Кстати, помимо настроек доступа теперь можно изменить название вашего сайта. Если же у вас есть права только на просмотр проверок, то вместо иконки редактирования вы увидите иконку замочка. Сами проверки изменить, конечно же, тоже будет нельзя.

Другие запланированные нововведения

Мы в WEBO Software неустанно трудимся для вас, и к Новому Году планируем еще несколько полезных возможностей. Совсем скоро в WEBO Pulsar вы сможете:

• создавать проверки по почтовым протоколам SMTP, POP3, IMAP,
• получать по электронной почте подробные еженедельные или ежемесячные отчеты о результатах всех ваших проверок,
• доставлять уведомления о недоступности проверок любым людям из вашей адресной книги.

Следите за новостями. И конечно, мы всегда рады любым вашим отзывам о нашем сервисе.

Диагностика проблем с доступностью

WEBO Pulsar может не только сообщать о проблемах с веб-ресурсом, но и давать дополнительную информацию, которая поможет диагностировать и быстрее устранить эти проблемы.

Между WEBO Pulsar и проверяемым веб-ресурсом могут находиться десятки промежуточных узлов и проблемы могут возникнуть на любом из них. Может быть недоступен маршрутизатор магистрального провайдера, может не работать коммутатор в дата-центре, а может быть отключен сетевой интерфейс на самом сервере. Каждая из этих ситуаций требует соответствующей диагностики.

В первую очередь нужно определить на каком уровне модели OSI и на каком узле возникли проблемы. После этого можно предпринять соответствующие шаги для ее решения.

Уровни, на которых могут возникать проблемы

На 5, 6 и 7 уровнях модели OSI диагностические возможности удаленного сервера довольно ограничены. Тем не менее, если соединение с проверяемым ресурсом по соответствующему протоколу было установлено, но по каким-то причинам ответ веб-ресурса отличается от ожидаемого, то можно с уверенностью сказать, что проблема находится на самом проверяемом сервере, и что она возникает на верхних уровнях модели OSI. Дополнительная информация, которую может получить удаленный сервер, будет зависеть от конкретного используемого протокола. Например, для протокола HTTP это будут переданные HTTP заголовки.

Для диагностики ошибок на 1-4 уровнях (а также диагностики ошибок DNS, хотя это и 7й уровень модели OSI) в первую очередь удаленный сервер должен определить, не возникли ли проблемы у него самого. Например, может быть недоступен его DNS-сервер или отключен коммутатор в дата-центре.

Самодиагностика WEBO Pulsar

Для самодиагностики сервис WEBO Pulsar использует набор контрольных точек, среди которых и сервера WEBO Software и просто общедоступные ресурсы с высоким процентом доступности. Недоступность одной из контрольных точек и доступность всех остальных еще не является поводом для поиска проблем на самом сервере WEBO Pulsar. Но недоступность нескольких контрольных точек уже является серьезным поводом для беспокойства. Разумеется, контрольные точки должны быть размещены в различных сетях, а еще лучше в разных странах. Кроме того контрольные точки желательно задавать с использованием доменного имени, а не IP-адреса. Это позволит одновременно убедиться и в том, что DNS-сервер доступен и работает корректно.

Если контрольные точки доступны, то искать проблему нужно в другом месте.

Диагностика проблем с определением IP-адреса сервера

1. На всякий случай проверим еще раз, доступен ли DNS-сервер с помощью telnet, nmap, ping или любой другой подходящей утилиты.
   
   
   webo@pulsar# nmap -p 53 192.168.1.1
   
   
   Starting Nmap 5.00 ( http://nmap.org ) at 2010-09-29 15:27 MSD
   Interesting ports on 192.168.1.1:
   PORT   STATE SERVICE
   53/tcp open  domain
   
   
   Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds
   
   
2. Попробуем получить NS запись для проверяемого домена.
   
   
   webo@pulsar# nslookup -q=NS webo.in
   Server:                   192.168.1.1
   Address:               192.168.1.1#53
   
   
   Non-authoritative answer:
   webo.in  nameserver = dns1.webdrive.ru.
   webo.in  nameserver = dns2.webdrive.ru.
   
   
   Authoritative answers can be found from:
   dns2.webdrive.ru internet address = 212.158.162.5
   dns1.webdrive.ru internet address = 213.189.213.54
   
   Здесь мы видим две NS-записи для проверяемого домена: dns1.webdrive.ru и dns2.webdrive.ru. Дальше будем диагностировать уже их. Но возможен и другой вариант.
   
   
   webo@pulsar# nslookup -q=NS www.webogroup.com
   
   
   Server:                   192.168.1.1
   Address:               192.168.1.1#53
   
   
   Non-authoritative answer:
   www.webogroup.com        canonical name = cs78.ngenix.net.
   
   
   Authoritative answers can be found from:
   ngenix.net
                   origin = ns.ngenix.net
                   mail addr = noc.ngenix.net
                   serial = 1285244204
                   refresh = 28800
                   retry = 7200
                   expire = 604800
                   minimum = 86400
   
   В этом случае доменное имя является синонимом другого имени. В качестве доменного имени теперь следует использовать cs78.ngenix.net, а в качестве nameserver — сервер ns.ngenix.net.
   
   Если же ни одной NS или CNAME-записи получить не удалось, то проблема локализована. Скорее всего, домен не делегирован. В первую очередь нужно проверить сроки делегации домена и NS-записи для него.
   
   
3. Если же проблема по-прежнему не локализована, попробуем определить IP-адреса обнаруженных NS-серверов.
   
   
   webo@pulsar# nslookup ns.ngenix.net
   
   
   Server:                   192.168.1.1
   Address:               192.168.1.1#53
   
   
   Non-authoritative answer:
   Name:     ns.ngenix.net
   Address: 93.93.93.93
   
   Если на этом шаге не удается определить IP-адреса ни одного из NS-серверов, то проблема локализована.
   
   
4. Последнее, что можно сделать — проверить доступность самих NS-серверов, убедиться, что на них доступен 53 порт и работает служба DNS. Разумеется, проверять это имеет смысл только для тех NS-серверов, для которых удалось определить IP-адрес.
   
   
   webo@pulsar# traceroute -T -n -p 53 93.93.93.93
   traceroute to 93.93.93.93 (93.93.93.93), 30 hops max, 56 byte packets
    1  192.168.1.1  1.265 ms  2.230 ms  2.693 ms
    2  212.5.114.1  12.918 ms  13.080 ms  13.100 ms
    3  87.118.210.201  13.068 ms  14.752 ms  14.751 ms
    4  87.118.192.170  14.782 ms  14.806 ms  14.833 ms
    5  195.128.64.74  15.538 ms  15.570 ms  15.596 ms
    6  217.150.38.58  15.626 ms  15.596 ms  14.668 ms
    7  217.150.45.142  153.807 ms  143.696 ms  143.542 ms
    8  193.232.226.22  15.875 ms  15.867 ms  14.312 ms
    9  78.41.104.133  9.346 ms  9.324 ms  9.136 ms
   10  93.93.93.93  9.743 ms  9.424 ms  9.389 ms
   
   
   webo@pulsar# nmap -n --max-retries 4 -PS53 -p53 -PN 93.93.93.93
   
   
   Starting Nmap 5.00 ( http://nmap.org ) at 2010-09-29 16:51 MSD
   Interesting ports on 93.93.93.93:
   PORT   STATE SERVICE
   53/tcp open  domain
   
   
   Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
   
   
   webo@pulsar# nslookup cs78.ngenix.net 93.93.93.93
   Server:                   93.93.93.93
   Address:               93.93.93.93#53
   
   
   Name:     cs78.ngenix.net
   Address: 78.41.104.43
   
   Таким образом, мы можем понять, на каком этапе определения IP-адреса возникают проблемы. Конечно же, никто не гарантирует, что проблема только в определении IP-адреса. Одновременно с этим сам сервер может быть отключен или вообще уничтожен. Но это уже другая проблема.
   

Определяем проблемы на промежуточных узлах

Для нижних уровней модели OSI все несколько сложнее.  Эти проблемы проявляются в виде ошибок libcurl, таких как CURLE_COULDNT_CONNECT (7), CURLE_OPERATION_TIMEDOUT (28), CURLE_SEND_ERROR (55) и CURLE_RECV_ERROR (56).

Часто тут можно определить лишь проблемный узел, но не уровень, на котором возникли проблемы. Для удаленного сервера поврежденный кабель между маршрутизаторами и неправильная маршрутизационная таблица могут выглядеть одинаково. Так что в этом случае остается только одно — провести трассировку маршрута с помощью утилиты traceroute. Желательно это сделать в двух режимах: ICMP и TCP/UDP.

webo@pulsar# traceroute -I -n -w 1 90.156.236.74

traceroute to 90.156.236.74 (90.156.236.74), 30 hops max, 60 byte packets

 1  192.168.1.1  1.223 ms  2.218 ms  2.670 ms

 2  212.5.114.1  12.247 ms  12.409 ms  12.439 ms

 3  87.118.210.201  12.476 ms  12.461 ms  12.479 ms

 4  87.118.192.170  20.665 ms  21.333 ms  21.265 ms

 5  195.128.64.74  12.982 ms  13.013 ms  13.039 ms

 6  213.248.78.137  13.099 ms  13.054 ms  12.191 ms

 7  80.239.147.162  22.916 ms  16.435 ms  16.386 ms

 8  80.91.246.236  39.007 ms  39.109 ms  39.393 ms

 9  80.91.249.12  55.362 ms  54.684 ms  55.056 ms

10  80.91.248.210  64.924 ms 80.91.245.183  65.895 ms 80.91.250.134  67.018 ms

11  80.91.253.169  64.177 ms  60.169 ms  59.514 ms

12  80.91.248.246  60.393 ms  59.764 ms  58.733 ms

13  213.248.88.198  58.672 ms *  59.229 ms

14  85.17.100.206  60.203 ms * *

15  * * *

16  * * *

17  * * *

webo@pulsar# traceroute -T -n -w 1 -p 80 90.156.236.74

traceroute to 90.156.236.74 (90.156.236.74), 30 hops max, 56 byte packets

 1  192.168.1.1  1.467 ms  2.219 ms  2.751 ms

 2  212.5.114.1  12.093 ms  12.144 ms  12.137 ms

 3  87.118.210.201  12.413 ms  12.425 ms  12.455 ms

 4  87.118.192.170  14.811 ms  14.738 ms  14.756 ms

 5  195.128.64.74  14.761 ms  14.779 ms  14.808 ms

 6  213.248.78.137  17.571 ms  17.310 ms  16.583 ms

 7  80.239.147.157  35.097 ms  29.924 ms 80.239.147.162  17.601 ms

 8  80.91.245.51  42.147 ms 80.91.246.236  40.269 ms 80.91.245.51  43.361 ms

 9  80.239.147.170  56.170 ms  55.182 ms *

10  * * 80.91.253.169  49.680 ms

11  80.91.253.167  60.822 ms *  60.067 ms

12  * 213.248.88.198  46.373 ms  45.933 ms

13  213.248.88.198  56.737 ms 85.17.100.206  46.183 ms  48.199 ms

14  85.17.100.206  59.943 ms 95.211.18.1  49.014 ms 85.17.100.206  56.945 ms

15  90.156.236.74  45.956 ms 95.211.18.1  56.781 ms  57.720 ms

Как видно, трассировки ICMP пакетами было бы недостаточно, т.к. на ICMP пакеты сервер не отвечает. Дополнительная трассировка с помощью TCP пакетов на 80 порт помогла установить, что сервер все-таки доступен.

Подводим итоги

Итак, диагностика проблем подразделяется на 3 основных вида: диагностика проблем с DNS, диагностика проблем на верхних уровнях модели OSI и трассировка маршрута к серверу. В зависимости от результата проверки WEBO Pulsar выбирает подходящий вариант и автоматически проводит дополнительные исследования (если включена опция «Создавать детальный лог при недоступности»). Результаты можно увидеть в личном кабинете или в уведомлении по e-mail. Это поможет быстрее понять, где именно возникла проблема, кто и как будет ее решать. В случае проблем на сервере работы прибавится администратору сервера, в случае проблем в датацентре нужно срочно связаться с техподдержкой, а в случае проблем у магистрального провайдера нужно успокоиться и подождать — от нас с вами в таких случаях мало что зависит.

Все о дополнительных проверках

Вы наверняка обратили внимание на возможность задания дополнительных проверок для разных типов уведомлений. Сегодня мы расскажем о том как применять их наиболее эффективно.

Вне зависимости от типа и частоты, дополнительные проверки всегда выполняются с интервалом в одну минуту и производятся автоматически при наступлении любого проблемного события, будь то недоступность какого-то веб-ресурса или превышение его времени ответа. Число таких проверок может быть в пределах от нуля до пяти, но что действительно важно — все дополнительные проверки выполняются абсолютно бесплатно.

Основное назначение дополнительных проверок — не допустить отправки соответствующих уведомлений, если возникшая проблема носит кратковременный характер.

Например, вы можете использовать услуги виртуального хостинга и знать что время ответа вашего сайта периодически может достигать пиковых значений. При этом появление этих пиков может быть обусловлено не проблемами самого сайта или его неравномерной нагрузкой, а нестабильной работой вашей хостинговой площадки.

В такой ситуации дополнительные проверки удобно использовать в качестве фильтра, чтобы получать уведомления только тогда, когда время ответа превышает заданный порог в течение нескольких минут подряд. В противном случае вы рискуете получать на почтовый ящик по письму в час.

Если рассматривать случай, приведенный на скриншоте, то точная хронология событий для проверки может выглядеть следующим образом (пусть это будет проверка HTTPS/POST, раз в 10 минут):
...
16:25 — время ответа превышено (следующая проверка запланирована на 16:35)
16:26 — производится первая дополнительная проверка, проблема подтверждается, отправляется уведомление по e-mail
16:27 — производится вторая дополнительная проверка, проблема подтверждается
16:28 — производится третья дополнительная проверка, проблема не подтверждается (проблема носила краткосрочный характер, не требует срочного вмешательства, а значит и лишнего расхода на срочную отправку СМС)
16:35 — производится очередная плановая проверка
...

Считаете, что пяти дополнительных проверок недостаточно? Есть какие-то предложения о том, как улучшить концепцию использования таких проверок? Мы с радостью примем ваши комментарии и предложения.

Знакомство с WEBO Pulsar

В этом блоге мы будем рассказывать о нашем новом сервисе WEBO Pulsar. Отсюда вы узнаете об особенностях его работы, о новых и только запланированных возможностях и многом другом. Но для начала пара о самом сервисе. Итак, какие возможности предоставляет наш сервис? Какие проблемы он помогает решить?

Основная задача WEBO Pulsar — контроль за доступностью ваших сайтов и веб-сервисов. Он выполняет проверки заданных URL с определенной вами частотой (от одной проверки в минуту до одной проверки в сутки) по протоколам HTTP, HTTPS. В ближайшем будущем появится поддержка протоколов SMTP, IMAP, MySQL и ряда других. Поддерживаются проверки методами HEAD, GET и POST. Последняя дает возможность контролировать результат отправки формы, т.е. например, результат добавления товара в корзину или входа в персональный аккаунт.

Но мало толку от проверки сайта, если об обнаруженных проблемах нельзя своевременно узнать. Мы выделяем несколько типичных проблем: недоступность веб-ресурса, превышение времени ответа, отсутствие указанного текста в ответе. При возникновении любой из перечисленных проблем сервис может рассылать уведомления по e-mail, sms, jabber (к этому списку скоро добавятся уведомления через twitter). WEBO Pulsar бережно хранит всю собранную статистику и позволяет получить эту статистику за любой день, за весь период проверок. С точностью до каждой единичной проверки. Статистика отображается на масштабируемых графиках, а также может быть в один клик выгружена в форматах CSV или HTML.

Одним из наших приоритетов при создании сервиса было обеспечение минимальной стоимости проверок, для того, чтобы найти применение сервису могли все, от студентов до крупных организаций. И с этой задачей мы пока справляемся, взгляните на наши цены. Вы можете быть уверенным в доступности своего интернет-магазина всего за 12 рублей в месяц. Это при регулярных проверках с частотой раз в десять минут. За такие деньги вы не везде бутерброд купите. Если же вам требуется контроль целого парка веб-сайтов, у нас тоже есть для вас решение. Мы заключаем договора на обслуживание компаний, предоставляем нотариально заверенные подтверждения доступности (и недоступности тоже).

Если у вас еще нет аккаунта WEBO Pulsar, зарегистрируйтесь прямо сейчас и вы беслатно получите на счет средств, в размере достаточном для нескольких недель проверок.

Возникла необходимость в новой фиче? Не удобен интерфейс? Есть вопросы по поводу ваших проверок? Присылайте ваши вопросы и предложения почтой, в комментарии или через сервис Реформал (вы ведь наверняка уже заметили кнопку Оставьте ваш отзыв, в самом сервисе?). Мы всегда рады вашему участию.