Pandora: Documentation en: Log Monitoring
1 Log Collection
Pandora FMS is a monitoring system which mainly collects events and performance information. Sometimes, it's used to monitor the result of a certain command's output in form of a string. The same mechanism (which is called 'command execution parsing') is used to execute expressions (as a single, as a match or by regular expression) within a log, returning only the matched information or the number of matches.
You may also use Pandora FMS to count the number of files in a log or single matches (by using 'grep') on a file, but that is monitoring, not log-collection.
The biggest problem regarding massive log collection is the huge sizes they can grow to. We're talking about environments starting in 100MB's a day to others where 1GB's per hour is considered to be normal. That means: Information of such dimensions cannot be processed, normalized and stored in a database - it's simply impossible.
Until now, Pandora FMS doesn't have a solution to this problem - but with version 5, Pandora FMS Enterprise offers a solution to manage hundreds of MB's per day in log files. This solution allows to reuse the same agents used for monitoring, to collect information from event logs (windows) or in form of text file logs. It uses syntax which is very similar to the current log-monitoring modules.
Logs managed by Pandora FMS Agents (event-log or plain-text files) are stored in a special directory in the original RAW format on the Pandora FMS Server, which was defined in the moment of configuration.
The Pandora FMS Data Server receives the XML file from the agent which contains the information gained by the monitoring and log sources in its original format. It stores the log information on the hard drive. The monitoring information is going to be processed as usual.
All log information is arranged on the hard drive, using a directory hierarchy by date, so the system is able to quickly locate all information - no matter how large your repository might be. This system is well known and it's also the standard for extensive data searches and storage tasks.
First, you're required to activate this feature within the console. It's in a special section in the setup, as you can see on the following picture under the 'Activate Log Collector' option in the 'Enterprise' tab:
After enabling this option within the setup, you may set up some other specific options for the log collection in the 'log collector' tab. You're able to define the directory where the Pandora FMS Data Server is going to store the log files. It should be BIG. Please keep in mind that logs can accrete to several Terabytes in a few days!
Of course, you're also able to setup the max. number of days you intend to keep this data on your hard drives. Any data above the specified limit is going to be automatically deleted from the servers.
If you activate or deactivate the log collection feature, you're required to restart the Pandora FMS Server in order for the changes to take effect. If you want to store a huge amount of data but don't intend to create any interference to your real-time operations under Pandora FMS, it's recommended to setup a remote hard drive by using NFS to store all the information in that directory (we recommend SAN disks for this task). Another complementary option is to set up two data servers to send the most 'dense' information to the 'big one' which possesses the better hard drives.
1.3 Search and Visualization
In a log collection tool, we look for two main features:
1. The search for information, filtering by date and / or source.
2. To visualize the information drawn as occurrences per defined time unit.
In the example below, we've searched for any data source which was gained from October 16 to October 17:
There are some filters you may use to select the information you intend to see. The most obvious ones are the time range and others like modules or the source of information (which is defined in the log collector within the agent) and the agent itself where information originates from.
The most important and useful field is definitely going to be the 'string search' (search in the capture). As in the above mentioned case, this ought to be a simple text string or a regular expression in form of an IP address:
As seen in the screen shot below, it looks in the interval date / time set (the last minute) to any data source, for data that "looks like" an IP, within the range 192.168.0.0/16
1.4 Agent setup
Let's see two examples to capture log information in windows and unix:
1.4.1 In Windows
module_begin module_name Eventlog_System module_type log module_logevent module_source System module_end
module_begin module_name PandoraAgent_log module_type log module_regexp C:\archivos de programa\pandora_agent\pandora_agent.log module_description This module will return all lines from the specified logfile module_pattern .* module_end
In both cases, the only difference between a monitoring module and a log source definition is this:
This new syntax, is only understood by the 5.0 agent, so, if you want to use this new feature, you need to upgrade the agents to 5.0 version.
1.4.2 Unix systems
In Unix you use a new plugin that comes with the version 5.0 agent. Its syntax is simple:
module_plugin grep_log_module /var/log/message Syslog \.\*
Similar to the log parser plugin (grep_log) grep_log_module plugin sends the processed information to the log collector with the name "syslog" as the source of the logfile. Use the regular expression \. \ * (In this case "all") as pattern when choosing which ship lines and what not.