Skip to content

Latest commit

 

History

History
208 lines (149 loc) · 7.94 KB

README.md

File metadata and controls

208 lines (149 loc) · 7.94 KB
Raw

syslog

The syslog plugin is a Cacti plugin that has been around for more than a decade. It was inspired by the 'aloe' and 'h.aloe' plugins originally developed by the Cacti users sidewinder and Harlequin in the early 2000's. As you will be able to see from the ChangeLog, it has undergone several changes throughout the years, and remains, even today when you have enterprise offering from both Elastic and Splunk, remains a relevant plugin for small to medium sized companies.

It provides a simple Syslog event search an Alert generation and notification interface that can generate both HTML and SMS messages for operations personnel who wish to receive notifications inside of a data or network operations center.

When combined by the Linux SNMPTT package, it can be converted into an SNMP Trap and Inform receiver and notification engine as the SNMPTT tool will receive SNMP Traps and Informs and convert them into Syslog messages on your log server. These syslog messages can then be consumed by the syslog plugin. So, this tool is quite handy.

For log events that continue to be generated frequently on a device, such as smartd's feature to notify every 15 minutes of an impending drive failure, can be quieted using syslog's 'Re-Alert' setting.

Core Features

  • Message filtering

  • Message searching

  • Message Alerting

  • Alert Levels of System and Host

  • Alert Methods of Individual and Threshold Based

  • Message Removal Rules to Delete or Hide Messages

  • Filter Messages by Cacti Graph window from Cacti's Graph View pages

  • Use of native MySQL and MariaDB database partitioning for larger installs

  • Remote Log Server connection capabilities

  • Custom column mappings between Remote Log Server and required Syslog columns

  • Ability to Generate Tickets to Ticketing Systems through Script Execution

  • Ability to run alert specific commands at Alert and Re-alert times

Important Version 4.0 Release Notes

In prior releases of Syslog, the Individual Alert Method would send an Email, open a ticket or run a command per line in the Syslog that matches the pattern. However, in Syslog Version 4, if you want an alert per Host, you will have to move your Alerts from the System Level to the Host Level as System Level Alerts will generate one command execution for all matching messages.

Installation

To install the syslog plugin, simply copy the plugin_syslog directory to Cacti's plugins directory and rename it to simply 'syslog'. Once you have done this, goto Cacti's Plugin Management page, and Install and Enable the plugin. Once this is complete, you can grant users permission to view syslog messages, as well as create Alert, Removal and Report Rules.

Note: You must rename config.php.dist in the syslog plugin directory to config.php and make changes there for the location of the database, user, password, and host. This is especially important if you are using a remote logging database server.

If you are upgrading to 2.0 from a prior install, you must first uninstall syslog and insure both the syslog, syslog_removal, and syslog_incoming tables are removed, and recreated at install time.

In addition, the rsyslog configuration has changed in 2.5. So, for example, to configure modern rsyslog for Cacti, you MUST create a file called cacti.conf in the /etc/rsyslog.d/ directory that includes the following:

You have two options for storing syslog information you can either use the existing Cacti Database or use a dedicated database for syslog as syslog databases especially for large networks can grow pretty quick it may be wise to create a dedicated database. To use a dedicated DB first create a database in mysql and assign a user you will then change

$use_cacti_db = true;

to

``console $use_cacti_db = false;


You will also need to ensure the cacti user is granted select on the syslog database

```shell
GRANT SELECT ON syslog.* TO 'cacti'@'localhost';

Cacti Configuration for RSYSLOG

Edit /etc/rsyslog.d/cacti.conf

$ModLoad imudp
$UDPServerRun 514
$ModLoad ommysql

$template cacti_syslog,"INSERT INTO syslog_incoming(facility_id, priority_id, program, logtime, host, message) \
  values (%syslogfacility%, %syslogpriority%, '%programname%', '%timegenerated:::date-mysql%', '%HOSTNAME%', TRIM('%msg%'))", SQL

*.* >localhost,my_database,my_user,my_password;cacti_syslog

For version below 2.0 it should be:

$ModLoad imudp
$UDPServerRun 514
$ModLoad ommysql

$template cacti_syslog,"INSERT INTO syslog_incoming(facility_id, priority_id, program, logtime, host, message)
values (%syslogfacility%, %syslogpriority%, '%programname%', '%timegenerated:::date-mysql%', '%HOSTNAME%', TRIM('%msg%'))", SQL

. >localhost,my_database,my_user,my_password;cacti_syslog

For version 2.4 and above it should be:

module(load="ommysql")
action(type="ommysql" server="localhost" serverport="3306"
db="syslogDB" uid="userID" pwd="passwdID")

$template cacti_syslog,"INSERT INTO syslog_incoming(facility_id, priority_id, program, logtime, host, message)
values (%syslogfacility%, %syslogpriority%, '%programname%', '%timegenerated:::date-mysql%', '%HOSTNAME%', TRIM('%msg%'))", SQL

For CentOS/RHEL systems you will all need to install the rsyslog-mysql package

yum install rsyslog-mysql
systemctl resatrt rsyslog

If you are upgrading to version 2.5 from an earlier version, make sure that you update this template format and restart rsyslog. You may loose some syslog data, but doing this in a timely fashion, will minimize data loss.

Ensure you restart rsyslog after these changes are completed. Other logging servers such as Syslog-NG are also supported with this plugin. Please see some additional documentation here: Cacti Documentation Site

We are using the pure integer values that rsyslog provides to both the priority and facility in this version syslog, which makes the data collection must less costly for the database. We have also started including the 'program' syslog column for searching and storage and alert generation.

To setup log forwarding from your network switches and routers, and from your various Linux, UNIX, and other operating system devices, please see their respective documentation.

Finally, it's important, especially in more recent versions of MySQL and MariaDB to set a correct SQL Mode. These more recent SQL's prevent certain previously allowable syntax such as an empty data and certain group by limitations in the SQL itself. Therefore, you need to ensure that the SQL mode of the database is correct. To do this, first start by editing either /etc/my.cnf or /etc/my.cnf.d/server.cnf and inserting the SQL mode variable into the database configuration. For example:

[mysqld]
sql_mode=NO_ENGINE_SUBSTITUTION,NO_AUTO_CREATE_USER

After this change, you should log into the mysql server and run the following command:

mysql> show global variables like 'sql_mode';

And ensure that it matches the setting that you placed in the database configuration. If it does not, please search for the configuration that is making this SQL mode other than what you required. More recent versions of MySQL and MariaDB will source multiple database configuration files.

Possible Bugs and Feature Enhancements

Bug and feature enhancements for the syslog plugin are handled in GitHub. If you find a first search the Cacti forums for a solution before creating an issue in GitHub.

Authors

The syslog plugin has been in development for well over a decade with increasing functionality and stibility over that time. There have been several contributors to thold over the years. Chief amongst them are Jimmy Conner, Larry Adams, SideWinder, and Harlequin. We hope that version 2.0 and beyond are the most stable and robust versions of syslog ever published. We are always looking for new ideas. So, this won't be the last release of syslog, you can rest assured of that.

Copyright (c) 2004-2024 - The Cacti Group, Inc.