Okay, my syslog-ng instance died at some point last night and because I don't have it setup properly for respawning... Can anyone running syslog-ng on AIX 5.* give me some tips for this? I'm feeding pipes so i have to start instances of SEC as soon as I start syslog-ng - but the SEC scripts appear to "close" so if they're configured to respawn I'll have 2000 instances of them in an hour.
Net-SNMP has critical process monitoring and might have a mechanism to auto-correct a non-sufficient "syslog-ng" process count. Right now we just having it blast a SNMP trap to our NOC. I don't think I've ever heard of an syslog daemon running inside of any daemontools setup, though. ~BAS On Thu, 19 Oct 2006, Brian Loe wrote:
Okay, my syslog-ng instance died at some point last night and because I don't have it setup properly for respawning...
Can anyone running syslog-ng on AIX 5.* give me some tips for this?
I'm feeding pipes so i have to start instances of SEC as soon as I start syslog-ng - but the SEC scripts appear to "close" so if they're configured to respawn I'll have 2000 instances of them in an hour. _______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "...from back in the heady days when "helpdesk" meant nothing, "diskquota" meant everything, and lives could be bought and sold for a couple of pages of laser printout - and frequently were."
On Tue, 2006-10-24 at 19:13 -0400, Brian A. Seklecki wrote:
On Thu, 19 Oct 2006, Brian Loe wrote:
Okay, my syslog-ng instance died at some point last night and because I don't have it setup properly for respawning...
Can you elaborate on this problem? syslog-ng dies or just some maintenance script stopped it, or? -- Bazsi
On 10/25/06, Balazs Scheidler <bazsi@balabit.hu> wrote:
On Tue, 2006-10-24 at 19:13 -0400, Brian A. Seklecki wrote:
On Thu, 19 Oct 2006, Brian Loe wrote:
Okay, my syslog-ng instance died at some point last night and because I don't have it setup properly for respawning...
Can you elaborate on this problem? syslog-ng dies or just some maintenance script stopped it, or?
Unfortunately, no. I haven't been able to figure out why it died - and this is the only time it has died in the month or so I've been running it. The issue, though, is that if it dies, I have no way to programmaticly start it again without user intervention (and those SEC instances) on this system. That's why I was hoping there were some AIX admins that have built or edited rc, init and/or other scripts for syslog-ng. That won't help with the SEC scripts but I'll deal with that later - at least I'd still have the data.
I run syslog-ng under daemontools on a couple loghosts where I don't want it down for more than a second. I already have cfengine install daemontools on all my systems anyways, so it is trivial for me to automate that part as well. The only problem is that daemontools comes up after all the rc scripts, which leaves you without logging during all of startup. Workable solution is to still have an rc script that starts syslog and have the daemontools run script kill off any already running syslog-ng daemons when it comes up later. Might be overkill to supervise it in the first place - judgement call I suppose. -- Nate Campi
Got a sample rc script? On 10/25/06, Nathan Campi <nate@campin.net> wrote:
Workable solution is to still have an rc script that starts syslog and have the daemontools run script kill off any already running syslog-ng daemons when it comes up later. Might be overkill to supervise it in the first place - judgement call I suppose.
-- Nate Campi
I had this all ready to go: #!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin if [ -f /var/run/syslog-ng.pid ] then # make sure the PID in the pidfile is actually running and is # syslog-ng, not something else if ps -ef|grep " `cat /var/run/syslog-ng.pid ` " | grep -v grep | grep syslog-ng >/dev/null then echo "already have a syslog-ng daemon running, killing it now" kill `cat /var/run/syslog-ng.pid ` fi fi exec /sbin/syslog-ng -F ...then I realized that syslog-ng doesn't update /var/run/syslog-ng.pid when running in the foreground. The sshd from openssh does, so I have logic like the above in my ssh run script called from daemontools. I suppose you'll just have to call pkill before the exec of syslog-ng. :( On Wed, Oct 25, 2006 at 10:55:30AM -0500, Brian Loe wrote:
Got a sample rc script?
On 10/25/06, Nathan Campi <nate@campin.net> wrote:
Workable solution is to still have an rc script that starts syslog and have the daemontools run script kill off any already running syslog-ng daemons when it comes up later. Might be overkill to supervise it in the first place - judgement call I suppose.
-- Nate Campi
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- Nate "UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a boot partition virus." - Peter H. Coffin .
Nathan Campi wrote:
I had this all ready to go:
#!/bin/sh PATH=/sbin:/usr/sbin:/bin:/usr/bin
if [ -f /var/run/syslog-ng.pid ] then # make sure the PID in the pidfile is actually running and is # syslog-ng, not something else if ps -ef|grep " `cat /var/run/syslog-ng.pid ` " | grep -v grep | grep syslog-ng >/dev/null then echo "already have a syslog-ng daemon running, killing it now" kill `cat /var/run/syslog-ng.pid ` fi fi
exec /sbin/syslog-ng -F
...then I realized that syslog-ng doesn't update /var/run/syslog-ng.pid when running in the foreground. The sshd from openssh does, so I have logic like the above in my ssh run script called from daemontools. I suppose you'll just have to call pkill before the exec of syslog-ng. :(
Or when running in the foreground, make the PID file from the script, rather than syslog-ng doing it. Evan.
On Wed, Oct 25, 2006 at 10:55:30AM -0500, Brian Loe wrote:
Got a sample rc script?
On 10/25/06, Nathan Campi <nate@campin.net> wrote:
Workable solution is to still have an rc script that starts syslog and have the daemontools run script kill off any already running syslog-ng daemons when it comes up later. Might be overkill to supervise it in the first place - judgement call I suppose.
-- Nate Campi
syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- Evan Rempel erempel@uvic.ca Senior Programmer Analyst 250.721.7691 Computing Services University of Victoria
That won't work since you need to exec syslog-ng. I'd have recommeneded that if it was feasible. :( -- Nate Campi
On Wed, 2006-10-25 at 12:24 -0700, Nathan Campi wrote:
That won't work since you need to exec syslog-ng. I'd have recommeneded that if it was feasible. :(
if you exec syslog-ng from the script, then the pid of syslog-ng will match that of the script. E.g. the contents of $$ should be ok. -- Bazsi
On Thu, Oct 26, 2006 at 11:38:53AM +0200, Balazs Scheidler wrote:
On Wed, 2006-10-25 at 12:24 -0700, Nathan Campi wrote:
That won't work since you need to exec syslog-ng. I'd have recommeneded that if it was feasible. :(
if you exec syslog-ng from the script, then the pid of syslog-ng will match that of the script. E.g. the contents of $$ should be ok.
Duh, my bad. Thanks Bazsi. I wrote that message on my phone while walking down the street. I'll have to think before I email next time. :( -- Nate "Few things are harder to put up with than the annoyance of a good example." - Pudd'nhead Wilson's Calendar(1894) - Samuel Clemens
Please bear with me. This is a little involved. We have a bunch of servers, but I am only focusing on one today. It logs everything to two syslog-ng central servers. A really simple config file --------- options { sync(0); log_fifo_size(50000); use_fqdn(yes); keep_hostname(no); chain_hostnames(yes); time_reap(60); time_reopen(5); }; source local { unix-stream("/dev/log" max-connections(200)); file("/proc/kmsg" log_prefix("kernel: ")); internal(); }; template standard_file { template("$ISODATE $FULLHOST $FACILITY.$LEVEL $MESSAGE\n"); template_escape(no); }; destination syslog { file("/var/log/syslog.$YEAR$MONTH$DAY.000000" owner("root") group("syslogs") perm(0640) template(standard_file)); }; destination syslogServer1 { tcp("server1" log_fifo_size(50000) ); }; destination syslogServer2 { tcp("server2" log_fifo_size(50000) ); }; log { source(local); destination(syslog); destination(syslogServer1); destination(syslogServer2); }; ----------------- Anyhow. On the two central servers, I different numbers of records in the files, and the statistics on the sender show 2008-03-04T23:26:38-08:00 local@caribou.comp.uvic.ca syslog.info syslog-ng[3391]: Log statistics; dropped='tcp(AF_INET(server2:514))=0', dropped='tcp(AF_INET(server1:514))=14690649', processed='center(queued)=53993217', processed='center(received)=17997739', processed='destination(syslogServer2)=17997739', processed='destination(syslogServer1)=17997739', processed='destination(syslog)=17997739', processed='source(local)=17997739' The problem is that the files on disk show caribou 16257954 server1 1742054 server2 965475 and that just doesn't add up. Neither server shows any dropped messages. I know that the statistics miss some time at the beginning of the day and at the end of the day, but the numbers don't even come close. Caribou stats show that no messages are dropped to server2, and lots dropped to server1, however, server2 actually wrote more messages to disk. Server 1 is also about 30% faster than server2. I am willing to listen to any explanation, but I am beginning to think that the statistics that are logged are wrong. Comments?
Hi,
Anyhow. On the two central servers, I different numbers of records in the files, and the statistics on the sender show
2008-03-04T23:26:38-08:00 local@caribou.comp.uvic.ca syslog.info syslog-ng[3391]: Log statistics; dropped='tcp(AF_INET(server2:514))=0', dropped='tcp(AF_INET(server1:514))=14690649', processed='center(queued)=53993217', processed='center(received)=17997739', processed='destination(syslogServer2)=17997739', processed='destination(syslogServer1)=17997739', processed='destination(syslog)=17997739', processed='source(local)=17997739'
Please note that these numbers are aggregated, so these show the amount of messages arriving to/ leaving syslog-ng since it has been started.
The problem is that the files on disk show
caribou 16257954 server1 1742054 server2 965475
and that just doesn't add up. Neither server shows any dropped messages.
I think you misunderstood what dropped means. Dropped stands for messages which were undeliverable (maybe the TCP connection was broken you can check the internal messages of syslog-ng for such problems) so dropped messages never reached server1 or server2.
I know that the statistics miss some time at the beginning of the day and at the end of the day, but the numbers don't even come close.
The statistics shows everything which reached syslog-ng.
Caribou stats show that no messages are dropped to server2, and lots dropped to server1, however, server2 actually wrote more messages to disk. Server 1 is also about 30% faster than server2.
As I wrote above when the report shows that a destination had more dropped messages then that server received fewer messages than the other. Using the numbers above: destination(syslogServer1) processed 17997739 while the TCP destination dropped 14690649 messages. Although the TCP destination could be used by multiple destinations I guess destination(syslogServer1) and TCP(syslog1) could be mapped. This means that 3307090 messages were delivered to syslogServer1. And as this is still an aggregated number you should calculate the number of messages starting from the time when the central log server has been started so there is a chance that you have to check multiple logfiles on your servers because the period you're interested in may span multiple days. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Geller, Sandor (IT) wrote:
Hi,
Anyhow. On the two central servers, I different numbers of records in the files, and the statistics on the sender show
2008-03-04T23:26:38-08:00 local@caribou.comp.uvic.ca syslog.info syslog-ng[3391]: Log statistics; dropped='tcp(AF_INET(server2:514))=0', dropped='tcp(AF_INET(server1:514))=14690649', processed='center(queued)=53993217', processed='center(received)=17997739', processed='destination(syslogServer2)=17997739', processed='destination(syslogServer1)=17997739', processed='destination(syslog)=17997739', processed='source(local)=17997739'
Please note that these numbers are aggregated, so these show the amount of messages arriving to/ leaving syslog-ng since it has been started.
Yes, I have taken the first statistic in the day and subtracted if from the last statistic in the day. There is some time between 00:00 and the first statistic, and the last statistic and 23:59.999... This time will total the interval between statistics. This is what I meant by "the statistics miss some time in the day."
The problem is that the files on disk show
caribou 16257954 server1 1742054 server2 965475
and that just doesn't add up. Neither server shows any dropped messages.
I think you misunderstood what dropped means. Dropped stands for messages which were undeliverable (maybe the TCP connection was broken you can check the internal messages of syslog-ng for such problems) so dropped messages never reached server1 or server2.
I didn't misunderstand this. The source server stats show 17997739 messages queued, 14690649 dropped to the syslogServer1 which means that 3307090 were delivered. SyslogServer1 stats report that no messages were dropped, but countinmg of log lines in the files on SyslogServer1 from caribou only totals 1742054. What happened to the other 1565036. Even worse, the syslog-ng stats on caribou report 0 drops to syslogServer2 destination, but it only recored 965475 message in its files. Where did the other 15292479 messages go? I can't loose 15292479 without having any reporting on it.
Caribou stats show that no messages are dropped to server2, and lots dropped to server1, however, server2 actually wrote more messages to disk. Server 1 is also about 30% faster than server2.
As I wrote above when the report shows that a destination had more dropped messages then that server received fewer messages than the other.
I agree, so where did all of the messages for syslogServer2 go?
Using the numbers above: destination(syslogServer1) processed 17997739 while the TCP destination dropped 14690649 messages. Although the TCP destination could be used by multiple destinations I guess destination(syslogServer1) and TCP(syslog1) could be mapped. This means that 3307090 messages were delivered to syslogServer1. And as this is still an aggregated number you should calculate the number of messages starting from the time when the central log server has been started so there is a chance that you have to check multiple logfiles on your servers because the period you're interested in may span multiple days.
I take this into account by taking the difference between the first and last statistic record in each day. It misses a little, but not much. Evan.
I find it particularly odd that caribou itself, the originator, has a different count on its local log file than is reported by syslog-ng statistics for destination(syslog).
processed='source(local)=17997739' processed='destination(syslog)=17997739',
The problem is that the files on disk show caribou 16257954
How did you measure the "files on disk show" value? "wc -l" of a log file? "grep -c"? Other?
Fegan, Joe wrote:
I find it particularly odd that caribou itself, the originator, has a different count on its local log file than is reported by syslog-ng statistics for destination(syslog).
processed='source(local)=17997739' processed='destination(syslog)=17997739',
The problem is that the files on disk show caribou 16257954
How did you measure the "files on disk show" value? "wc -l" of a log file? "grep -c"? Other?
I mean "grep -c" for the host in question. -- Evan Rempel erempel@uvic.ca Senior Programmer Analyst 250.721.7691 Computing Services University of Victoria
On Wed, 2008-03-05 at 11:50 -0800, Evan Rempel wrote:
Please bear with me. This is a little involved.
We have a bunch of servers, but I am only focusing on one today. It logs everything to two syslog-ng central servers. A really simple config file
--------- options { sync(0); log_fifo_size(50000); use_fqdn(yes); keep_hostname(no); chain_hostnames(yes); time_reap(60); time_reopen(5); };
source local { unix-stream("/dev/log" max-connections(200)); file("/proc/kmsg" log_prefix("kernel: ")); internal(); };
template standard_file { template("$ISODATE $FULLHOST $FACILITY.$LEVEL $MESSAGE\n"); template_escape(no); };
destination syslog { file("/var/log/syslog.$YEAR$MONTH$DAY.000000" owner("root") group("syslogs") perm(0640) template(standard_file)); };
destination syslogServer1 { tcp("server1" log_fifo_size(50000) ); }; destination syslogServer2 { tcp("server2" log_fifo_size(50000) ); };
log { source(local); destination(syslog); destination(syslogServer1); destination(syslogServer2); }; -----------------
Anyhow. On the two central servers, I different numbers of records in the files, and the statistics on the sender show
2008-03-04T23:26:38-08:00 local@caribou.comp.uvic.ca syslog.info syslog-ng[3391]: Log statistics; dropped='tcp(AF_INET(server2:514))=0', dropped='tcp(AF_INET(server1:514))=14690649', processed='center(queued)=53993217', processed='center(received)=17997739', processed='destination(syslogServer2)=17997739', processed='destination(syslogServer1)=17997739', processed='destination(syslog)=17997739', processed='source(local)=17997739'
The problem is that the files on disk show
caribou 16257954 server1 1742054 server2 965475
and that just doesn't add up. Neither server shows any dropped messages. I know that the statistics miss some time at the beginning of the day and at the end of the day, but the numbers don't even come close. Caribou stats show that no messages are dropped to server2, and lots dropped to server1, however, server2 actually wrote more messages to disk. Server 1 is also about 30% faster than server2.
I am willing to listen to any explanation, but I am beginning to think that the statistics that are logged are wrong.
I know about one possible bug that might explain this: as long as the _first_ connection to a TCP destination is not established, dropped messages are not counted. E.g. the dropped counter is allocated for a destination when the first connection is established. So if server2 was down when syslog-ng started and server1 was up, syslog-ng might not count dropped messages towards server2 in the initial period. Does that sound possible? -- Bazsi
Balazs Scheidler wrote:
On Wed, 2008-03-05 at 11:50 -0800, Evan Rempel wrote:
Please bear with me. This is a little involved.
We have a bunch of servers, but I am only focusing on one today. It logs everything to two syslog-ng central servers. A really simple config file
--------- options { sync(0); log_fifo_size(50000); use_fqdn(yes); keep_hostname(no); chain_hostnames(yes); time_reap(60); time_reopen(5); };
source local { unix-stream("/dev/log" max-connections(200)); file("/proc/kmsg" log_prefix("kernel: ")); internal(); };
template standard_file { template("$ISODATE $FULLHOST $FACILITY.$LEVEL $MESSAGE\n"); template_escape(no); };
destination syslog { file("/var/log/syslog.$YEAR$MONTH$DAY.000000" owner("root") group("syslogs") perm(0640) template(standard_file)); };
destination syslogServer1 { tcp("server1" log_fifo_size(50000) ); }; destination syslogServer2 { tcp("server2" log_fifo_size(50000) ); };
log { source(local); destination(syslog); destination(syslogServer1); destination(syslogServer2); }; -----------------
Anyhow. On the two central servers, I different numbers of records in the files, and the statistics on the sender show
2008-03-04T23:26:38-08:00 local@caribou.comp.uvic.ca syslog.info syslog-ng[3391]: Log statistics; dropped='tcp(AF_INET(server2:514))=0', dropped='tcp(AF_INET(server1:514))=14690649', processed='center(queued)=53993217', processed='center(received)=17997739', processed='destination(syslogServer2)=17997739', processed='destination(syslogServer1)=17997739', processed='destination(syslog)=17997739', processed='source(local)=17997739'
The problem is that the files on disk show
caribou 16257954 server1 1742054 server2 965475
and that just doesn't add up. Neither server shows any dropped messages. I know that the statistics miss some time at the beginning of the day and at the end of the day, but the numbers don't even come close. Caribou stats show that no messages are dropped to server2, and lots dropped to server1, however, server2 actually wrote more messages to disk. Server 1 is also about 30% faster than server2.
I am willing to listen to any explanation, but I am beginning to think that the statistics that are logged are wrong.
I know about one possible bug that might explain this: as long as the _first_ connection to a TCP destination is not established, dropped messages are not counted.
E.g. the dropped counter is allocated for a destination when the first connection is established.
So if server2 was down when syslog-ng started and server1 was up, syslog-ng might not count dropped messages towards server2 in the initial period.
Does that sound possible?
It does sound possible, but I can't really confirm this. We have 17 sysadmin making changes to 25 different network segments, firewall etc, and on top of that we just moved one of our two syslog servers to a different new data center with all of the accompanying firewall issues that go with 30 new subnets being rolled out at once :-( All I really wonder now is "in what version of syslog-ng has/was this issue addressed?" Evan. -- Evan Rempel erempel@uvic.ca Senior Programmer Analyst 250.721.7691 Computing Services University of Victoria
On Wed, 2008-03-12 at 09:36 -0700, Evan Rempel wrote:
Balazs Scheidler wrote:
On Wed, 2008-03-05 at 11:50 -0800, Evan Rempel wrote:
Please bear with me. This is a little involved.
I know about one possible bug that might explain this: as long as the _first_ connection to a TCP destination is not established, dropped messages are not counted.
E.g. the dropped counter is allocated for a destination when the first connection is established.
So if server2 was down when syslog-ng started and server1 was up, syslog-ng might not count dropped messages towards server2 in the initial period.
Does that sound possible?
It does sound possible, but I can't really confirm this. We have 17 sysadmin making changes to 25 different network segments, firewall etc, and on top of that we just moved one of our two syslog servers to a different new data center with all of the accompanying firewall issues that go with 30 new subnets being rolled out at once :-(
All I really wonder now is "in what version of syslog-ng has/was this issue addressed?"
It was not fixed yet, my collegue diagnosed it in the previous weeks, but I did not get around to fix that yet. -- Bazsi
Another instance of dropped messages, but all statics records from syslog-ng indicate that no messages were dropped. Here is the logging path Server C - syslog-ng 2.0.8 - file destination - tcp destination A - tcp destination B Server A - syslog-ng 2.0.8 Linux 2.6.x - tcp source - pipe destination Server A - syslog-ng 2.0.8 linux 2.6.x - pipe source with flow-control - file destination Server B - syslog-ng 2.0.8 Linux 2.6.x - tcp source - pipe destination Server B - syslog-ng 2.0.8 linux 2.6.x - pipe source with flow-control - file destination Server C logged 608955 messages Server A logged 351502 messages Server B logged 179874 messages None of the servers record any dropped messages. syslog-ng does not report dropped messages on file destinations, but with the flow-control any drops should occur at the server that writes to the pipe. Anyone want to propose an explanation? Evan
On Wed, 2008-03-26 at 09:46 -0700, Evan Rempel wrote:
Another instance of dropped messages, but all statics records from syslog-ng indicate that no messages were dropped.
Here is the logging path
Server C - syslog-ng 2.0.8 - file destination - tcp destination A - tcp destination B
Server A - syslog-ng 2.0.8 Linux 2.6.x - tcp source - pipe destination Server A - syslog-ng 2.0.8 linux 2.6.x - pipe source with flow-control - file destination
Server B - syslog-ng 2.0.8 Linux 2.6.x - tcp source - pipe destination Server B - syslog-ng 2.0.8 linux 2.6.x - pipe source with flow-control - file destination
Server C logged 608955 messages Server A logged 351502 messages Server B logged 179874 messages
None of the servers record any dropped messages. syslog-ng does not report dropped messages on file destinations, but with the flow-control any drops should occur at the server that writes to the pipe.
Anyone want to propose an explanation?
Isn't this the same as the previous one? E.g. the tcp connections could not be established at startup from Server C -> Server A and Server C -> Server B Otherwise I can't see where it could lose messages, it should at least report it. I'm going to add a "global" drop counter, just as in 1.6.x; it might give a clue in these situations. -- Bazsi
Balazs Scheidler wrote:
On Wed, 2008-03-26 at 09:46 -0700, Evan Rempel wrote:
Another instance of dropped messages, but all statics records from syslog-ng indicate that no messages were dropped.
Here is the logging path
Server C - syslog-ng 2.0.8 - file destination - tcp destination A - tcp destination B
Server A - syslog-ng 2.0.8 Linux 2.6.x - tcp source - pipe destination Server A - syslog-ng 2.0.8 linux 2.6.x - pipe source with flow-control - file destination
Server B - syslog-ng 2.0.8 Linux 2.6.x - tcp source - pipe destination Server B - syslog-ng 2.0.8 linux 2.6.x - pipe source with flow-control - file destination
Server C logged 608955 messages Server A logged 351502 messages Server B logged 179874 messages
None of the servers record any dropped messages. syslog-ng does not report dropped messages on file destinations, but with the flow-control any drops should occur at the server that writes to the pipe.
Anyone want to propose an explanation?
Isn't this the same as the previous one? E.g. the tcp connections could not be established at startup from Server C -> Server A and Server C -> Server B
No, not in this case. All servers were up and connected, and logging some information on the channel, however, many messages never got do disk on the receiving servers.
Otherwise I can't see where it could lose messages, it should at least report it.
I'm glad that you think it should. This was my understanding to. What about dropping at the incoming buffer? Is there something related to log_iw_size that would result in messages begin discarded, but since it is not related to a destination, no drop counter is increased? Are the upper limits to the buffer size numbers such as 64K, 2G, 4G etc. We use very large buffers (20 million) and log_is_size(10 million)
I'm going to add a "global" drop counter, just as in 1.6.x; it might give a clue in these situations.
A long time ago you mentioned that you wanted to implement a different statistics reporting mechanism. Have you made any progress in that area? I would like to see drop counters for file destinations. If a filesystem becomes full, I want to know how many messages were dropped, or none if it gets fixed prior to buffers being exhausted. I need to confirm that no messages were dropped. Evan. -- Evan Rempel erempel@uvic.ca Senior Programmer Analyst 250.721.7691 Computing Services University of Victoria
participants (7)
-
Balazs Scheidler
-
Brian A. Seklecki
-
Brian Loe
-
Evan Rempel
-
Fegan, Joe
-
Geller, Sandor (IT)
-
Nathan Campi