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.
|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:
defaultexecutor assigns all methods from all services not otherwise assigned to zenhubworker (default).
eventexecutor is reserved for the zenhub service itself.
admexecutor assigns all instances of the applyDataMaps method from all services to zenhubworker (adm).
- By default, the
userexecutor has no services or methods assigned to it. When configured, any methods assigned to this executor are assigned to zenhubworker (user).
Method assignment rules
*:*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,
bar:foo, are assigned to three separate executors. The worker assigned the
bar:fooexecutor would only execute the
foomethod from the
barservice. The worker assigned the
*:fooexecutor 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,
*:foo. The method
bar:foowould be passed to the worker assigned the
*:fooroute. Other methods from the
barservice will be handled by the worker assigned the
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
ZenPacks can introduce new services and methods, so the list is not comprehensive.
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.