Zenoss Core 3: Tips and Tricks

Implement Zenoss core and fit it into your security management environment using this easy-to-understand tutorial guide.


Zenoss Core 3.x Network and System Monitoring

Zenoss Core 3.x Network and System Monitoring

Implement Zenoss core and fit it into your security management environment using this easy-to-understand tutorial guide.

        Read more about this book      

(For more resources related to the subject, see here.)

Importing devices and attributes
Tip: If you already have a list of the SNMP capable devices by hostname or IP address, Zenoss Core can import them via the zenbatchload command.
In its simplest form, zebatchload will process a text file that lists one device per line. Here's a sample list of devices that I will call deviceList.txt:


Since zenbatchload is a Zenoss Core daemon, we need to run it as the zenoss user. Here are the commands:

su - zenoss
<enter zenoss user's password>
zenbatchload deviceList.txt

The zenbatchload import utility will not update devices that are already in the device inventory.

Editing and moving organizers
Tip: Editing organizers: You can change the name or description of an organizer by selecting the organizer and then clicking on Edit. You can find the Edit option by clicking on the Actions menu button (which looks like a sprocket) at the bottom of the Infrastructure sidebar. See the following screenshot:

Moving organizers: You can nest organizers by dragging and dropping one organizer into another one to create a hierarchy. You can only nest similar organizers, which means that you cannot move a system into a group or a group into a location.

Zeneventlog—unable to connect to Windows
Tip: If you see an event that indicates zeneventlog is unable to connect to Windows, that's an indication Zenoss Core is not able to authenticate to the Windows server. Check the Configuration Properties (zProperties) of the device to ensure you have the correct username and password set.
The following screenshot shows the WMI specific zProperties:

Remember, the zWinUser and zWinPassword properties must be an administrator on the Windows server you're monitoring. It's possible that each of your Windows servers could require a different username and password.
The zWinUser property can be either a local or a domain account. If you use a domain account, specify the domain for the zWinuser value (for example, mojoactive\administrator).

Zenoss Core does not collect WMI data
Tip: It's possible that Zenoss Core isn't collecting any data from the Windows Servers via WMI, but there are no events reported. You can check the following zProperties at the device or class level:

  • Make sure the device is using the zenoss.wmi.WinServiceMap collector plugin
  • Set the zWmiMonitorIgnore property to False in the Configuration Properties for the device or device class
  • If you want to collect event logs, set the zWinEventlog property to True in the Configuration Properties for the device or device class

Acknowledging an event
Tip: Acknowledging an event signals to other team members and to Zenoss Core that you are aware of the event and, presumably, taking action. Acknowledging the event is good communication among your team, but Zenoss Core can also escalate event severities or alerts based on an event status.
A common way to escalate an event or an alert is by the event count. For example, we can instruct Zenoss Core to escalate the event severity from Error to Critical if the event hasn't been acknowledged after a specified number of monitoring cycles. Or if we're dealing with alerts, Zenoss Core can be configured to alert the next person on call, in the event you fall asleep on the roof at 3 in the morning and don't realize the database server has been down for 15 minutes.
To acknowledge an event:

  1. Select the event from the Event Console by clicking on it.
  2. Click on the on Acknowledge Events button (the icon that looks like a check mark).

A check mark will appear next to the event. See the following screenshot:

In the screenshot all the events are acknowledged, except the first one.

        Read more about this book      

(For more resources related to the subject, see here.)

Closing events
Tip: If Zenoss Core monitors a device and finds that a previously detected error condition no longer exists, it automatically clears the event and moves it to History.
You can also manually close an event, after you fix the problem that caused the initial error condition. Let's manually close an event.

  1. Highlight the event from the Event Console.
  2. Find the Close selected events icon and click on it. It's the button with the X inside a circle at the top of the Event Console. Closing an event has the same effect as when Zenoss Core clears the event.
  3. The event disappears from the Event Console.

Don't worry, if the issue isn't really resolved, the event will reappear the next monitoring cycle.

Mapping an event
Tip: There may be times when an event pops into the Event Console in the /Unknown event class. Syslog events, for example, will map to the /Unknown event class.
We can change the mapping of an existing event to a new class. Whether you're mapping an unknown event or changing an existing mapping, the procedure is the same.
Let's take an example where we have an active event from an exim4 mail server program event which we want to map to the /App/Log event class. Feel free to use your own example.

(Move the mouse over the image to enlarge it.)

To map the event:

  1. Select the event from the Events list.
  2. Click on the Map to Event Class button (looks like an org chart) to display the Classify Events dialog box.
  3. In the Classify Events dialog box, select the event class (for example, /App/Log).
  4. Click on SUBMIT to map the event.

After we map the event, Zenoss displays a confirmation message with a link to view the new mapping. Follow the link to view the new mapping:

You can also browse the exim4 mapping by navigating to the /Apps/Log event class and then selecting the Mappings link in the sidebar.

Turning off event de-duplication
Tip: Zenoss Core wants to dedupe every event it receives, but you can override this behavior by adding a custom event mapping and event transformation for the event class. The following transformation comes from the Zenoss Core community documentation at http://community.zenoss.org/docs/DOC-2445#HowdoIstopautomaticEventDeduplication:

mydedupfix1 = getattr(evt,'triggerLastOccur')
mydedupfix2 = getattr(evt,'triggerEventName')
evt.eventKey = '%s - %s' % (mydedupfix1, mydedupfix2)

This code creates a unique event key for every instance of the event, thereby voiding Zenoss Core's deduplication efforts.

Testing syslog configuration with Logger
Tip: We can test our remote syslog configuration by using the command line tool "logger" to send a test syslog message of a specified facility and priority. To test, run the following commands from the Linux device that is logging its syslog messages to Zenoss Core:

logger -p cron.warn "This is a test"
logger -p mail.error "This is another test"

The logger command syntax is straightforward. The -p option specifies the facility and the priority which we follow with a message in quotes. Depending on the syslog.conf rules you wrote, the event may or may not be sent to Zenoss Core. Obviously, your examples should test both use cases.
To double check, click on the Event Console and verify that the syslog messages are being logged correctly.

Configuring alerting rules
Tip: To add an alerting rule, first edit the user. Select the Alerting Rules tab (see the following screenshot) while editing the username to display the list of rules assigned to the user.

  1. From the Advanced menu, select Settings and then Users to display a list of users. You should see a list of users that includes the admin user and the user you defined during installation.
  2. Edit a user (other than admin) by clicking on the name. The properties for the user account will be displayed:

  3. From the sidebar, click on the Alerting Rules menu. A blank Alerting Rules page will be displayed.
  4. Select Add Alerting Rule from the Alerting Rules menu. The Add Alerting Rule dialog box will be displayed.
  5. In the Add Alerting Rule dialog box, type a name for the rule (for example, Test). Click on the OK button to add the rule. At this point the rule is disabled.

    (Move the mouse over the image to enlarge it.)

  6. To enable the rule, click on the rule name to display the properties.
  7. Select True from the Enabled drop-down list.
  8. Click on Save to enable the alerting rule

At this point we have an alerting rule with some default settings. The default rule sends an e-mail when any device in a Production State generates a new event with a Severity level equal to or greater than Error. Zenoss also sends an alert when the event clears.


This article took a look at some tips and tricks for using Zenoss Core 3.

Further resources on this subject:

Books to Consider

comments powered by Disqus

An Introduction to 3D Printing

Explore the future of manufacturing and design  - read our guide to 3d printing for free