Zenoss developers will be available for questions on Thursday, November 20 at 11am EST (UTC -05:00) in the #zenoss IRC channel on irc.freenode.net (port 6667). Please drop in and bring your questions, answers, suggestions and feedback. We can discuss the recent 2.3 release and recent events in the Zenoss community.

We’ll log the session and repost them here if you can’t make it.

Don’t forget you can search for answers to common questions by visiting the Zenoss forums.

Here is a reoccurring calendar event reminder: Zenoss IRC Session (iCal/Outlook)

Tags: development, irc, Zenoss

Zenoss developers will be available for questions on Friday, November 7 at 11am EST (UTC -05:00) in the #zenoss IRC channel on irc.freenode.net (port 6667). Please drop in and bring your questions, answers, suggestions and feedback. We can discuss the 2.3 beta and recent changes in the Zenoss community. Also please note that we have moved it to Friday this week because of an internal scheduling conflict.

We’ll log the session and repost them here if you can’t make it.

Don’t forget you can search for answers to common questions by visiting the Zenoss forums.

UPDATE:
Here’s Friday’s IRC log

http://www.zenoss.com/community/discuss/irc/archives/dev-chat-11-07-2008
other logs are available here:

http://www.zenoss.com/community/discuss/irc

Tags: Community, developers, irc, Zenoss

In a recent forum post, user ccole shared a event transform to create unique thresholds per filesystem monitored. He reported that

My management is very interested in Zenoss, but we’ve got a few challenges. The first challenge is that we have a number of Windows machines that have large shadow copy volumes. Those are intended to fill up, and alerting for those isn’t particularly useful. The second challenge is that a one-size-fits-all threshold doesn’t actually fit all.

The solution we’ve fixed upon is to put a custom threshold into the volume name and work off that. Here’s the code used in the /Perf/Filesystem event transform (based off another user’s change that made for more understandable messages)

Zenoss guru Chet Luther added a couple of minor fixes and here’s the result:

import re

fs_id = device.prepId(evt.component)
for f in device.os.filesystems():
    if f.id != fs_id: continue

    # Extract the percent and free from the summary
    m = re.search("threshold of [^:]+: current value ([\d\.]+)", evt.summary)
    if not m: continue
    usedBlocks = float(m.groups()[0])
    p = (usedBlocks / f.totalBlocks) * 100
    freeAmtGB = ((f.totalBlocks - usedBlocks) * f.blockSize) / 1073741824

    # Make a nicer summary
    evt.summary = "Disk space low: %3.1f%% used (%3.2f GB free)" %  (p,freeAmtGB)

    # This is where we change to a per device threshold
    perDeviceThreshold = 95.0
    m = re.search("zz(\d{3})", f.id)
    perDeviceThreshold = m and float(m.groups()[0]) or 95.0
    if p >= perDeviceThreshold: evt.severity = 5
    break

UPDATE: fixed the indentation

Tags: event transform, tip, Tips, Zenoss

Packt Publishing’s recently published book Zenoss Core Network and Systems Monitoring has started picking up reviews recently. We think it’s a great new guide for expanding your understanding and becoming more familiar with configuring, using, and adapting Zenoss Core.

• Roberto Galoppini’s Open Source Books: Zenoss Core
• James Pulver’s Reviewing the Zenoss Book from PACKT Publishing
• Dave Hope’s Book Review of Zenoss Core, Network and System Monitoring
• Scott Haskell’s Zenoss Core Network and System Monitoring Review

The book was written by Zenoss community member Michael Badger who was passionate about our software and took it upon himself to share his knowledge. Packt Publishing has also added a nice excerpt on their site:
User Management in Zenoss.

Read the reviews and check out the software, we’re very proud that our software generates that kind of enthusiasm and hope that our efforts and the efforts of our community of users are evident as you use Zenoss Core. It’s available in hardcopy and as a PDF from Packt Publishing

Tags: book, Community, reviews, Zenoss

Community member Nathaniel McCallum’s provided instructions for making Zenoss use LDAP or ActiveDirectory for Authentication and Authorization recently had a very important update from Scott Haskell. Users were reporting very slow UI response times and Scott narrowed it down to those installations using LDAP. He tracked down the Zope RAM Cache Manager and updated the documentation on how to greatly improve performance:

Enabling Caching

LDAPMultiPlugins has the ability to cache expensive LDAP look-ups and other operations. This ability, however, is not enabled by default. To enable caching:

• Login to the ZMI (Zope Management Interface) at http://servername:8080/zport/manage
• Click on ‘acl_users(PAS)’ from the center pane or the top-level ‘acl_users’ from the left navigation pane
• From the drop-down list in the upper right, select ‘RAM Cache Manager’ and click add.
• Give the RAM Cache Object a name; e.g. - LDAP Cache
• Click on the newly created object to configure it
• Tweak the properties as needed
• Click on the ‘Associate’ tab
• Click ‘Locate’
• Your LDAPMultiPlugins object (whatever you named it) and userManager will appear as objects that you can associate with the RAM Cache.
• Check your LDAPMultiPlugin object and select ‘Save Changes’.

Caching is now enabled for LDAP.

Scott went even further and documented his debugging and troubleshooting of the problem. Thanks again to Scott for this great tip!

Tags: Community, ldap, tip, Zenoss, Zope

This tip has been adapted from Wouter ‘netdata’ D’Haeseleer’s post on Zenoss-Users:
http://community.zenoss.com/forums/viewtopic.php?p=23030

Download this file and put it in $ZENHOME/bin
http://www.zenoss.com/Members/netdata/tracepath.py

or if your Zenoss server has direct access to the internet you could do this:
wget http://www.zenoss.com/Members/netdata/tracepath.py -O $ZENHOME/bin/tracepath.py
or
curl -O http://www.zenoss.com/Members/netdata/tracepath.py -o $ZENHOME/bin/tracepath.py

Set the permissions:
chmod +x tracepath.py

You can now run it against any device you want to see if Zenoss is able to build layer 3 dependencies for.

tracepath.py swiss11
Getting path from zenoss0101 to swiss11...
zenoss -> VGB-DC01-SW01 -> VG_Turnhout -> pbru223.controlnet.equant.net -> pkt47.controlnet.equant.net -> CHEL-ZO01-SW01 -> swiss11

This reveals the path from the Zenoss server to the device passed in.

When Zenoss is unable to trace the path it will throw an error:

tracepath.py pkt1401
Getting path from zenoss0101 to pkt1401...
Traceback (most recent call last):
  File "/opt/zenoss/bin/tracepath.py", line 30, in ?
    path = source.os.traceRoute(destination, [])
  File "/opt/zenoss/Products/ZenModel/OperatingSystem.py", line 121, in traceRoute
    return nextdev.traceRoute(target, ippath)
  File "/opt/zenoss/Products/ZenModel/Device.py", line 507, in traceRoute
    return self.os.traceRoute(target, ippath)
  File "/opt/zenoss/Products/ZenModel/OperatingSystem.py", line 121, in traceRoute
    return nextdev.traceRoute(target, ippath)
  File "/opt/zenoss/Products/ZenModel/Device.py", line 507, in traceRoute
    return self.os.traceRoute(target, ippath)
  File "/opt/zenoss/Products/ZenModel/OperatingSystem.py", line 121, in traceRoute
    return nextdev.traceRoute(target, ippath)
  File "/opt/zenoss/Products/ZenModel/Device.py", line 507, in traceRoute
    return self.os.traceRoute(target, ippath)
  File "/opt/zenoss/Products/ZenModel/OperatingSystem.py", line 122, in traceRoute
    raise TraceRouteGap("unable to trace to %s, gap at %s" % (target.id,
Products.ZenModel.Exceptions.TraceRouteGap: unable to trace to pkt1401, gap at pbr213.controlnet.equant.net

Zenoss throws an error that there is a gap at pbr213.controlnet.equant.net. This means the Zenoss server is unable to see the routes that will lead to pkt1401.

When you use this script without a correct device it will lead to this:

tracepath.py foobar
Getting path from zenoss0101 to foobar...
Invalid destination.

Zenoss developers will be available for questions on Tuesday, August 14 at 11am EST in the #zenoss IRC channel on irc.freenode.net (port 6667). Please drop in and bring your questions, answers, suggestions and feedback. See you there!

We’ll log the session and repost them here if you can’t make it.

Don’t forget you can search for answers to common questions by visiting the Zenoss forums.

UPDATE:
Here’s last Thursday’s IRC log
http://www.zenoss.com/community/discuss/irc/archives/dev-chat-08-14-2008
other logs are available here:
http://www.zenoss.com/community/discuss/irc

Tags: Community, development, irc, Zenoss

Does the way that Zenoss chooses what templates to apply have you confused?

Explanation of Template Binding

Zenoss applies templates in many different and therefore confusing ways. The following is an explanation of the different ways templates get bound and hopefully a logically explanation of why it is done. It is important to remember that the name of each template is very important and is case sensitive.

Device Templates

Device templates are applied to devices, and only once per device. Device templates get bound to devices according to a single rule, what the zDeviceTemplates property contains. For most device classes within the system this is set to “Device”. For a hypothetical /Server/Linux/MySQL device class the zDeviceTemplates property would likely contain Device and MySQL so that normal CPU & Memory information would be collected using the Device template and MySQL specific metrics using the MySQL template.

Common device templates:

• Device
• MySQL, Apache
• Active Directory, MSExchangeIS, MSSQLServer, IIS

Component Templates

Component templates are a bit more mysterious than device templates. The biggest difference in how they’re applied is that they can be applied many times per device depending on how many components the device contains that match the template. Another big difference is that there are no zProperties that control which template is applied. They follow more rigid rules.

Common component templates:

• FileSystem, HardDisk, IpService, OSProcess, WinService
• Fan, PowerSupply, TemperatureSensor
• LTMVirtualServer, VPNTunnel

These component templates are named EXACTLY according to the name of the underlying class that represents the component. This is the case for all component templates except for what you might expect to be called IpInterface. As you might have already noticed, there is no template called IpInterface.

Interface Templates

Templates get applied to network interfaces using a special kind of binding. Instead of using the name of the underlying class, Zenoss will look for a template that has the same name as the “type” of the interface. You can find this type by clicking into the details for any network interface from the OS tab of its containing device.

If a template matching the name of the interface’s type can’t be found, the “ethernetCsmacd” template will be used as the fallback. Most interfaces you’ll find are this type.

Conclusion

Hopefully this helps you better understand how templates are bound to devices and components.

Tags: Bindings, Templates, Zenoss

Zenoss provides a variety of tools to help you integrate it into other tools. Commonly used are the REST, XML-RPC and Python APIs. Another less-used option is XML. This can be very useful as a read-only integration point because you can get all of the data you need in a single simple transaction and good XML parsing libraries exist for all languages.

In this example, we’ll be creating a page template that replicates the data that is available on a device’s status tab. The only difference is that the data will be easily-consumable XML.

Create the Page Template

1. Go to http://yourzenoss:8080/zport/portal_skins/custom/manage
2. Choose “Page Template” from the drop-down box in the top-right and click Add.
3. Set the Id to “deviceStatusXml” then click Add and Edit.
4. Replace the default contents with the XML template below.
5. Click Save Changes.

XML Template

<?xml version="1.0"?>
<tal:block tal:define="
status python:here.getPingStatus()<1 and 'Up' or 'Down';
productionState python:here.convertProdState(here.productionState);
priority python:here.convertPriority(here.priority);
">

<device tal:attributes="id here/id">
<manageIp tal:content="here/manageIp"/>
<status tal:content="status"/>

<availability tal:content="here/availability"/>
<uptime tal:content="here/uptimeStr"/>
<productionState tal:content="productionState"/>
<priority tal:content="priority"/>
<lastChange tal:content="here/getLastChangeString"/>
<lastCollection tal:content="here/getSnmpLastCollectionString"/>
<firstSeen tal:content="here/getCreatedTimeString"/>

<deviceClass tal:content="here/getDeviceClassName"/>
<location tal:content="here/getLocationName"/>
<groups tal:repeat="group here/groups/objectValuesAll">
<group tal:attributes="id group/id; name group/getOrganizerName"/>
</groups>
<systems tal:repeat="system here/systems/objectValuesAll">
<system tal:attributes="id system/id; name system/getOrganizerName"/>
</systems>

<tag tal:content="here/hw/tag"/>
<serialNumber tal:content="here/hw/serialNumber"/>
<hardwareMake tal:content="here/hw/getManufacturerName"/>
<hardwareModel tal:content="here/hw/getModelName"/>
<osMake tal:content="here/os/getManufacturerName"/>
<osVersion tal:content="here/os/getModelName"/>
<rackSlot tal:content="here/rackSlot"/>
<snmpSysName tal:content="here/snmpSysName"/>
<snmpLocation tal:content="here/snmpLocation"/>
<snmpContact tal:content="here/snmpContact"/>

<snmpDescr tal:content="here/snmpDescr"/>
<comments tal:content="here/comments"/>
</device>

</tal:block>

Viewing the XML

1. Navigate to any device in your Zenoss web interface.
2. Click on the Status tab. Note that the URL ends with /deviceStatus
3. Change the URL to end with /deviceStatusXml instead.
4. View the source of the page that comes up. Device status in XML!

The Zenoss Submit a Tip Contest has ended and I would like to thank everyone who submitted tips close to 30 and posted multiple blog entries pointing to Zenoss tips.
The winner was Torben Bøgede Sørensen whose tip was  “How to Setup a Kiosk or Zenoss Overview monitor.” This tip was selected randomly from all entriess.

I also wanted to recognize two exceptional community members who submitted many tips for the contest and to help out their fellow Zenoss users Wouter D’Haeseleer and Arthur Penn. In recognition for their exceptional efforts I am awarding them each a limited edition Zenoss jacket that we use to recognize our employees during their first year of service. This signifies their exceptional effort and that we consider them a part of the Zenoss Project team.
Thanks to everyone who participated and who helped share their Zenoss knowledge.