I have a rsyslog daemon running on a server receiving and aggregating messages from a number of other servers. Occasionally, I see line written which looks like the start of a message, an ellipsis(...), and the end of another, different, message.
It doesn't appear to have anything to do with the length of the message, as longer messages get through with out problems.
I have looked through the rsyslog doco without success and searching google for ... is not useful. Have I just missed something in the doco, or is this a bug?
The elipsis is actually coming from the log4j syslog appender implementation. If the line is "too long" it will be truncated and an elipsis will be written instead.
Related
I have python beaver service running on my machine. Its configured along with logstash to push logs to kibana dashboard. For some reason beaver is not collecting logs of the services for the starting 15min. I want to debug beaver but not sure how to do so.
I tried running the command:
/usr/bin/beaver -c /etc/beaver/conf
The Output is get is
[2014-12-18 16:42:06,084] INFO Starting worker...
[2014-12-18 16:42:06,085] INFO Working...
[2014-12-18 16:42:06,092] INFO [fe01g1e15e8] - watching logfile <some-log-file>
[2014-12-18 16:42:06,092] INFO [fe01g1e15ed] - watching logfile <some-log-file>
[2014-12-18 16:42:06,093] INFO [fe01g14105c] - watching logfile <some-log-file>
[2014-12-18 16:42:06,193] INFO Starting queue consumer
The functionality is working just fine. But how do i debug on what happened to the first 15min? Also, there are no log files for beaver
I found out that the best method for debuging beaver is to work closely with the open source code.
First of all for debuging use the parameter --debug to get more log infromation and then look in the code for the parts that collects the data or look for the problematic error prints that you recieve from the debug messages. You can also add your own prints and temporarily replace the code on your server in order to understand were the problematic part might be.
From what I know, your problem can be in one of two parts, the first part consumes the data into an internal queue and the second part gets information from the queue and sends it using the selected transport method (in your case to logstash).
I already have a pull request waiting for approval that will include prints with the status of the number of messages in the queue and the number of messages transported (in debug mode) and I guess this can really help you understand what part is not working.
https://github.com/josegonzalez/python-beaver/pull/324
I am using rsyslog to relay events from a machine to Loggly (cloud log management). I have an application running on that machine that logs to the local rsyslog by using the SyslogAppender of log4net. However, since some of the events are multi-line, thus contain new lines which are then replaced by the escape sequence #012. However, I would like to replace the newlines in the message part to <br/>. I have looked at rsyslogs property replacing [1] feature but I am not really sure if this is the right way. Furthermore, changing the implementation of the application would require some effort so I would like to avoid this way. So I am looking for a way to solve this issue "outside" of my application.
Thanks in advance for any help or suggestions!
[1] http://www.rsyslog.com/doc/property_replacer.html
It seems that the #12s is getting produced by log4net - not by syslog. If you don't want to change the application, you can use sed to replace the #12 by <br/>:
sed 's/#12/\n/g' logfile
Hy!
I have a subversion server running on linux, and I want to set up a hook which checks the format of the log message.
The log message should like this:
#ID TEXT
So it sould start with a # followed by an ID (numbers only) followed by a space and a log message, which is minimun 50 chars length.
How can I do this? Oh, and I want to call some scripts after that and I want to pass the log message to the scripts, so I need the log message in a variable or something.
Thank you for your help!
when using AMQ 5.6 and starting the broker using ./activemq start...where does the stdout/stderr go?
I expected it to show up in the /data/activemq.log file, but it doesn't...is there are way around this with a tweak to the log4j or JavaServiceWrapper config perhaps?
When I start in console mode using ./activemq console, the stdout/stderr messages are displayed as expected. In particular, I need to get output from e.printStackTrace() to show up in the logs when running in this mode.
it seems to just get redirected to /dev/null...I changed the /bin/activemq script to redirect to ../data/start.log instead and sure enough, the stdout/err are there...not sure why this isn't the default behavior to be honest...
When i remember correctly, there is another file called wrapper.log. look out for it in the same dir where wrapper.conf is.
I would like to print some messages and variable values while my configuration is applied.
I would also like to separate the output of different configuration blocks visually. so I use
notify {"\n\nINSTALL TOMCAT TO $target_folder":}
as described in puppet tutorials and documentation.
Unfortunately the output does not really add readability to the whole log:
notice:
INSTALL TOMCAT TO /opt/example/uiserver
notice: /Stage[main]//Node[dev-xyz.example.com]/Tomcat[uiserver_tomcat]/Notify[
INSTALL TOMCAT TO /opt/example/uiserver]
INSTALL TOMCAT TO /opt/example/uiserver'
Problem - instead of just printing the message, puppet also outputs an annoying echo /message: defined 'message' as '. Is there any way to eliminate it?
Using withpath => false did not help.
Puppet 2.7.17.
Set --logdest to syslog.
It's console by default.
--logdest:
Where to send messages. Choose between syslog, the console, and a log
file. Defaults to sending messages to the console.
Maybe try using the notice() function instead of the notify type as per http://www.puppetcookbook.com/posts/simple-debug-messages.html
With the notice() function mesagee will be written to the puppetmaster's log instead of the client, but there won't be an echo line echo'd back.