16. Distributed Collector
16.1. About Distributed Collector
Distributed Collector allows you to deploy additional performance collection and event monitoring daemons to the Resource Manager server or other servers. Doing this allows you to:
• Distribute processor, disk, and network load across multiple servers.
• Collect performance and events from networks that cannot be reached by the Resource Manager server. • Configure more than one set of monitoring settings, such as different cycle times, for the zenperfsnmp daemon.
When you first install Distributed Collector, Resource Manager is configured with one hub and one collector. You cannot delete the initial hub and collector (each named localhost) that are set up by Distributed Collector.
16.1.1. About Collectors
A collector is a set of collection daemons, on the Resource Manager server or another server, that shares a common configuration. That configuration contains values, such as:
• Number of seconds between SNMP collections cycles • Default discovery networks
• Maximum number of zenprocess parallel jobs
Each collector has its own copy of each of the Resource Manager collection daemons. For example, Resource Manager initially contains collection daemons with names like zenperfsnmp, zenprocess, and zenping. If you create a
new collector named My2ndCollector, then the system creates new daemons named My2ndCollector_zenperfsnmp, My2ndCollector_zenprocess, and My2ndCollector_zenping.
16.1.2. About Hubs
Distributed Collector also allows you to set up new hubs. A hub represents an instance of the zenhub daemon,
through which all collector daemons communicate with the object and event databases.
All collectors must belong to exactly one hub; however, a hub can have many collectors associated with it. All hubs (and indirectly all collectors) refer to the same object and event databases. Typically, only very large systems with more than five collectors (or more than 1,500 devices) benefit from multiple hubs.
Hubs manage configuration data and pass it to the collectors. Hubs also take data from the collectors and pass it to the Zenoss DataStore. Multiple hubs can be a more efficient way to manage larger deployments, as they help distribute the computing resources when configuration changes are made. They further remove the potential for configuration changes to be a bottleneck to gathering and processing data.
16.1.3. Typical Usage Scenarios for Distributed Monitoring
The correct distributed strategy for your environment depends on network security restrictions, as well as scale. Contact Zenoss Support if you are unsure which option best suits your enterprise.
Typical setup scenarios for using multiple hubs and collectors are shown in the following table:
Hub Collector Description
Local hub Local collector This setup requires only a single server, and is the most common Re- source Manager deployment type. You would most likely use this configu- ration if you need to monitor fewer than 1000 devices, and your master Re-
Distributed Collector
Hub Collector Description
source Manager server has direct network access to all of the monitored devices.
Local hub Remote collector This setup requires two servers, and is the most basic distributed setup. The primary benefit of this configuration over the local hub/local collec- tor configuration is that the master server does no collection. This frees resources, optimizing the server's ability to perform its central role of database server and Web interface.
Local hub Multiple re- mote collectors
This is the most common distributed Resource Manager configuration. You might use this configuration to scale Resource Manager to monitor more than 1000 devices. Depending on the hardware of the collectors, it is pos- sible to monitor up to 1000 devices for each collector using this configura- tion. You might also use this configuration to handle differing network secu- rity policies. Often, your master Resource Manager server will not have ac- cess to all of the devices you need to monitor. In this case you can set up a remote collector with the required network access.
Multiple re- mote hubs
Multiple re- mote collectors
This configuration is for large installations only. For cases in which you have more than five collectors, you should consider deploying one or more hub servers to handle them.
Table 16.1. Distributed Monitoring Use Scenarios
16.1.4. Prerequisites
Prerequisite Restriction
Product Resource Manager 4.x, Zenoss Version 2.4 or higher
Required ZenPacks ZenPacks.zenoss.DistributedCollector
Table 16.2. Distributed Collector Prerequisites
16.1.5. Navigating Collectors and Hubs
To view and manage collectors and hubs: 1. Log in as the Resource Manager user.
2. From the navigation menu, select Advanced > Collectors.
The Collectors page appears.
Figure 16.1. Collectors Page
The page lists existing hubs and collectors in hierarchical form. Hubs are listed at the top level; collectors are nested below the hub to which they belong.
Distributed Collector
• Add a hub
• Delete a hub (which also deletes its associated collectors) • View and edit hub settings
• Configure associated monitoring templates
Select a hub to display details and configuration options. From here, you can: • Update a hub
• Add and delete collectors
Figure 16.2. Collectors Page - Overview
In the left panel, select Daemons to display details about the zenhub daemon that belongs to the collector. Links
adjacent to the daemon name allow you to view the daemon log, and view and edit its configuration. Use the buttons to the right of the daemon name to stop, start, and restart it.
Figure 16.3. Collectors Page - Daemons