Today we’ll talk about how you can create different types of network monitoring targets for the network monitoring sensors (Beez). We defined the ‘Target’ concept as an abstract enough entity on the NetBeez ecosystem so our customers could come up with interesting ways to define their network resources. Here are some of the types of network monitoring targets we identified:
- DNS service
- Internet connectivity (external sites & Internet gateways)
- Webserver (e.g. company website)
- Web application (frontend/backend, e.g. library catalog)
- Cloud app
- Site oriented (Part 2)
- SSLVPN collector
- Internet gateway
- Network monitoring targets for Wireless monitoring
As mentioned in the title a network monitoring target is a network resource that needs to be delivered to your users/customers in order to accomplish the enterprise’s business goals. Each resource can be defined as a set of tests (what we call Test Templates of PING, DNS HTTP, or Traceroute tests) and a set of Beez that monitor this target from the end-user’s perspective, from remote locations. This way, you can understand if an issue with a given target is Local Vs. Global, or Network Vs. Application.
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.
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 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.
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) PINGs 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.
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.
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.
Defining your resources is the hardest part of the monitoring process. But once this is done, then you will have peace of mind when everything is green 🙂
In the second part of this blog, I will cover the concept of setting up network monitoring targets from a site-oriented aspect. Stay tuned!