Webinar: Discover Zenoss Cloud SaaS-Based IT Monitoring
Forrester Insights:Powering Digital Transformation With Intelligent Monitoring & Analytics
Webinar: Eliminate Blind Spots With Nutanix & Zenoss
Zenoss Partner Portal
Become a Partner
Learn. Discuss. Participate.Join thousands of Zenoss users and experts to learn, discuss and participate in the Zenoss Community.
Customer Support Portal
Zenoss Learning Center
Customers for LifeAt Zenoss, our customers are at the core of everything we do.
Request A Demo
This ZenPack is included with commercial versions of Zenoss and enterprise support for this ZenPack is provided to Zenoss customers with an active subscription.
The ZenPacks.zenoss.DistributedCollector ZenPack allows you to deploy additional performance collection and event monitoring daemons, on the Zenoss platform master host, and on other hosts.
This feature allows you to:
When you first install Distributed Collector, Zenoss platform 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.
A collector is a set of collection daemons, on the Zenoss platform server or another server, that shares a common configuration. That configuration contains values, such as:
Each collector has its own copy of each of the Zenoss platform collection daemons. For example, Zenoss platform 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.
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.
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:
To view and manage collectors and hubs:
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.
From this page, you can:
Select a hub to display details and configuration options. From here, you can:
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.
Collectors Page - Daemons
You must update all collectors after you:
To update a collector:
Note: This section is only relevant for users upgrading from Zenoss Core.
After installing Zenoss platform, existing collectors must be configured to use the nginx reverse proxy. Otherwise, the host name of the collector cannot be resolved from the master, and zenwebserver (nginx) will not start.
To configure a collector to use the reverse proxy, set the render url property to:
where CollectorID is the ID of the collector.
Zenoss platform does not automatically back up remote collector performance data (RRD files). To back up this data, set up a cron job on the remote collector. The cron job should invoke zenbackup with these options:
zenbackup --no-eventsdb --no-zodb
Old backup data is not automatically deleted; therefore, the backup solution you use to save the data should remove the backup file when it is no longer needed.
You can configure the amount of data stored by RRDcached for each collector. Edit one or more options in the zenrrdcached.conf file; options are:
When you delete a collector, its devices are left without an assigned collector. Zenoss recommends that you reassign assigned devices prior to deleting a collector.
To delete a collector, click the name of the hub where the collector exists from the main collectors page. The Hub overview page appears. From the list of Collectors, select the collector you want to delete. From the Action menu, select Delete Collector.
When you delete collectors using this Zenoss platform instance, they are not removed or "uninstalled" in any way from the collector device. They continue to exist on the device until manually removed through the file system.
Adding devices to collectors occurs when you add the device to Zenoss platform.
The device appears in the Devices list, located at the bottom of the collector overview page.
You can move devices from one collector to another.
Note: If you move devices between collectors, you also can select an option choose to move their associated performance data.
Collector daemons appear on the Daemons page for each collector, and can be started, stopped and restarted from there.
Only one zentrap instance can be run on a server, as it must bind to the SNMP trap port (162). If you install multiple collectors on the same server, you must assign different port numbers to additional zentrap daemons. Attempting to run additional zentrap daemons using the same port will cause them to fail at startup.
Each collector installs the zenrender daemon with the rest of the collector package. If multiple collectors are installed on the same host, then the zenrender daemon will attempt to run for each collector. Since each zenrender daemon attempts to bind to the same port, all but the first daemon will fail to start. This is a problem for HA/failover environments, since failure detection systems will detect these stopped zenrender daemons and assume they are down. (ZEN-2967)
The remedy for this is to assign each zenrender daemon (beyond the first) its own unique port. This is accomplished by adding the following line to each Collector_zenrender.conf on your collector's host (in $ZENHOME/etc), where Collector is the collector name:
X is a number greater than 1 and unique among multiple collectors.
Note: The ports you choose for the additional collectors are arbitrary, as they are not used. However, you must leave at least one zenrender daemon using the default port (8091).
You may specify the collector daemons to start for all collectors, and for individual collectors.
To specify the daemons to start for all collectors, follow these steps:
To specify the daemons to start for an individual collector, follow these steps:
The Distributed Collector ZenPack uses openSSH and an RSA public/private key pair for secure communications between the master host and remote hub and collector hosts.
During installation, the Distributed Collector ZenPack invokes the OpenSSH ssh-keygen command to generate a new, unique RSA key pair for user zenoss on the master host. The command generates an RSA key pair with an empty passphrase, and places the key pair in the zenoss user's $HOME/.ssh directory.
Note: The Distributed Collector ZenPack does not support SSH key pairs that require a passphrase.
You may use the generated key pair to deploy a remote hub or collector, or replace the pair with a new key pair. However, you must use the same key pair for all hub and collector hosts. Therefore, if you choose to replace the key pair, Zenoss recommends doing so before deploying any remote hub or collector.
When a remote hub or collector is created, the Distributed Collector ZenPack copies the key pair of the zenoss user on the master host to the authorized keys file of the zenoss user on the remote hub or collector host, if the entry does not already exist.
When a remote hub or collector is deleted, entries for the zenoss user (on the master host) in the authorized keys file of the root and zenoss user on the remote hub or collector are not removed. Likewise, the known hosts file of the zenoss user (on the master host) is not edited to remove the entry for the remote hub or collector. You must remove these manually.
View the discussion thread.
This ZenPack is developed and supported by Zenoss Inc. Commercial ZenPacks are available to Zenoss commercial customers only. Contact Zenoss to request more information regarding this or any other ZenPacks. Click here to view all available Zenoss Commercial ZenPacks.