In Chapter 6, Core Event Management we took an in-depth look at how Zenoss Core processes events that result from its core monitoring activities. In other words, Zenoss Core went looking for problems. In this chapter, we'll let the problems come to Zenoss Core by way of non-Zenoss applications, such as syslog, Windows event log, scripting, and e-mail.
In this chapter, we will:
- Route syslog messages to Zenoss Core
- Monitor the Windows event log
- Incorporate event reporting into third-party scripts via zensendevent
- Create events by e-mail using zenpop3 and zenmail
- Configure alerting rules
Let's get started.
We have the capability to monitor syslog messages from Unix-based hosts on the network by turning Zenoss Core into a syslog server. The syslog is a standard logging format for Unix-based systems that allow administrators to analyze, troubleshoot, and debug the programs and services running on a device. Zenoss uses the zensyslog daemon to turn incoming syslog messages into events from any host on the network.
Before we configure our servers to send syslog messages to Zenoss Core, we need to determine the syslog facility and priority we want to monitor. The available facilities include auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, and uucp. The facility specifies the subsystem we want to monitor. For example, we specify the lpr facility to monitor print activity.
We specify one of the following priorities, listed from the lowest to the highest severity: debug, info, notice, warning, err, crit, alert, and emerg. As an example, we would choose warning to monitor logs with a priority of warning, err, crit, alert, and emerg.
Pick a Linux server from your inventory and let's work through an example by modifying its syslog.conf file:
Note the *.debug syntax in the syslog example. This sends all syslog facilities (represented with *) with a minimum priority of debug to Zenoss Core. I chose this setting for our example so we could get the events flowing. Dumping all your syslog messages to a the Zenoss Core event will likely cause a lot of events, and may be more than you want. So, some customization is warranted here and the natural question is, "What is an appropriate value?". However, I can't provide an answer that applies to you and your environment. Remember, we're telling individual servers what messages to send to Zenoss Core. If in doubt, cast a wide net and then narrow it down.
I, for example, really don't want to see events in Zenoss Core for anything less than an error. So at the very least, I modify the rule in my server's syslog.conf file to:
*.err @192.168.1.125
If I was configuring the syslog on a server whose main mission in life was as an FTP server, then I might be inclined to narrow the server's syslog.conf with this rule:
This will send all syslog messages concerning FTP that at least have a priority of error to the Zenoss Core server for processing by zensyslog. You can specify multiple rules, which helps us send just the right messages to Zenoss Core.
Feel free to set a more appropriate value. For the benefit of the non-Linux system administrators, you can gain more information about syslog.conf, by running the command at your nearest terminal:
man syslog.conf
Of course, Unix-based servers are not the only devices that have remote syslog capabilities. Many routers provide remote logging features. We'll overview the steps needed for a Cisco router. For other devices, consult the documentation.
To forward a Cisco router's syslogs to Zenoss Core, we need to know the Zenoss Core host, the minimum log priority to collect, and the facility. The following priorities are available: emergency, alert, critical, error, warning, notice, informational, and debug. The available facilities include local0 through local7 (also available to syslog on Unix servers) and the default facility is local7.
To forward syslog messages from a Cisco IOS router to Zenoss Core, log into the router and follow these steps using privileged EXEC mode:
- Enter the configuration mode with the command:
configure terminal - Specify the Zenoss server by IP address or host name with the command:
logging 192.168.1.125 - Set the syslog priority:
logging trap warning - Set the syslog facility:
logging facility local7 - Quit the configuration mode:
end - Verify the logging information:
show logging
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.
Note
The events from syslog will show with an unknown class. Use the procedures outlined in Chapter 6, Core Event Management to map the events to a class.