When setting up a monitoring solution for IT infrastructure, device discovery is (obviously) a critical first step. But discovery can mean different things to different people and organizations. To some people, it means figuring out what attributes a device has, e.g., memory, CPU, file systems and so on. We call this type of discovery “modeling,” and it is the key to our deep infrastructure monitoring. To others, discovery can mean basically scanning a network and finding all the devices on it.
Zenoss does both of these very well. Beyond that, however, is a critical step called categorization. This is where your monitoring solution will find a device, identify it, place it in the proper device class, and begin monitoring.
When it comes to adding devices, it is most efficient to add devices that your organization already knows about first. This could be a CMDB integration, a spreadsheet or list that is converted to a batch load script, an automated process using the Zenoss API or (as a last resort) manually entering devices. After that, an organization needs to deal with the devices they don't know about. Zenoss can scan the network and discover these, and if we have credentials for the scan, we can identify what a lot of devices are. The question is what to do with them.
In some organizations, if a device is on the network that their monitoring solution does not know about, it is a major issue. It's unauthorized and needs to be located and removed (and someone probably needs to get remedial training on the proper process to add devices). These organizations do not want to categorize unknown devices and start monitoring them automatically.
Other organizations are not as strict and need to rely on a network scan to get everything into their monitoring solution to be tracked. For this, Zenoss has the Discovery Mapping ZenPack. This allows the organization to automatically put devices into the class they want them to be in and to begin monitoring them. It is also possible to write scripts to classify devices after discovery if the Discovery Mapping ZenPack does not cover the device types or more complicated mapping rules are needed.
The last case is automation. Organizations will automatically deploy devices and want to monitor them immediately. Scanning the network to find these types of devices after they are deployed is very inefficient. The best way to do this it to use the same automation that is deploying the devices to add the devices to Zenoss for monitoring. This way, they go straight to the right class and can be monitored as soon as they are up and running.
Zenoss can allow you to take the approach that suits your organization best due to its very flexible nature. By default, we add discovered devices to a /Discovered device class in Zenoss for an admin to review. We do not automatically categorize them, and we do this on purpose. Zenoss has the ability to be highly customizable in the way it monitors devices. For example, you can choose to monitor an application server differently than a database server, even if the OS is the same. Or, monitor a database server differently based on whether or not it’s in a cluster. Our MSP customers will customize monitoring based on the service level of their customers, using monitoring as a value-added service.
Zenoss needs to understand how you have implemented monitoring and your rules for categorization.When it comes to automatically categorizing the devices that Zenoss discovers when scanning a network, we can help you categorize the devices — placing them in the appropriate device class — if you tell us what those rules are. This approach allows us to accommodate the widest array of customer environment types, with the default being the most stringent with the ability to add categorization as needed. It's much easier to add categorization than it is to try and remove it later.
In addition, Zenoss offers well over 400 individual ZenPacks that enable you to monitor any devices you manage — from legacy UNIX servers to hyperconverged systems and public cloud resources. By eliminating blind spots in the data center and building a clean, real-time service model that pulls in data points from every resource, you can build a solid foundation for ensuring consistent availability for your most critical services. If you want to learn more, we’d love to show you.
