Test Your Server Against the Heartbleed OpenSSL Vulnerability

April 8th, 2014
Posted in Tools, Tech

A major vulnerability in OpenSSL software was announced late yesterday, impacting all servers having the Heartbeat TLS extension enabled with OpenSSL versions states above.

The "heartbleed" vulnerability, has been already recorded as CVE-2014-0160. Further details can be found at http://heartbleed.com and https://www.openssl.org/news/secadv_20140407.txt.

The bug has already scared a lot of system administrators and site owners, and the one that we've done on WebSitePulse was to release a test against this vulnerability.

So, if you want to check whether your secure server is affected or not, please visit: http://www.websitepulse.com/heartbeat.php

Browser Full Page Test Tool Now Ready for Use

April 3rd, 2014
Posted in Tools

Not long after releasing our latest and most sophisticated monitoring level – the In-Browser Application Monitoring, we are happy to announce that it is now available as a free test tool.

So here’s a brief description of what the In-Browser level of monitoring is all about:

It simulates a real user “browser-like” experience. It is based on the Firefox “GECKO” engine and supports multiple simultaneous connections, JavaScript rendering and page component caching. The benefit is that we are able to detect performance issues connected to the code itself, the images and all other third-party embedded objects.

We developed our In-Browser Application Monitoring service further and created the Browser Full Page test that you can use at any time. This is how its main page looks like:

Click to Enlarge

To test a website URL, simply enter it in the field, click the Perform Test button and a loading animation will pop up.

Click to Enlarge

After the test is completed, a result screen will be provided:

Click to Enlarge

The tested URL and a timestamp of the test are the first things to appear on the page. An initial load screenshot is then provided as well as an option to see what the return load screenshot looks like. This is one of the unique features of the Browser Full Page test. It is initially simulating a first-time user experience and, immediately after that, a second test is performed to simulate a repeated user experience. Screenshots are then made and the collected data is reported.

Next is the WebSitePulse performance grade score that, in this case, is almost perfect – 99/100. Congratulations, Google! An information about the number of requests made and the total page size can be seen next to the score itself. First and return visit times are also displayed below.

Switching our attention to the Request Timeline below, we will notice a breakdown of all page components (3 in this case) and how long it took to load them on both the initial and return load tests. You can easily navigate through the timeline by clicking the Initial Load, Return Load and Both Combined buttons on top of the chart. Clicking the magnifying glass icons on the right will reveal the request and response headers for the selected element.

Click to Enlarge

Switching to the recommendations screen is easy - simply click the Recommendations button. Having mentioned that Google.com performed pretty well on our test, we can still hint improvements for its performance and responsiveness. Here is what we have to say for that one:

Click to Enlarge

You can also Tweet and share your results on Facebook or Google+. Or, if you still do not have an account with us, you can click the Start a FREE Trial button and set your site up for monitoring. You will get all of the functionality described above, plus tons more like several different types of alerts, takeover feature, 24/7 e-mail, chat and phone support, 40 locations around the world etc.

So, what is your WebSitePulse score?

April Fools' Day: How Website Monitoring Really Works

April 1st, 2014
Posted in Monitoring

Click to Enlarge

If you have ever wondered what we do behind the scenes while watching after your online business, you can now find out how the monitoring process really works:

We initiate an immediate error-detection process via our hideously complicated monitoring system which consists of throwing ‘heads and tails’ coin by the IT Employee on duty. Depending on what you say ‘heads and tails’ stands for, your website might be up – or might be down. This process, however, cannot be performed by an uncertified IT specialist as throwing the coin under specific angles requires years of training. The unprofessional completion of this process might result in your website being down, which then completely renders the monitoring of your website.

Why You Need Database Monitoring

March 31st, 2014
Posted in Monitoring

After your web servers, the database servers are probably the second most important part of your system and that is why it is critical that you monitor them in order to minimize their downtime. We have two database specific levels of monitoring that can help you with keep your servers up and running as close to 100% of the time as possible.

You can monitor both MySQL and MS SQL servers. We can even create custom solution for you if you have more specific database monitoring needs.

Click to Enlarge

To ensure your MySQL server accepts connections, you can use our MySQL basic level of monitoring.

Click to Enlarge

In the Basic Configuration section you can specify the target label, monitoring interval, timeout value, etc. You can also choose which of the extra services you want to use like takeover, traceroute on error, force monitoring, etc. After you have made your selections and click continue, you will go to the Advanced Settings section.

Click to Enlarge

You will be able to select the host name from the drop down menu if you have already used it for setting up other targets. If not, you will have to enter the hostname or IP address in the new host field. If you are using a port different than the default 3306, you need to change the port value as well. If you check the use of PING option, we will also ping your server on every check and you will have the ping information in the reports as well. Keep in mind that the PING packets should be allowed through your firewalls so you might need to whitelist some of our IPs. This is the basic level of monitoring and it will not provide you with a lot of detailed information. We will only alert you when your database stops accepting connections or if we are not able to reach your server, or your server responds slower than usual.

If you need a more advanced database monitoring, however, you should consider using our advanced level. The basic configuration for a MySQL advanced target is exactly the same as for the basic monitoring. There are certain differences in the advanced configuration section.

Click to Enlarge

Here we will not only open a connection to your MySQL server, but we will also log in and check some of the variables’ values of the server.

Click to Enlarge

You can check the following Status Variables:

  • Connected threads
  • Running threads
  • Opened files
  • Opened tables
  • Uptime

You can be alerted in the cases where the values are bigger or smaller than a specific number.

Click to Enlarge

Keep in mind that you have to provide us with log in credentials in order to be able to use this level of monitoring. We need access to your database server which is always a vulnerability risk. When creating the test credentials, give us only permission to access the variables which we are going to test and not the administrator access to your database.  Another good idea will be to allow access only from our IP addresses and whitelist only them.

We can also monitor MS SQL servers. There are a few small differences to the advanced configuration section of these types of targets.

Click to Enlarge

You can check for the following variables:

  • Errors
  • Running transactions
  • Opened connections
  • Database size (MB)

Once again, you can be alerted in the cases where the values are bigger or smaller than a specific number.

Accessing your database from outside your network is not the most secure option you can use. If your administrators do not want to allow access from outside your data center, there is an option which you can use and we can still monitor if your database works correctly.

All you need to do is create a script on your machine that will run some database tests and publish the results on a webpage that is accessible from the Internet. You can then use our performance level of monitoring and look for specific keywords like OK or Error on that specific website.

What's CDN Monitoring for?

March 28th, 2014
Posted in Monitoring

Most businesses now have clients from every corner of the world. Back in the day, if you had an online store, you would just host it on a dedicated server in a specific data center and focus only on clients located geographically close to that data center. If you decide to use such an option today and you have customers and partners from all over the world, it is likely that some of them will have problems loading the specific resources fast enough compared to your competitors. Such high response times might cause you a lot of problems and even revenue loss.

Handling a huge traffic volume as well as minimizing and localizing downtimes to only certain parts of the world (CDN nodes) would make you consider using CDN instead of dedicated servers hosted in a single location. Hybrid networks also exist where people use both CDN and dedicated servers for different parts of the content. 

 So, what is a CDN? CDN is short for Content Delivery Network or Content Distribution Network. The CDN nodes are located in different data hosting centers around the world with multiple backbone connections and different ISPs in order to make the whole content distribution network much more stable and downtime proof.

Most of the Internet content which is served today, actually comes from CDNs. CDNs are used to serve static and dynamic websites but its main advantages can be utilized when serving video and audio content and Internet television. Most social networks and big e-commerce portals also use mostly CDNs due to the high number of simultaneous connections they get every second.

When using a CDN, your content will be copied to multiple servers in different geographical locations. A large CDN will consist of hundreds and even thousands of different servers, all of which have copies of your content.  Your applications will not experience problems during periods of maximum load and your system will be able to deal with a huge number of simultaneous requests.

One of the best features of a CDN is that it allows a fail-safe degradation of the network in cases of Internet problems or attacks. Even if your site is under a massive DDoS attack, at least some of your clients will be able to get the correct content from the CDN nodes which are not affected. Since you have basically the same copies of that data on many servers, it can also serve as a great backup tool in case something happens to a specific CDN node and you lose data. Customization is also possible where specific content will only be displayed for specific geographical locations.

When clients request content from a CDN, they are automatically diverted to the server which is closer to them. This way the content can be delivered much faster and the routes between the machines are optimized.

The best option to monitor a CDN will be to use as many different monitoring locations as you can. We are constantly expanding our network and right now we have 40 different monitoring locations. Depending on your CDN configuration, the locations situated in different countries or continents will most likely reach different nodes of your content distribution network. You can use our test tools and do HostName tests to find out exactly which node each of our servers is hitting. If we start detecting problems only from some of the locations, this will indicate that only certain nodes are not working correctly and you should consider contacting out your CDN provider. Since using all of our 40 locations might come out too expensive, you should at least consider using several of them.

If you are experiencing problems only for a specific geographical region, you might want to monitor a specific node (by using its IP address and not the domain name) and/or using only the monitoring locations close to the specific place.

You can use most of our monitoring levels to monitor a CDN but the performance and full-page levels are the most widely used ones. You can also consider using our application and transaction levels of monitoring if you have an e-commerce site for example and you want to check that all applications are working fine as well.