Zenhub and its workers

The zenhub service performs many functions:

provides collector services the instructions they need to perform their duties
serves as a broker for event processing from the collector services to the upstream infrastructure services
writes device and component information discovered during modeling to the Zope object database (ZODB)

The zenhub service accomplishes most of this work by creating lists of tasks and passing off the lists to its workers. Different tasks, also referred to as methods, go to different workers.

Worker service	Description
zenhubworker (default)	The default worker service. It is responsible for any methods not specifically assigned to a different worker
zenhubworker (adm)	The worker that processes applyDataMaps methods, which are performed after a device is modeled or remodeled. These methods update the object database and have their own worker so that model data from large"devices (or large numbers of devices) do not impede the methods performed by other workers.
zenhubworker (user)	A troubleshooting worker that performs a user-defined list of methods. By default, the list is empty and the worker is stopped. For more information, see Available user methods below.
zenhubiworker	The worker that processes invalidation requests. For more information, see Available user methods below.

Method assignment overview

The zenhub service uses the zenhub-server.yaml file to assign methods to specific workers. As of Resource Manager release 6.6.0, the default contents of the file are as follows:

## zenhub server configuration
##
## <executorid>:
##    spec: "<module-path>:<class-name>",
##    worklist: "<worklist-name>"  ### not required, if empty uses <executorid> as a name
##    routes:
##        - <service-name>:<method-name>
##        ...
##

default:
    spec: "Products.ZenHub.server.executors:WorkerPoolExecutor"
    routes:
      - "*:*"

event:
    spec: "Products.ZenHub.server.executors:SendEventExecutor"
    routes:
      - "EventService:sendEvent"
      - "EventService:sendEvents"

adm:
    spec: "Products.ZenHub.server.executors:WorkerPoolExecutor"
    routes:
      - "*:applyDataMaps"

user:
    spec: "Products.ZenHub.server.executors:WorkerPoolExecutor"

Notes about the executors:

The default executor assigns all methods from all services not otherwise assigned to zenhubworker (default).
The event executor is reserved for the zenhub service itself.
The adm executor assigns all instances of the applyDataMaps method from all services to zenhubworker (adm).
By default, the user executor has no services or methods assigned to it. When configured, any methods assigned to this executor are assigned to zenhubworker (user).

Method assignment rules

The *:* route can only be assigned to a single executor. If the *:* route is assigned to multiple executors, the zenhub service does not start.
Specific is prioritized over general. For example, assume that three routes, *:*, *:foo, and bar:foo, are assigned to three separate executors. The worker assigned the bar:foo executor would only execute the foo method from the bar service. The worker assigned the *:foo executor would execute the foo method found in all other services. The *:* executor would execute all other methods from all other services.
Methods are prioritized over services. For example, assume the following two routes, bar:* and *:foo. The method bar:foo would be passed to the worker assigned the *:foo route. Other methods from the bar service will be handled by the worker assigned the bar:* service.

Available user methods

Zenoss strongly recommends not using the user executor and the zenhubworker (user) service unless requested by Zenoss Support. The following list is a sample of the methods available for the user executor:

getDevicePingIssues
getDeviceConfig
getDeviceConfigs
applyDataMaps
singleApplyDataMaps
getCollectorThresholds
getThresholdClasses
getEncryptionKey
getClassCollectorPlugins
getConfigProperties
propertyItems
getDeviceListByOrganizer

ZenPacks can introduce new services and methods, so the list is not comprehensive.

Invalidations

When a collector service starts, it requests a configuration file from the zenhub service. The file describes the service's tasks. For instance, the zenperfsnmp service receives a list of devices and their IP addresses, relevant community strings and other SNMP settings, and a list of data sources from the monitoring templates associated with the devices and their components. The configuration file is refreshed according to the configuration flush interval (default 6 hours). When a change that affects monitoring is made—for example, to a template or a zProperty—the zenperfsnmp does not learn of the change until the flush interval expires.

For this reason, changes that affect monitoring generate special messages, known as invalidations, which are passed to the zenhubiworker service. This worker informs the relevant collection services that their current configuration files are invalid, which prompts them to request a new file from the zenhub service before the flush interval expires.

For information about starting invalidations manually, see Updating device configuration.