0

I'm using rsyslog to send access & error log data to a remote server. The interface is in place, but I'm getting an extra bit of text in the outbound log data that isn't included in /var/log/http/access_log.

Here's a snippet from an access_log entry. 1.1.1.1 is my IP address, and 99.99.99.99 is the appserver's IP.

1.1.1.1 99.99.99.99 - - [29/Jun/2015:11:57:58 -0400] "GET /somepage.php HTTP/1.1" 200 443 20

Corresponding outbound log data sent by rsyslog using
tcpdump -vv -s 0 -A dst port 514 from the appserver (sending machine):

<173>Jun 29 11:57:58 appserver acoder: 1.1.1.1 99.99.99.99 - - [29/Jun/2015:11:57:58 -0400] "GET /somepage.php HTTP/1.1" 200 443 20

How do I remove the first few segments of the outbound log data? Specifically:

Jun 29 11:57:58 appserver acoder: 

I'd like that string removed so the only thing that is being sent is exactly what is in the access_log shown in the first quote above.

httpd.conf

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
# LogLevel warn
LogLevel debug

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).

LogFormat "%h %A %l %u %t \"%r\" %>s %p %b" combined
LogFormat "%h %A %l %u %t \"%r\" %>s %p %b" common

LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

rsyslog.conf

# rsyslog v5 configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)

#### GLOBAL DIRECTIVES ####

# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf


#### RULES ####

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.

local5.*;local6.* @syslog.my.organization.tld:514

# ### end of the forwarding rule ###
0

The parts that you're trying to remove are written by the receiving rsyslog daemon, not by the sender, and cannot be removed. They're part of the log format for rsyslog.

  • I'm viewing output sent from the app server with tcpdump -vv -s 0 -A dst port 514. So you are saying that the rsyslog log format cannot be edited beyond what is done in httpd.conf's LogFormat section? – a coder Jun 29 '15 at 17:53
  • Yeah this answer is not fully correct. I changed the log output by using $template myFormat,"%msg%\n" and local5.*;local6.* @syslog.my.organization.tld:514;myFormat. Still have a bit of tweaking to do, but the text Jun 29 11:57:58 appserver acoder: is now gone. – a coder Jun 29 '15 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.