Monitoring databases in large, distributed or hybrid environments
If you have your database servers distributed in multiple locations or networks they will often be behind separate firewalls. In addition you often have limited bandwidth or slower response time (round-trip time). Opening ports in the firewall for each and every instance you want to monitor is cumbersome and should be avoided from a security perspective.
If you have a large number of servers to monitor you run into scalability issues. There is an upper limit on the number of simultaneous connections you can have from a single monitoring server, it will have a finite number of cores and memory and too many monitoring connections can create network contention and a storage bottleneck if you try to collect and store monitoring data from too many servers at the same time
Lack of redundancy. The bigger and more complex the environment, probably the bigger the need for redundancy in monitoring servers as well as the database servers themselves
In many enterprise networks you are likely to encounter several, sometimes all of the above challenges. We find these kind of challenges common, especially in larger managed service providers (MSP) and hospital/healthcare groups. So we started to work on resolving these issues about 8 years ago, delivered the first solutions 6 years ago and have been refining and extending these ever since.
But lets be honest – we have not been good at telling our customers about this, it has been a well kept secret for all but a small group of our larger customers.
In the dbWatch database monitoring solution we have the possibility to deploy any number of dbWatch servers. Each of these servers have the following properties:
On windows, we can monitor 250 instances, on a linux platform 500 instances
The server will handle all status checks
The server triggers scheduled maintenance and statistics collection tasks
The server will cache the most recent status and stats for all the local servers
The dbWatch monitor (this is the dbWatch UI application) can connect to one or more dbWatch servers simultaneously.
In most smaller installations there will be only one dbWatch server. This server connects to all the instances that are being monitored. The dbWatch keeps an open connection to all the servers.
The dbWatch monitor connects to the dbWatch server.
When we get to more complex environments, where you have multiple locations, or subnets with database servers hidden behind firewalls, we can add more dbWatch servers. We put these additional dbWatch servers behind the firewall or in location where the instances to be monitored are located.
By using multiple dbWatch servers we get a number of benefits:
The monitor has a single connection through the firewall to the dbWatch server. This keeps number of open ports in the firewall at a minimum.
The local dbWatch server maintains the connections to all the local instances, and triggers the monitoring and maintenance tasks locally.
Network traffic between the dbWatch monitor and the local dbWatch server will only take place when the status of a local server changes, or when you run dashboards or reports on the local servers from the dbWatch monitor. This will keep network traffic to a minimum.
We can scale up to monitor almost any number of instances by adding more dbWatch servers
In the dbWatch monitor you always get the complete overview or can drill down into any instance, regardless of which dbWatch server it is connected to.
If the connection to any dbWatch server is lost, the other servers and connected instances are still available in the monitor. This adds to overall redundancy and system robustness.
when autoscanning for new instances, we can do this inside the local network or location from the local dbWatch server. Scanning for instances from outside the firewall is not desirable, and often impossible.
Over the last 10 years we have developed a range of technologies and methods to safely and efficiently monitor sql instances in distributed locations and in diverse networks behind firewalls. This is a common scenario in healthcare, managed service providers and large enterprise in general. Today we consider this a proven and common mode of operation and is frequently used by many customers.
