Today we’ll talk about how you can create different types of network monitoring targets for the network monitoring sensors (Beez). A network monitoring target defines a resource, service, or application that needs to be continuously tested for availability and performance.
Example of Network Monitoring Targets
Here are some of the types of network monitoring targets we identified:
- DNS service
- Connectivity to internal or external networks
- Web server (e.g. company website)
- Web application (frontend/backend, e.g. library catalog)
- SaaS application such as Webex, Salesforce, or Slack.
- Full mesh of ping tests
A target includes a set of tests (e.g. ping, DNS, HTTP …) and of agents that monitor this target from remote locations. This way, you can understand if an issue with a given target is localized to one agent or to all of them, pointing to a larger issue.
DNS Service
Whether you have a distributed DNS service within your enterprise network, or one centralized one, or even none at all, the ability to resolve hostnames to IP addresses is absolutely necessary for every organization. Service availability for DNS can be verified by a ping test to the DNS server, a hostname resolution test (DNS test) using that DNS server, and a traceroute test towards it for historical troubleshooting.
If you have multiple DNS servers across your network environment for servicing different areas, then you would defined multiple DNS targets for each region and have the group of agents within each region test each DNS server independently.
Network connectivity
There are two approaches here. Either monitor your internet gateways individually per region or globally, or monitor external websites that are always up, such as google.com, or just do both!
An internet gateway target would consist of a PING test to the gateway as well as a traceroute test for troubleshooting. An internet target could also be defined as a PING, DNS, HTTP and traceroute to google.com, and depending on how granular you want to be, you can also test different port numbers.
Web server
Web servers need to be reachable from the network (ping), need to have a resolvable domain name (DNS), need to have the web server (e.g. Apache) up and running and serving (HTTP), and need to be reachable from steady routes (traceroute). These four tests should be enough to verify the availability and performance of a single server.
Web applications
These types of services are a little more complex than a simple web server. They sometimes include load-balancers, backend databases, and other complex architectures. An application manager would know which of these components should be monitored, and verified from the user’s perspective.
Generally you would add the following types of tests: (1) ping tests to the load-balancers, (2) DNS resolution of the service, and more importantly, (3) HTTP test to the root of the service, (4) an HTTP test with URL parameters, to test the backed, e.g. For a library catalog application, this would be a URL to the search page with built-in search terms which would work the same way as if an end-user searched for something on the site, (5) a traceroute may also help for troubleshooting.
SaaS applications
These are similar to Web Applications, but they usually live in the cloud, and are mostly serviced by content distribution networks. Thus it is important for enterprises with highly distributed WANs who pay big bucks for cloud services to make sure that these services are accessible from any WAN location.
Full mesh of tests
Mesh tests among Beez are getting more and more popular among our customers. If you have a serious core network where every location must be able to connect to every other location in your WAN, then you need to set up a mesh test which will run ping and traceroute tests from a subset of beez to every other beez in that set. This also provides historical statistics that help you plan your network upgrades.
Finally, I’d like to mention here that besides all these network monitoring targets you can use to monitor, validate and measure the availability of your network resources, our Beez can also run iperf tests on any environment, from any Beez to any other Beez, to validate the QoS of your network. In terms of our hardware Beez, the first version of Raspberry Pi can generate up to 65Mbps and Raspberry Pi 2 can generate up to 90Mbps of Iperf traffic. However, if you need more power you can generate up to 600Mbps with our GigE Beez, which are Utility based. You can try it yourself by following this earlier blog.
Conclusion on Network Monitoring Targets
Defining your resources to monitor is the hardest part of the monitoring process. But once this is done, then you will have peace of mind when everything is green. If you want to learn more about NetBeez network monitoring, request a demo.
