Post installation Core
RiverMuse Core 4.1.7
|
As a next step after installation, RiverMuse recommends you familiarize yourself with the following sections and undertake any necessary configuration to customize your system.
Installation tree
The root of the installation tree is /opt/rivermuse.
|
|
Reading man pages
In order to collect the man pages for omosd, yarpd, and rsyslog.conf, you need to configure the $MANPATH environment variable.
- Append the RiverMuse manual page path to the existing manual page path by typing the following:
Flexible configuration
RiverMuse offers flexible configuration of the omosd and yarpd daemons including:
- The ability to cap the growth of each log file, thus, building in roll over functionality.
- Control the level of the log messages.
- Details on how to connect to the rivermuse database.
- Details on inter-process communication.
etc directory
Under the etc directory, there are a number of configuration (.conf) files:
| File |
Description |
| omosd.xml |
The configuration file for omosd. |
| logger-omosd.conf |
Configures the logout of omosd. |
| yarpd.xml |
The configuration file for omosd. |
| logger-yarpd.conf |
Configures the logout of yarpd. |
How to configure log messages
You can configure system log messages in logger-omosd.conf and logger-yarpd.conf:
- Each message in the code has a predefined logger level. Loggers may be assigned any of the following levels: TRACE, DEBUG, INFO, WARN, ERROR and FATAL.
- In this instance, the gate determines that only messages with level WARNING or above will be logged.
- The location of the output is /var/log/omosd.root.log. If you want to examine what omosd is doing, you will need to design your own alert rules; therefore, you should start looking in this file.
If an issue arises, you can change the following to DEBUG:
- Level DEBUG provides detailed debug information.
For further information on logging please refer to http://logging.apache.org/log4cxx/index.html.
Reading log files to write alert rules
The following example code extract should assist you with reading and understanding a log file; thereby, helping you write an alert rule. The code extract shows a message coming from rsyslog. Be advised the line numbering is subject to change, but the filenames will remain the same.
To assist you in writing alert rules, in the /var/log/omosd.root.log, you need to use the fields in the INPUT section as shown in the following example:
- You can write an alert rule making use of each field name and its corresponding value, i.e., agent_name = syslog, alert_severity = 6. For further information on writing alert rules refer to the Alert Rules GUI.
The following extract shows the rules looking to match against the values stated in the INPUT fields:
- The logging level is set at INFO.
- The fact Unknown token is returned means the rule has failed to match.
When the values in the INPUT fields are matched with the alert rule, the rule then fires:
The following extract shows the events being inserted into the rivermuse database:
Configuring omosd.xml
The omosd.xml is the primary configuration for the omosd daemon. Most importantly, it contains details on how to communicate with omosd via SOAP used in communication with rsyslogd.
To configure rsyslogd to talk to omosd you must configure the port value:
- The port address in this instance is 20080.
The configuration for talking to MySQL. By default, the configuration is set to talk to MySQL on the localhost. You will need to modify this section for distributed installations.
- The default user name to talk to MySQL is root.
- The database value is set to the rivermuse database.
Configuring queue sizes and thread values
You can configure the number of elements for an omosd queue by configuring the max_size value as shown in the code insert below. If max_size is not defined, or, it equals 0, the number of elements in the queue is unlimited. Be advised, max_size has a minimum number of 4096 elements.
In omosd there are two pools of work threads: one of them is for incoming data from agents; and, the other pool relates to processing data with rules, and sending the data into a database. You can configure the number of work threads in each pool by configuring <input value> and {{<output value> as shown in the code insert below. Be advised, the minimum value is 1, and the maximum value is 100.
rsyslog directory
After you install the .rpms the instances-available directory contains the following:
| file |
objective |
| omos.conf |
to tell the system to talk to omosd. |
| solaris.conf |
special configuration for Solaris installations. |
| snare.conf |
to communicate with a Snare agent on a Windows machine. |
| sendmail.conf |
to monitor sendmail messages. |
| http_access.conf |
to monitor who is accessing your webserver. |
On systems that do not have kernel logging, you must enable omos.conf:
How to enable instances
- Login as the root user.
- In the instances-enabled directory, create a soft link to omos.conf:
- To enable any of the other instances, follow the procedure documented above, replacing omos.conf with the appropriate .conf.
To pick up the changes in configuration you need to run rsyslogctl. For each enabled configuration, the system will start a separate instance of rsyslogd-lite; therefore, each rsyslog is using a different configuration file.
