syslog-ng's Introduction

Overview

Modular syslog-ng configuration, with one log file per daemon or service.

The log files are stored below /var/log/syslog/<daemon>.log Log messages which aren't associated with a specific service or daemon will be logged to the catch-all /var/log/messages log file. For example, syslog-ng will create log files as seen below:

ls /var/log/syslog

acpid.log       dhcpcd.log  lightdm.log         polkitd.log  sshd.log
bluetoothd.log  dhcpd.log   NetworkManager.log  portage.log  syslog-ng.log
dbus.log        kernel.log  ntpd.log            postfix.log

Installation

Simply clone the Git repository and let /etc/syslog-ng point to the root of your cloned repository:

git clone https://github.com/stepping-stone/syslog-ng.git ~/repos/syslog-ng
mv /etc/syslog-ng /etc/syslog-ng.orig
ln -s ~/repos/syslog-ng /etc/syslog-ng
/etc/init.d/syslog-ng restart

If you're looking for a more enterprisish way to install the configuration, check out the puppet-syslogng module, which is based on this configuration. Alternatively, you can also find an ebuild for installing the configuration.

Contribution

Contributions are very welcome, simply fork our repository and send us a pull-request. If you found a bug, open an issue.

Missing daemon or service configuration

There are so many daemons out there, that we can't add all by ourself :) If you're using a software for which no configuration exists (your log messages are appended to /var/log/messages), proceed with the following basic steps to create and submit a new configuration:

Fork our repository on GitHub
Create the required configuration files:

serviceName=<NAME-OF-THE-SOFTWARE>           # For example OpenSSH, or Bluetooth daemon.
serviceProgramName=<NAME-OF-THE-SYSLOG-TAG>  # For example sshd, or bluetoothd.

# Create the syslog-ng filter 
cat << EOF > "syslog-ng.conf.d/filter.d/${serviceProgramName}.conf"
# ${serviceName} (${serviceProgramName}) filter

filter f_${serviceProgramName} { program("^${serviceProgramName}\$"); };
EOF

# Create the syslog-ng file destination
cat << EOF > "syslog-ng.conf.d/destination.d/${serviceProgramName}.conf"
# ${serviceName} (${serviceProgramName}) destination

destination d_${serviceProgramName} { file("\`syslog_dir\`/${serviceProgramName}.log"); };
EOF

# Create the syslog-ng default file log path
cat << EOF > "syslog-ng.conf.d/log.d/90_${serviceProgramName}.conf"
# ${serviceName} (${serviceProgramName}) final file log

log { source(s_log); filter(f_${serviceProgramName}); destination(d_${serviceProgramName}); flags(final); };
EOF

/etc/init.d/syslog-ng reload

Test your new config snippets, by generating a log message from your new software and see if /var/log/syslog/<serviceProgramName>.log gets created.
Commit and push your additions

git add syslog-ng.conf.d/filter.d/${serviceProgramName}.conf \
        syslog-ng.conf.d/destination.d/${serviceProgramName}.conf \
        syslog-ng.conf.d/log.d/90_${serviceProgramName}.conf

git commit -m "Adding configuration for ${serviceName} (${serviceProgramName})."

git push

Send us a pull-request.
Thank you! :)

syslog-ng's People

Contributors

Stargazers

Watchers

syslog-ng's Issues

postfix on centos

On CentOS 6.4 postfix is logging this to /var/log/messages.

Oct 18 10:58:08 localhost postfix/postfix-script[1364]: starting the Postfix mail system
Oct 18 10:58:08 localhost postfix/master[1365]: daemon started -- version 2.6.6, configuration /etc/postfix

The filter that doesn't match it looks as follows.

filter f_postfix { program("postfix"); };

Usually i would advocate that postfix users should really take care configuring their server, this would include postfix' logging configuration. With CentOS/RHEL however, postfix is started as the default sendmail wrapper as part of the distro.

Would changing this to a regex based match() be an option you would merge? I would only use the regex on the program variable so it doesn't match unrelated lines.

Thanks
Lucas

Documentation Request: Method Justification

I very much appreciate that you are freely sharing this repository and its evident that you've invested a bit of time and effort. I thought it might be helpful to document why you do are filtering messages like this in order to help people better decide if they should utilize your project. In the end, I hope this will help you gain more users instead of people re-inventing the wheel.

Please don't take this as a criticism or me advocating to change how you do things; this is merely a request to document what you feel are the advantages to your methodology.

For example, why bother listing each program separately? Why not just use $PROGRAM in the destination path?

destination files_known {
    file("/var/log/$YEAR.$MONTH.$DAY/$HOST/$PROGRAM");
};

If you are going to list program, why not have one big filter for "known" programs

filter known_program {
    program("cron") or [...]
}

source foo { [...] }
destination files_known {
  file("/var/log/$YEAR.$MONTH.$DAY/$HOST/$PROGRAM");
}
destination files_unknown {
  file("/var/log/$YEAR.$MONTH.$DAY/$HOST/unknown-$FACILITY");
}
log {
    source(foo);
    filter(known_program);
    rewrite(rewrite_program);
    destination(files_known);
    flags(final);
};
log {
    source(foo);
    destination(files_unknown);
};

stepping-stone / syslog-ng Goto Github PK

syslog-ng's Introduction

Overview

Installation

Contribution

Missing daemon or service configuration

syslog-ng's People

Contributors

Stargazers

Watchers

Forkers

syslog-ng's Issues

postfix on centos

Documentation Request: Method Justification

filter/configuration for mcelog

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent