EFICIENCIA Y EFICACIA DE LOS PROYECTOS.

Read the following sections for more information about monitoring using ZenCommand.

6.3.1. About ZenCommands

Zenoss Core has the ability to run Nagios® and Cacti plug-ins though the ZenCommand process. ZenCommand can run plugins locally and remotely by using a native SSH transport. When run, the system tracks the return code of each plug-in and then creates events with plug-in output. Additionally, it can track performance information from a plug-in.

Figure 6.17. Running ZenCommands

6.3.2. Example: Writing a ZenCommand (check_http example)

You can use a ZenCommand plugin (check_http) to check for specific content of a Web page. (This implicitly checks for server/page 200 status as well.)

The following example procedure shows how to set up a ZenCommand plugin to check specific content. The steps show how to test the plugin, and then integrate it.

1. As the zenoss user, test the plugin from the command line. Enter the following command to test the product di- rectory:

$ZENHOME/libexec/check_http -H www.zenoss.com

If the check_http command is correct, the output will look similar to the following.

Core Monitoring

Note

The check_http -h command displays all plugin options.

2. Add the device you want to check (one running a "www" Web site) to the Zenoss Core system, setting the discovery protocol to "none."

3. Navigate to the device, and then select Monitoring Templates from the left panel. 4. Create a local copy.

The default device template is overridden with the device template specific to this device.

5. In the template, remove the sysUpTime data source. (In this example, SNMP is not used for the device.) 6. Add a new description to the template.

7. Add a new data source called rootWebCheck.

8. In the rootWebCheck data source, set the following variables: • Source Type = COMMAND

• Component = rootWebCheck • Cycle Time = 30

9. Debug your ZenCommand by running zencommand in the foreground with debugging on:

zencommand run -d www.website.com -v10

Where www.website.com is the site you want to monitor.

The command template field is a TALES expression. You can make substitutions in the command that will make it generic for any device added to this class.

10.Set the -H flag to the IP of the device against which this command will be run, as follows:

check_http -H ${here/manageIp}

11.Add a check looking for content on the page. The -r flag will run a regular expression against the Web page to check for text.

check_http -H ${here/manageIp}-r textstring1

Where textsrting1 is text you know is on the resulting Web page.

12.For this example, the command should be generic. Make a custom field for the regex that can be changed per device. Set the default to “.*”, which will match everything. Go to /Devices/Custom Schema and add a new field: • Label = Web Match Regex

• Name = cWebMatchRegex • Type = string

• Default = .* • Visible = True

Core Monitoring

13.Return to the template and change the command to be.

check_http -H ${here/manageIp}-r ${here/cWebMatchRegex}

14.Add the regex value into cWebMatchRegex (used in the example above). 15.Test the ZenCommand from the command line.

6.3.3. Example: Collect Data from A ZenCommand

To collect and display data from the ZenCommand check_http example, you can log the data to see something like response time in a graphical format.

1. Navigate to /Web/Device template.

2. Go to the data source created in the check_http example.

3. Add a data point named "time." (No modifications are needed to the data point.) 4. Test the command again. You should see a log message that starts with:

DEBUG:zen.zencommand:storing responseTime = 1.0

5. Make a graph to display the data. In the device template, create a graph called “Web Response Time." 6. For this graph, set the following values:

• Data Sources = rootWebCheck_responseTime • Units = Seconds

• Min Y = 0

7. Go to Graphs for the device www.website.com (the Web site you were using to check) to see the graph. Graph data will not appear until collection is run several times. Restart zencommand so that the new configuration takes

effect immediately.

6.3.4. Plugin Format for ZenCommands

Nagios® plugins are configured by using a command template that is much like the RRDTemplates used for perfor- mance monitoring.

A template named “Device” will bind to all devices below the template definition. Within each template is a list of commands that will run. The commands can be any program that follows the Nagios® plug-in standard. Inputs are command line arguments; output is the first line of stdout, plus a return code.

Note

Zenoss Core return codes differ from Nagios return codes, as follows:

Value Zenoss Core Nagios

0 Clear OK

1 Data Source WARNING

Core Monitoring

Value Zenoss Core Nagios

3 Data Source UNKNOWN

For complete information about Nagios plugin guidelines, browse to this location: http://nagiosplug.sourceforge.net/developer-guidelines.html

A Nagios® command has several fields:

• name – Specifies the name of the command object.

• enabled – Indicates whether this command should be used on a given device.

• component – Specifies the component name to use when zencommand sends events to the system. • event class – Specifies the event class to use when sending events to the system.

• severity – Sets the default severity to use when sending events to the system. • cycle time – Sets the frequency a command should be run (in seconds). • command template – Specifies the command to run.

The command template string is built by using Zope TALES expressions. Several variables are passed when eval- uating the template. They are:

• zCommandPath – Path to the zencommand plug-ins on a given box it comes from the configuration property zCom- mandPath. zCommandPath is automatically added to a command if a path is absent from the beginning of the com- mand.

• devname – Device name of the device against which the command is being evaluated. • dev – Device object against which the command is being evaluated.

• here – Context of evaluation. For a device, this is equivalent to dev for a component (such as a file system or interface). This is the component object.

• compname – If this command evaluates against a component, specifies its name as a string. • now – Current time.

Template values are accessed like shell variables. They are the same as the expression syntax used in the appendix titled TALES Expressions (in this guide).

Examples

Run an http check against all devices by using the URL /zport/dmd:

check_http –H ${devname}-u /zport/dmd

In a template named FileSystem, the following command will run against all file systems on a device:

check_disk –w 10% -c 5% -p ${compname}

6.3.5. Testing ZenCommands

Core Monitoring

From the command line, run:

zentestcommand –d DeviceID --datasource=DataSourceName

where DeviceID is the device on which you want to run the command, and DataSourceName is the name of a data source on a template associated with the device.

The zentestcommand script prints the results of the command to standard output.