We recently worked with a client to troubleshoot issues with a SQL Server instance. The client was running SQL Server 2012 on a Virtual Machine. The applications running on the SQL Server were running into issues and the client was unsure what the root cause of the issues was. Initially,
I have fielded several interesting questions recently about how our monitoring systems work, some of them asking if we can monitor very specific technologies. The short answer is generally, yes- if it is online and can be reached either outside of your firewall via our dozens of monitoring locations, or
Over time, the number of tools used to manage a businesses IT infrastructure can grow into an unwieldy set of utilities, programs and services with an unmanageable list of quality and performance reports. Because of this, many small and medium businesses are looking for a simple all-in-one solution to fit
In a recent report by IDC titled, “DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified,” the cost of downtime was explored across Fortune 1000 organizations. The numbers they arrived at may surprise you. The average cost of application downtime among fortune 1000 companies was estimated at somewhere between 500,000 and 1 million dollars per hour! The total cost of downtime per year was estimated to be between 1.25 billion and 2.5 billion dollars per year.
The Visual Traceroute Tool maps each hop along a traceroute, and graphically calls out dropped packets and unresponsive nodes. It also allows you to drill down into errors and visualize traceroutes from different locations on a hop by hop basis. The best way to explain how this works is to show you an
As the internet continues to grow exponentially, we see organizations relying on a great number of devices to support higher and higher standards of uptime and performance. With the release of MetricsView Performance Counter Monitors and SNMP Monitoring Agents, Dotcom-Monitor provides complete website performance monitoring solutions to give you insight
Dotcom-Monitor now offers a dedicated IPv6 monitoring location, which means that tasks being monitored from this location will not be able to resolve traffic across an IPv4 network, so if the communication cannot travel across an IPv6 compatible network, this location will return a failed monitoring result.
Now you can test IPv6 connections specifically from an “IPv6 only” location to ensure that your services are accessible via IPv6 only nodes. This is useful for testing IPv6 specific resolution because there are configurations available on different networking devices that may allow traffic between IPv4 and IPv6 nodes that will not work with IPv6-Only nodes. For example, it is possible that you may have a router on one end of the communication that attempts to send IPv6-Only traffic using a tunneling mechanism to tunnel IPv6 through an IPv4 only network while the router on the other end is not capable of extracting the IPv6 address from the IPv4 tunneled data.
Utilizing an IPv6 location also allows you to ensure that any APIs you use are capable of handling IPv6 communications. The IPv6 monitoring location will let you know if your application is not IPv6-aware by triggering an alert when the application is unable to respond.
Voice Connectivity is Critical. Your phone systems have gone down and you are unable to communicate with your customers. After several hours of troubleshooting you have managed to get the services up again but what do you do now? Whether you utilize a SIP based VoIP system, digital voice over T1 lines or POTS (plain old telephone service), those voice services need to be available.
How Often are You Asked “Is the Website Down?” Such calls can lead to hours of lost time only to find out it was a minor issue for a limited user base. Do you have the tools in place to proactively detect and deal with such issues?
The new DNS caching features at Dotcom-Monitor allow you to perform some interesting tests that show how DNS caching can affect your page load speed.
We realize that many organizations monitor their online services with a number different goals in mind, and so we listened to the feedback we received that some users want to include the DNS response time in their monitoring and some users want to be able to remove DNS response from their monitors.
How you wish to handle DNS response time in regard to your monitoring needs is up to you, but we want to take this opportunity to show the differences in how DNS response time affects website load using our new tools.
We ran a test monitoring YouTube from a single location in the midwest United States with three different DNS cache settings. A basic HTTP full page load on the YouTube front page resulted in some interesting, although not that surprising results.
Keep in mind the results will vary depending upon a number of variables such as which locations you are monitoring from, the time of day, the load on the DNS servers, and on the website servers.
© 1998-2024 Dotcom-Monitor, Inc. All rights reserved.
