Uptime Uptime is the period of time when a site performs well.

Uptime corresponds to the time when a site is accessible from the Internet. The opposite term - downtime - shows for how long a site has not been working during specified period of time. Usually uptime is measured in percents, and for period of time is choosen year. Percents over the year could be easily transformed into time values. Some typical values of uptime and corresponding period of unavailability during the year are shown here:

90% - 876 hours

99% - 87 hours, 36 minutes

99.9% - 8 hours, 45 minutes, 36 seconds

99.99% - 52 minutes, 34 seconds

So high uptime is really important. Even if it seems that 99% is pretty high value - it corresponds to several days of failure. If that happens in a row, many clients can be lost. Uptime value is usually guaranteed by web hosting, where the site is hosted. Website Monitoring may help you to increase the uptime and check if the value, declared by the hosting company, is real.

  • CM.Glossary.WebsiteMonitoring
  • CM.Glossary.Downtime
  • CM.Glossary.WebHosting
  • CM.Glossary.Availability
more glossary
"Really amazing Service, congratulations."
- W.
Host-Tracker under Windows Azure

Those, who actively involved with the Web, should know HostTracker, a company from Ukraine, which has been supporting one of the leading global web monitoring services since 2004. Its goal is to monitor site health and accessibility in near-real-time access. Using alert message system, HostTracker allows to reduce downtimes, to improve quality of service for users, to quickly localize troubles...

​Those, who actively involved with the Web, should know HostTracker, a company from Ukraine, which has been supporting one of the leading global web monitoring services since 2004. Its goal is to monitor site health and accessibility in near-real-time access. Using alert message system, HostTracker allows to reduce downtimes, to improve quality of service for users, to quickly localize troubles, and etc.

Architecturally, HostTracker includes a server-based hub, acting both as a data collector and control center, and a series of software agents, launched in various regions – typically using the equipment operated by major providers, hosters and affiliates. The geographically distributed architecture provides common system reliability and also allows collecting data in terms of access speed, bandwidth and other key performance characteristics on regional level – a critically important feature for the international business.

The first version of HostTracker, which is still functioning and providing services for tens of thousands of customers, was Linux based. Today, it is supported by nine control servers, located and organized in two DPCs on collocation principle, and few dozens of agents. Considering that the final objective of web monitoring is focused on increasing the uptime of client-based web resources – whereas 95% of HostTracker customers were able to increase it up to 99% – then, performance and accessibility of the service itself are not just critical, but rather fundamental parameters that influence the whole business. Theoretically, HostTracker should demonstrate accessibility close to 100%. However, an extensive growth of the service made this task hard to solve.

HostTracker was facing constantly increasing network traffic – a problem for seamless operation of the service. Inability to add new control servers on-the-fly, difficulties when maintaining not uniform and multiple-aged hardware was another limiting factor. Moreover, the desire to develop the service through wider protocol and network service support was meeting certain obstacles. “Unfortunately, for Linux there was a limited choice of ready-to-use solutions and libraries, while inventing something completely new was difficult”, says Artem Prisyazhnyuk, HostTracker director. “We had an idea of reviewing the stack of technologies we used for a more sophisticated one and after taking a closer look at the .NET platform, its potential in terms of scalability and network support, I realized that was exactly the thing we had been looking for.”

It was sure that migrating to a completely different platform should be a complex task – the project extended over three years. However, it was like blessing in disguise: during this period, the world has seen the cloud computing that seemed an ideal tool for solving both the scalability problem and putting aside one’s own whole infrastructure. Besides, the PaaS model allowed to remove most of the effort in terms of administering the solution and to control the application as a self-contained entity, to the extent of complete automation, and thus, Windows Azure had in fact no alternatives.

As a result, the second version of HostTracker, commercial operation of which started in May 2012, is already functioning under Windows Azure. Its central ingredient is realized as Web Role and associated with SQL Azure Database – it provides external portal, analytics and report generation, control of monitoring applications. The latter are ensured with instances of Worker Role, which also use SQL Azure Database to store their data and to provide the service scalability depending on the network loading. Agents are functioning as they did before, with the viability of their transfer to Windows Azure being considered.
Now, HostTracker uses HTTP/HTTPS and ICMP protocols to monitor specific ports, including various methods (HEAD/POST/GET), and etc.

Alarm reporting is available via email, SMS and instant messages. The customer can receive reports with statistics about resources being controlled and their performances. You can spend only 6 minutes to make monitoring settings for five sites, while the average response time in case of failure is limited by a couple of minutes, and it takes 1-3 minutes more to inform the customer about the problem. Using this service, anyone can check any site, including access from various regions.

 As a result, if on the one side the transfer to the .NET platform itself gave us the potential to modernize HostTracker, to optimize the application architecture and realize new internal functions, then, on the other side, the migration to the cloud allowed to refuse from less important, though time consuming activities such as administering the solution, and, first of all, to reach necessary performance indicators. Microsoft, for all basic Windows Azure services, declares 99,9% accessibility and guarantees monthly refunds, should this indicator be lower. This creates a firm ground for operating such services like HostTracker, as the accessibility is the most critical parameter for these applications. Using the cloud infrastructure also provides a better protection for the service: unauthorized access to the application and many types of attacks are effectively excluded, while the data safety is ensured by triple reservation.

HostTracker received another advantage from abandoning its own infrastructure. The service’s performance characteristics are also rather critical, for they directly affect the failure reporting system operation. In this respect, Windows Azure is virtually a drainless source of computing power. This means that by timely starting additional monitoring instances you can support HostTracker functioning parameters on the necessary level. Moreover, the cloud environment is exactly what you need in order to make this process almost fully automatic, excluding further need for direct control.

more blog
Thank you for feedback!
Sign In
Sign Up
Prices & packages
Our monitoring network
Home > Blog
Що таке DNSBL і як туди не потрапити (Українська)

DNSBL - це чорні списки доменів та IP адрес. В даній статті ви дізнаєтесь що вони собою представляють, за які «провинності» туди можна потрапити і які можуть бути наслідки цього. Ну і, звісно, як цей «доблесний» список покинути за допомогою сервісу моніторингу сайтів ХостТрекер.

DNSBL - це чорні списки доменів та IP адрес. В даній статті ви дізнаєтесь що вони собою представляють, за які «провинності» туди можна потрапити і які можуть бути наслідки цього. Ну і, звісно, як цей «доблесний» список покинути за допомогою сервісу моніторингу сайтів ХостТрекер.

Навіть цілком «пристойні» з боку закону сайти нерідко опиняються у вкрай неприємній компанії, зокрема, в одному списку зі спамерами, шахраями та інтернет-шахраями. При цьому весь цей час власник свято може бути впевнений, що його ця доля у будь-якому разі омине або що він не має ніякого відношення до даного роду проблем. Відповідно, дізнається він про таку проблему дуже нескоро, а трапитись вона все ж таки може.

Приклад (випадковий безкоштовний проксі):

При цьому, якщо натиснути на якесь конкретне посилання, то можна дізнатися про причину блокування:

Тобто цей поштовий сервер має неправильні налаштування, або ж вже є «зламаним». Також за іншими посиланнями можна виявити й інші причини: він вже є джерелом чийогось спаму. Але постає питання, як і чому можуть зазначатися різні причини? На що саме звертають увагу укладачі DNSBL-списків?

Як і чому?

Отже, в DNSBL потрапляють доменні імена Та/Або IP адреси. Орендарі віртуальних хостингів із загальним пулом IP адрес вже рознервувались, чи не так? Але неперебірливість хостингу до клієнтів не єдина причина можливого блокування. Списки складаються за таким ось критеріям:

Підозріла активність поштового сервера. У чому саме ця підозрілість проявляється? Свій список DNSBL може створити кожен, заклавши туди нарівні з експертною думкою і досвідом, свої суб’єктивні критерії відбору. Це може бути просто інтенсивність розсилки листів, або щось більш цікаве - розподіл її в часі, використання повторюваних списків розсилки тощо. Чимало хостерів середньої ланки, що пропонують своїм клієнтам послуги вбудованого поштового сервера, вже давно є, так би мовити, закоренілими учасниками цих списків. Тому використовувати такі сервери у своїй діяльності не рекомендується.

Поштові сервери з неправильною конфігурацією. Критерії відбору постійно змінюються, тому поштовхом до блокування може бути навіть відсутність чого-небудь важливого в налаштуваннях (на думку укладача чергового списку DNSBL), наприклад, відкриті порти або ризик вразливості ОС на даному сервері.

Скарги клієнтів. Так-так, якщо ви десь натиснули «поскаржитися», «відписатися» тощо, і навіть відразу про це забули - ваші зусилля і нерви не залишились непоміченими.  Адже цілком можливо, що саме ваші негативні відгуки повпливали на «новий» статус чийогось ресурсу.

Проксі, а особливо ті, які дозволяють анонімне використання. Тут теж у кожного свої критерії. Хтось вже за анонімність може забанити.

Чого ж Вам варто боятися

Списків DNSBL дійсно велика кількість. Деякі з них за роки існування отримали вагомий вплив на інтернет-користувачів та хороший рейтинг. Однак головним критерієм все ж залишається практичність. Якщо список дійсно дозволяє відфільтрувати спам або інші небажані дії - різноманітні сервіси починають його використовувати. І наслідки потрапляння туди можуть бути катастрофічними - перестають приходити листи або ж вони автоматично потрапляють у спам, відвідувачам постійно вискакують застереження про шахрайство, сайт зникає з якихось каталогів, куди він раніше був включений і т. д. Результат, як правило, один - сайт втрачає не тільки свої позиції у пошуковій видачі, а й частину своїх клієнтів. І чим в більшій кількості списків він з'являється - тим відчутніший цей негативний вплив. Якщо провина велика - то справа набуває серйозного характеру, проте швидко відстежується і виправляється. Якщо ж ні, сайт може роками висіти в декількох списках і стабільно щось «втрачати». Важко сказати, що і в якому випадку гірше - як кому подобається. Так що

Краще туди взагалі не потрапляти!

Ну або швидко звідти вибиратися, якщо все ж таки опинилися там. Гарантії непотрапляння вам ніхто і ніколи не зможе дати, але можна регулярно перевіряти ці списки, адже, як відомо, береженого Бог береже. І, звичайно, можна це робити автоматично. При чому, абсолютно безкоштовно. Ну, а для постійних клієнтів є окрема функція, яка буде пильнувати за ім'ям та адресою сайту на постійній основі і сповістить вас одразу, як лиш трапиться щось на кшталт вищеописаного.

Вибираємося з «ями»

Виявивши себе у DNSBL-базі, головне відреагувати швидко: чим менше часу сайт проведе в списку, тим менша ймовірність проблем. Поки ніхто з цим списком не синхронізувався. Зазвичай, є можливість видалити запис автоматично. Достатньо пройти «антиботову капчу» і пильно слідувати інструкціям. Ось тут просто потрібно зайти на певну сторінку з конкретної адреси:

У деяких випадках потрібно написати листа. Але зусилля в будь-якому разі будуть затрачені менші, ніж при ліквідації наслідків. Так що радимо завжди тримати руку на пульсі. Але власне кажучи, це все має робити хостинг…

ХостТрекер розробив цю функцію, коли сам потрапив у подібну халепу, тому рекомендуємо вчитися на наших помилках. Нагадуємо, ми завжди раді будь-яким цікавим пропозиціям і зауваженням.

Send to Twitter Send to Facebook Send to LinkedIn
HostTracker blog HostTracker page on Facebook