Pandora: Documentation en: Log Monitoring
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 at 100MB a day to others where 1GB per hour is considered normal. That means: Information of such dimensions cannot be processed, normalized and stored in a database - it's simply impossible.
Until now, Pandora FMS didn't have a solution to this problem - but with Version 5, Pandora FMS Enterprise offers a solution to manage hundreds of MBs per day in the form of log files. This solution allows the same agents used for monitoring to be reused to collect information from event logs (Windows) or in the form of text-file logs. It utilizes a syntax which is very similar to the one of the current log-monitoring modules.
The logs which are going to be 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 specified 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.
Search and Visualization
In a log collection tool, we tend to 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 23 to October 24:
You're also able to utilize some filters to select the information you intend to find. 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 the information originates.
The most important and useful field is definitely 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 on the picture below, the search task looks for data which looks like an IP, within the range 192.168.0.0/16 within the defined interval date / time on any data source.
These are two examples to capture log information under Windows and UNIX:
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 item:
This new syntax is only going to be understood by the new Version 5 Agent. If you intend to use this new feature, you're required to upgrade the agents to version 5.
Under UNIX, you're going to use a new plug in that comes along with the new Agent of Pandora FMS 5. Its syntax is quite simple:
module_plugin grep_log_module /var/log/messages Syslog \.\*
Similar to the log parser plugin (grep_log), the plug in named 'grep_log_module' sends the processed information to the log collector named 'syslog' as the source of the log file. We recommend using the regular expressions \. \ * (in this case 'all') as a pattern when choosing which ship lines and which doesn't.