syslog-ng is an enhanced log daemon, supporting a wide range of input and output methods: syslog, unstructured text, queueing, SQL & NoSQL.
do
rm ${NEWFILE}
done
This way once the file is read by syslog-ng it is getting deleted. here i am assuming that the file is process by syslog-ng ( which is the case for most of the time) I see all the files reaching my elasticsearch. Howerver I see below entries in log 2021-06-08T11:32:14.259750] Follow-mode file source not found, deferring open; filename='/var/log/apache2/93200/20210608/20210608-1702/20210608-170214-YL9VPvA4UO9fAg2IkuODWQAAAAI' is there any issue due to this ? i expect this will remove the file from monitoring ( hence keep the number of files well under the max-file count)
Hi @Homeshjoshi_twitter,
If I understand it correctly, the inotifywait -m -r -e close_writescript of yours will remove the file right after a process writing that file closes its fd.
Fortunately, when syslog-ng opens a file for reading, it keeps that file open. This means that if the file is deleted before it is fully processed by syslog-ng, we can still finish reading the file (The file will not really be deleted until the last FD is closed).
The only problematic scenario is when a file is deleted, but syslog-ng has not yet been able to open the file in that amount of time.
I think this is the case when you get the message you mentioned: Follow-mode file source not found
wildcard-file() source monitors files continuously, we don't close those files after processing them, so I think you either have to add a few-second delay before removing the file (in the hope syslog-ng can open it), or you should choose a different approach (a simple delay does not guarantee anything, but monitoring syslog-ng statistics (syslog-ng-ctl stats), or searching for internal debug logs that state we opened the file might actually work)
@Homeshjoshi_twitter
What I finally understand from your reply that my script is not going to work.
Adding a few-second delay might work, but it's an ugly hack, and nothing is guaranteed.
The better option (until we implement #3695) would be something that relies on the statistics of syslog-ng.
For example, it is possible to write a script that periodically checks the output of the sbin/syslog-ng-ctl query get 'src.file.*.processed' command, and removes the file only when the processed counter of the file can be found in the list, and it is greater than 0.
This should work reliably only if you do NOT re-create the same file (path) after deleting it (syslog-ng file statistics are not reset after the file is removed).
@arekm:matrix.org Hi,
The fallback flag is for processing messages that are not processed by any other normal log paths. You can not mark log_net as an "invisible" destination, but I'm pretty sure we can refactor/rephrase your configuration to achieve what you want; for example, using if-else blocks, or embedded log paths, final flags, or just filters.
Can you share all of your log paths, where s_sys is used? Exactly what messages would you like to see arrive into d_messages?
Now I'm seeing incorrect count values for suppressions messages on remote logs.
Please note that client is configured with suppress(600) and server is configured with suppress(0)
remote logs = server logs
when a message is for client, it starts suppression and looks for repeated messages.
once this repeated message steak is over, it logs "<MSG> repeated N times" and that log is also stored in server.
Now the problem I'm facing is the "repeated N times" value of N is sometimes different in server logs.
So Is there any open issue present currently? Do you know if this type of issue occurred before and fixed in later releases?
Hi @mshah618,
Now the problem I'm facing is the "repeated N times" value of N is sometimes different in server logs.
Could you elaborate on this a bit more? Did you find some inconsistencies between the client and server logs when using the suppress option?
Or do you expect a fixed amount of repetition within 600 seconds?
When a client is configured with the suppress(T) option, consecutive repetitive messages will be sent only once within that T timeframe. Please note that any non-identical message between 2 identical messages will reset the suppress counter.
After T seconds or when a non-identical message is found, the following summary will be sent to the server:Last message 'msg' repeated N times, suppressed by syslog-ng on ...
Can you share me your email id? I'll share those configs to you.
Could you share the relevant parts of your configuration publicly? More people can help you that way. :) You can remove sensitive information from the config.
If that's not possible, you can, of course, send your config to any of us in a private message.
Hi @mshah618,
Now the problem I'm facing is the "repeated N times" value of N is sometimes different in server logs.
Could you elaborate on this a bit more? Did you find some inconsistencies between the client and server logs when using the suppress option?
Or do you expect a fixed amount of repetition within 600 seconds?
I see inconsistencies between client and server logs when using suppress option.
Some times server log contains wrong number of repeated messages, some times client log contains it.
Some times client and server logs show correct, equal value.
Yeah, that might be the consequence of 2 destinations receiving messages from slightly different sources or log paths.
Could you share your client and server configs, please? You can send it as a private message here on Gitter, if you want to.
I'll summarize what we've found here, publicly.
I think some infrastructural details should be shared before moving forward with this problem. TLDR: suppress() is done on the client-side (by destinations), each destination has its own suppress counter/timer, so inconsistencies between the server and client side seems to be a configuration issue (for example, 2 different destinations are used on slightly different log paths, etc).
ok I figured it out. If I have it like this:
log {
source(s_myservers_tls);
filter{program(apache_error)};
parser(p_apache_error);
rewrite(r_rewrite_subst);
destination(df_new_apache_error);
};will the rewrite be applied AFTER the previous filter() directive? (so will the filter() be respected? Because with rewrite being done, the filter's input data would change and not work for this given filter)
Hello @plantroon ,
the statements in the Syslog-ng configuration file are "executed" from top down. So the filter will be applied to the original PROGRAM field. And the later rewrite will only affect the following destination statement.
However I am not sure about your "p_apache_error" parser. If your parser also process/alters the PROGRAM field, you might want to put it prior your filter statement.
Thanks :)
However I am not sure about your "p_apache_error" parser. If your parser also process/alters the PROGRAM field, you might want to put it prior your filter statement.
if I understand correctly, only the message itself is available to the parser, no? Therefore it does not work with the program field... at least mine does not. I use ewmm syslog driver if that has anything to do with it.
First things first, I think your setup will work as is.
A little bit of explanation, why your parser only receives the message part:
Every parser has a "template" option, with a default $MESSAGE value. The template option defines the input of the parser. Since evmm already parsed the incoming message as a apache log, your PROGRAM field, and other apache related macros are already filled.
(Usually if somebody writes a custom parser, they use "flags(no-parse) on the source side, which combined with the default MESSAGE value for the template, will result getting EVERYTHING)
hey there !
i'm trying to send logs from syslog-ng to elasticsearch(basically using syslog-ng as a proxy) and while this config perfectly works on my ubuntu 20.04 when i try to launch it inside docker it doesn't send anything
syslog-ng.conf
@version: 3.31
@include "scl.conf"
source s_network {
network(
port(514)
transport("tcp")
);
};
destination d_es{
elasticsearch-http(
index("syslog-ng")
url("https://")
user("admin")
password("password")
type("")
tls( peer-verify(no) )
);
};
log {
source(s_network);
destination(d_es);
};things i've tried already :
- launching container with
--privilegedflag - enabling verbose via
syslog-ng-ctlmode - barely any new messages
i'm using docker image 3.31.2-buster aka latest
could anyone please help me with that one ?
Hello! Naive question: are you sure that your container/syslog-ng indeed receives any log messages? (Exposing the 514 port, or using host network)
I am thinking about the Syslog-ng debug messages with the beginning of the "Incoming log entry" text.
i.e.: [2021-07-21T16:41:59.091937] Incoming log entry; line='<165>1 2003-10-11T22:14:15.003Z 1.2.3.4 evntslog - ID47 [example123456789
hi!
thank you for getting back to me
it does receive log entries, i've tried both with simple network requests and setting it up to collect logs from syslog + making logs entries via logger
do i enable verbose mode the right way?
root@6b6a564571aa:/# syslog-ng-ctl verbose --set=on
VERBOSE=1