[review request] 3.6queue/f/stats-reset
Hi, I'm about to integrate a stats-counter related change and prior to doing that I'd like to solicit feedback. There are both user-visible changes and developer visible changes, feedback on both is sought. Code related comments are preferred on github, functionality comments are best sent via email in response to this one. Here's the branch: https://github.com/balabit/syslog-ng/tree/3.6queue/f/stats-reset Thanks in advance. User-visible changes: ===================== syslog-ng is keeping track on a number of statistics counters that can be used to track what is happening. The detail level of these counters is controlled by the stats-level() global option, which defaults to zero. syslog-ng reports these counters periodically every stats-freq() seconds, or preferably on-demand by invoking "syslog-ng-ctl stats" on the command line. At stats-level(3) a number of "dynamic" counters are enabled, which track the number of messages on a per $HOST, per $PROGRAM and per $HOST_FROM basis. This means that you can follow how many messages a given $PROGRAM is generating in a period. The issue with dynamic counters is that they can consume a lot of memory if the rate of new $PRORGRAM/$HOST values is high. Previously the cleanup happened in a limited way at configuration reload (e.g. SIGHUP) time, which is not really useful for controlling memory usage by this feature. The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime(). Not-so visible changes ====================== I have fixed a few bugs and renamed a function to make it easier to understand. Details are in the git history. Balazs Scheidler (7): logsource: use stats_instant_inc_dynamic_counter() for HOST counters logsource: track time for PROGRAM counters mainloop: remove old orphanage based stats cleanup stats: add stats_prune_old_counters() stats-timer: implement stats_lifetime option cfg: add stats-lifetime() global option stats: rename stats_instance_inc_dynamic_counter() to stats_register_and_increment_dynamic_counter() lib/cfg-grammar.y | 16 ++++++++------- lib/cfg-parser.c | 1 + lib/cfg.c | 3 ++- lib/cfg.h | 1 + lib/logsource.c | 15 +++----------- lib/mainloop.c | 1 - lib/stats-timer.c | 61 +++++++++++++++++++++++++++++++++++++++---------------- lib/stats-timer.h | 2 +- lib/stats.c | 52 +++++++++++++++++++++++++++++++++++++++-------- lib/stats.h | 7 +++---- 10 files changed, 108 insertions(+), 51 deletions(-) -- Bazsi
Hi, I am not sure I understand correctly how this feature will work. For example, I set the stats-lifetime() option to 60 seconds, and start syslog-ng. At that moment, all counters are 0. After some time, say, 70 seconds after start, I use the syslog-ng-ctl stats command. What will be the output? The number of messages received since the last time the counters were zeroed (that is, in the last 10 seconds)? Or the number of messages received in the last full cycle (0-60 seconds)? If the former, does the stats message indicate that the number apply to the last 10 seconds? Also, if I want to aggregate the statistics, do I have to use the stats-freq() option, then filter and parse the stats message (so I get the numbers for the last 60 minutes), or is it possible to get this info reliably using the syslog-ng-ctl-stats command somehow? Regards, Robert On Saturday, November 16, 2013 14:50 CET, Balazs Scheidler <bazsi@balabit.hu> wrote:
Hi,
I'm about to integrate a stats-counter related change and prior to doing that I'd like to solicit feedback.
There are both user-visible changes and developer visible changes, feedback on both is sought.
Code related comments are preferred on github, functionality comments are best sent via email in response to this one.
Here's the branch:
https://github.com/balabit/syslog-ng/tree/3.6queue/f/stats-reset
Thanks in advance.
User-visible changes: =====================
syslog-ng is keeping track on a number of statistics counters that can be used to track what is happening.
The detail level of these counters is controlled by the stats-level() global option, which defaults to zero.
syslog-ng reports these counters periodically every stats-freq() seconds, or preferably on-demand by invoking "syslog-ng-ctl stats" on the command line.
At stats-level(3) a number of "dynamic" counters are enabled, which track the number of messages on a per $HOST, per $PROGRAM and per $HOST_FROM basis. This means that you can follow how many messages a given $PROGRAM is generating in a period.
The issue with dynamic counters is that they can consume a lot of memory if the rate of new $PRORGRAM/$HOST values is high.
Previously the cleanup happened in a limited way at configuration reload (e.g. SIGHUP) time, which is not really useful for controlling memory usage by this feature.
The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime().
Not-so visible changes ======================
I have fixed a few bugs and renamed a function to make it easier to understand. Details are in the git history.
Balazs Scheidler (7): logsource: use stats_instant_inc_dynamic_counter() for HOST counters logsource: track time for PROGRAM counters mainloop: remove old orphanage based stats cleanup stats: add stats_prune_old_counters() stats-timer: implement stats_lifetime option cfg: add stats-lifetime() global option stats: rename stats_instance_inc_dynamic_counter() to stats_register_and_increment_dynamic_counter()
lib/cfg-grammar.y | 16 ++++++++------- lib/cfg-parser.c | 1 + lib/cfg.c | 3 ++- lib/cfg.h | 1 + lib/logsource.c | 15 +++----------- lib/mainloop.c | 1 - lib/stats-timer.c | 61 +++++++++++++++++++++++++++++++++++++++---------------- lib/stats-timer.h | 2 +- lib/stats.c | 52 +++++++++++++++++++++++++++++++++++++++-------- lib/stats.h | 7 +++---- 10 files changed, 108 insertions(+), 51 deletions(-)
-- Bazsi
Hi, Counters are not zeroed. They get pruned iff they are not updated for stats-lifetime() seconds. And only the dynamic kind. This means that you have to query them within the lifetime period to avoid losing their value. Also, I'm thinking about sending stats as a well structured message with name value pairs, so you don't need to write custom scripts to query/store counters, you can use syslog-ng machinery for that. On Nov 17, 2013 7:49 PM, "Fekete Róbert" <frobert@balabit.hu> wrote:
Hi,
I am not sure I understand correctly how this feature will work. For example, I set the stats-lifetime() option to 60 seconds, and start syslog-ng. At that moment, all counters are 0. After some time, say, 70 seconds after start, I use the syslog-ng-ctl stats command. What will be the output? The number of messages received since the last time the counters were zeroed (that is, in the last 10 seconds)? Or the number of messages received in the last full cycle (0-60 seconds)? If the former, does the stats message indicate that the number apply to the last 10 seconds?
Also, if I want to aggregate the statistics, do I have to use the stats-freq() option, then filter and parse the stats message (so I get the numbers for the last 60 minutes), or is it possible to get this info reliably using the syslog-ng-ctl-stats command somehow?
Regards,
Robert
On Saturday, November 16, 2013 14:50 CET, Balazs Scheidler < bazsi@balabit.hu> wrote:
Hi,
I'm about to integrate a stats-counter related change and prior to doing that I'd like to solicit feedback.
There are both user-visible changes and developer visible changes, feedback on both is sought.
Code related comments are preferred on github, functionality comments are best sent via email in response to this one.
Here's the branch:
https://github.com/balabit/syslog-ng/tree/3.6queue/f/stats-reset
Thanks in advance.
User-visible changes: =====================
syslog-ng is keeping track on a number of statistics counters that can be used to track what is happening.
The detail level of these counters is controlled by the stats-level() global option, which defaults to zero.
syslog-ng reports these counters periodically every stats-freq() seconds, or preferably on-demand by invoking "syslog-ng-ctl stats" on the command line.
At stats-level(3) a number of "dynamic" counters are enabled, which track the number of messages on a per $HOST, per $PROGRAM and per $HOST_FROM basis. This means that you can follow how many messages a given $PROGRAM is generating in a period.
The issue with dynamic counters is that they can consume a lot of memory if the rate of new $PRORGRAM/$HOST values is high.
Previously the cleanup happened in a limited way at configuration reload (e.g. SIGHUP) time, which is not really useful for controlling memory usage by this feature.
The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime().
Not-so visible changes ======================
I have fixed a few bugs and renamed a function to make it easier to understand. Details are in the git history.
Balazs Scheidler (7): logsource: use stats_instant_inc_dynamic_counter() for HOST counters logsource: track time for PROGRAM counters mainloop: remove old orphanage based stats cleanup stats: add stats_prune_old_counters() stats-timer: implement stats_lifetime option cfg: add stats-lifetime() global option stats: rename stats_instance_inc_dynamic_counter() to stats_register_and_increment_dynamic_counter()
lib/cfg-grammar.y | 16 ++++++++------- lib/cfg-parser.c | 1 + lib/cfg.c | 3 ++- lib/cfg.h | 1 + lib/logsource.c | 15 +++----------- lib/mainloop.c | 1 - lib/stats-timer.c | 61 +++++++++++++++++++++++++++++++++++++++---------------- lib/stats-timer.h | 2 +- lib/stats.c | 52 +++++++++++++++++++++++++++++++++++++++-------- lib/stats.h | 7 +++---- 10 files changed, 108 insertions(+), 51 deletions(-)
-- Bazsi
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Balazs Scheidler <bazsi@balabit.hu> writes:
User-visible changes: =====================
syslog-ng is keeping track on a number of statistics counters that can be used to track what is happening.
The detail level of these counters is controlled by the stats-level() global option, which defaults to zero.
syslog-ng reports these counters periodically every stats-freq() seconds, or preferably on-demand by invoking "syslog-ng-ctl stats" on the command line.
At stats-level(3) a number of "dynamic" counters are enabled, which track the number of messages on a per $HOST, per $PROGRAM and per $HOST_FROM basis. This means that you can follow how many messages a given $PROGRAM is generating in a period.
The issue with dynamic counters is that they can consume a lot of memory if the rate of new $PRORGRAM/$HOST values is high.
Previously the cleanup happened in a limited way at configuration reload (e.g. SIGHUP) time, which is not really useful for controlling memory usage by this feature.
The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime().
So, this means that if I don't query the stats just before clearing, I'll potentially loose information? I mean, considering stats-freq(60) stats-lifetime(10), if I have a source that has messages available every 14 seconds, I'll loose some of them. Would it be possible to dump the stats just before forgetting them? Even better, dump only the ones we're about to prune out. That'd make things a bit safer, I think. -- |8]
On Mon, 2013-11-18 at 12:22 +0100, Gergely Nagy wrote:
Balazs Scheidler <bazsi@balabit.hu> writes:
User-visible changes: =====================
syslog-ng is keeping track on a number of statistics counters that can be used to track what is happening.
The detail level of these counters is controlled by the stats-level() global option, which defaults to zero.
syslog-ng reports these counters periodically every stats-freq() seconds, or preferably on-demand by invoking "syslog-ng-ctl stats" on the command line.
At stats-level(3) a number of "dynamic" counters are enabled, which track the number of messages on a per $HOST, per $PROGRAM and per $HOST_FROM basis. This means that you can follow how many messages a given $PROGRAM is generating in a period.
The issue with dynamic counters is that they can consume a lot of memory if the rate of new $PRORGRAM/$HOST values is high.
Previously the cleanup happened in a limited way at configuration reload (e.g. SIGHUP) time, which is not really useful for controlling memory usage by this feature.
The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime().
So, this means that if I don't query the stats just before clearing, I'll potentially loose information? I mean, considering stats-freq(60) stats-lifetime(10), if I have a source that has messages available every 14 seconds, I'll loose some of them.
yeah, stats-lifetime() should be set to a value to at least stats-freq() (or the poll frequency of an external polling application) to avoid data loss.
Would it be possible to dump the stats just before forgetting them? Even better, dump only the ones we're about to prune out. That'd make things a bit safer, I think.
I'd like to make it possible to generate a structured log message when stats-freq() happens. that can be the "dump" operation. I'm thinking along the lines of ${.syslog-ng.stats[0].type} == "processed" ${.syslog-ng.stats[0].source} == "src.file" ${.syslog-ng.stats[0].instance} == "input.log" ${.syslog-ng.stats[0].value} == "232323" ${.syslog-ng.stats[0].value_delta} == "3" And when formatted using $(format-json) this could become an actual array. we would need array support in name-value pairs for that though. The point of the format is to make it as easy to generate graphs using graphite or similar tools. Once we have the structured format, we might as well reuse that to dump pruned entries once pruning happens. What do you think? -- Bazsi
Balazs Scheidler <bazsi77@gmail.com> writes:
The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime().
So, this means that if I don't query the stats just before clearing, I'll potentially loose information? I mean, considering stats-freq(60) stats-lifetime(10), if I have a source that has messages available every 14 seconds, I'll loose some of them.
yeah, stats-lifetime() should be set to a value to at least stats-freq() (or the poll frequency of an external polling application) to avoid data loss.
That's not good.. we should fix this situation soonish, as this is much more complicated than my brain is willing to understand on a monday morning.
Would it be possible to dump the stats just before forgetting them? Even better, dump only the ones we're about to prune out. That'd make things a bit safer, I think.
I'd like to make it possible to generate a structured log message when stats-freq() happens. that can be the "dump" operation.
I'm thinking along the lines of
${.syslog-ng.stats[0].type} == "processed" ${.syslog-ng.stats[0].source} == "src.file" ${.syslog-ng.stats[0].instance} == "input.log" ${.syslog-ng.stats[0].value} == "232323" ${.syslog-ng.stats[0].value_delta} == "3"
And when formatted using $(format-json) this could become an actual array.
we would need array support in name-value pairs for that though.
The point of the format is to make it as easy to generate graphs using graphite or similar tools.
Once we have the structured format, we might as well reuse that to dump pruned entries once pruning happens.
What do you think?
This sounds good to me. I don't really care about the format of the dump at the moment, but the dump should happen. As for array support: just use [$index] as convention, and we'll teach most of the things that can potentially use it, to handle it (which means value-pairs). I had a PoC of that at one point, but I overcomplicated the code. I'll have another go sometime later, but I don't think that should hold up this feature. Just generate a new internal message with the layout you proposed above, we'll care about properly formatting it later, I would say. -- |8]
Hi, I don't have an opinion on the stats, but I definitely vote for array support!
Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but instead of dropping the stat counter at that time, the counter is just flagged for dropping. Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that have been flagged as having exceeded the stats-lifetime(). This way a counter is never dropped until it has exceeded the stats-lifetime() AND has been logged. This approach will cause me problems because I use the syslog-ng-ctl to get the detailed statistics, AND use the stats-freq() log line, routed to a program destination to invoke the syslog-ng-ctl. By that time the statistic would have been dropped :-( Perhaps the detailed statistics, like those returned from syslog-ng-ctl could be logged internally by syslog-ng, rather than the very long "Log statistics; ..." log line that is logged today. Perhaps a stats-multiline([0|1]) setting. That means that my program destination can use the internally logged stream rather than having to invoke syslog-ng-ctl to get the statistics. Evan. On 11/18/2013 03:51 AM, Balazs Scheidler wrote:
On Mon, 2013-11-18 at 12:22 +0100, Gergely Nagy wrote:
Balazs Scheidler <bazsi@balabit.hu> writes:
User-visible changes: =====================
syslog-ng is keeping track on a number of statistics counters that can be used to track what is happening.
The detail level of these counters is controlled by the stats-level() global option, which defaults to zero.
syslog-ng reports these counters periodically every stats-freq() seconds, or preferably on-demand by invoking "syslog-ng-ctl stats" on the command line.
At stats-level(3) a number of "dynamic" counters are enabled, which track the number of messages on a per $HOST, per $PROGRAM and per $HOST_FROM basis. This means that you can follow how many messages a given $PROGRAM is generating in a period.
The issue with dynamic counters is that they can consume a lot of memory if the rate of new $PRORGRAM/$HOST values is high.
Previously the cleanup happened in a limited way at configuration reload (e.g. SIGHUP) time, which is not really useful for controlling memory usage by this feature.
The current patch series introduces a stats-lifetime() option and syslog-ng starts inspecting counters every once in a while and prune those that are updated earlier than stats-lifetime().
So, this means that if I don't query the stats just before clearing, I'll potentially loose information? I mean, considering stats-freq(60) stats-lifetime(10), if I have a source that has messages available every 14 seconds, I'll loose some of them.
yeah, stats-lifetime() should be set to a value to at least stats-freq() (or the poll frequency of an external polling application) to avoid data loss.
Would it be possible to dump the stats just before forgetting them? Even better, dump only the ones we're about to prune out. That'd make things a bit safer, I think.
I'd like to make it possible to generate a structured log message when stats-freq() happens. that can be the "dump" operation.
I'm thinking along the lines of
${.syslog-ng.stats[0].type} == "processed" ${.syslog-ng.stats[0].source} == "src.file" ${.syslog-ng.stats[0].instance} == "input.log" ${.syslog-ng.stats[0].value} == "232323" ${.syslog-ng.stats[0].value_delta} == "3"
And when formatted using $(format-json) this could become an actual array.
we would need array support in name-value pairs for that though.
The point of the format is to make it as easy to generate graphs using graphite or similar tools.
Once we have the structured format, we might as well reuse that to dump pruned entries once pruning happens.
What do you think?
-- Evan Rempel erempel@uvic.ca Senior Systems Administrator 250.721.7691 Data Centre Services, University Systems, University of Victoria
Evan Rempel <erempel@uvic.ca> writes:
Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but instead of dropping the stat counter at that time, the counter is just flagged for dropping.
Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that have been flagged as having exceeded the stats-lifetime().
This way a counter is never dropped until it has exceeded the stats-lifetime() AND has been logged.
That makes a lot of sense, but syslog-ng-ctl stats should not count (or perhaps only with a flag), precisely to avoid the scenario you outlined too. -- |8]
On Mon, 2013-11-18 at 18:22 +0100, Gergely Nagy wrote:
Evan Rempel <erempel@uvic.ca> writes:
Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but instead of dropping the stat counter at that time, the counter is just flagged for dropping.
Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that have been flagged as having exceeded the stats-lifetime().
This way a counter is never dropped until it has exceeded the stats-lifetime() AND has been logged.
That makes a lot of sense, but syslog-ng-ctl stats should not count (or perhaps only with a flag), precisely to avoid the scenario you outlined too.
This really makes sense, however my issue is that stats-freq() is often set to 0 which disables the Log statistics message currently. Relying the cleanup mechanism on that would disable cleanup altogether in a lot of setups. hmm... maybe we should use stats-freq() if that's nonzero and stats-lifetime() when it is zero. This way the cleanup mechanism would kick in, without the risk of losing messages. syslog-ng-ctl stats wouldn't prune counters. This way, stats-freq() would be the one which actually clears counters, we get rid of an additional iteration over the set of counters. This paves the way for an improved log statistics message that could be sent into graphite/logstash/whatever graphing application via standard syslog-ng destination drivers, and all this without the risk of losing counters. What do you think? -- Bazsi
Balazs Scheidler <bazsi77@gmail.com> writes:
On Mon, 2013-11-18 at 18:22 +0100, Gergely Nagy wrote:
Evan Rempel <erempel@uvic.ca> writes:
Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but instead of dropping the stat counter at that time, the counter is just flagged for dropping.
Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that have been flagged as having exceeded the stats-lifetime().
This way a counter is never dropped until it has exceeded the stats-lifetime() AND has been logged.
That makes a lot of sense, but syslog-ng-ctl stats should not count (or perhaps only with a flag), precisely to avoid the scenario you outlined too.
This really makes sense, however my issue is that stats-freq() is often set to 0 which disables the Log statistics message currently. Relying the cleanup mechanism on that would disable cleanup altogether in a lot of setups.
hmm... maybe we should use stats-freq() if that's nonzero and stats-lifetime() when it is zero. This way the cleanup mechanism would kick in, without the risk of losing messages.
syslog-ng-ctl stats wouldn't prune counters.
This way, stats-freq() would be the one which actually clears counters, we get rid of an additional iteration over the set of counters.
This paves the way for an improved log statistics message that could be sent into graphite/logstash/whatever graphing application via standard syslog-ng destination drivers, and all this without the risk of losing counters.
What do you think?
Sounds very good to me. This is a big step towards what I need, and is simple enough to understand too. -- |8]
Hi, I have now updated my branch. The new functionality (extended statistics log message and log-fifo-size() reporting through stats) is not yet created, however a set of code reorganization would make this change much easier. So the current patch set (published on the same branch, rebased since last time) uses the stats-freq() timer to prune unneeded counters, but only if they have already been reported by the statistics log message. This solves the losing-data issue that was discussed earlier. So this time, it is more of a code-review thing, could those interested in code review this in the coming days, prior to integration? Thanks. On Wed, 2013-11-20 at 14:47 +0100, Gergely Nagy wrote:
Balazs Scheidler <bazsi77@gmail.com> writes:
On Mon, 2013-11-18 at 18:22 +0100, Gergely Nagy wrote:
Evan Rempel <erempel@uvic.ca> writes:
Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but instead of dropping the stat counter at that time, the counter is just flagged for dropping.
Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that have been flagged as having exceeded the stats-lifetime().
This way a counter is never dropped until it has exceeded the stats-lifetime() AND has been logged.
That makes a lot of sense, but syslog-ng-ctl stats should not count (or perhaps only with a flag), precisely to avoid the scenario you outlined too.
This really makes sense, however my issue is that stats-freq() is often set to 0 which disables the Log statistics message currently. Relying the cleanup mechanism on that would disable cleanup altogether in a lot of setups.
hmm... maybe we should use stats-freq() if that's nonzero and stats-lifetime() when it is zero. This way the cleanup mechanism would kick in, without the risk of losing messages.
syslog-ng-ctl stats wouldn't prune counters.
This way, stats-freq() would be the one which actually clears counters, we get rid of an additional iteration over the set of counters.
This paves the way for an improved log statistics message that could be sent into graphite/logstash/whatever graphing application via standard syslog-ng destination drivers, and all this without the risk of losing counters.
What do you think?
Sounds very good to me. This is a big step towards what I need, and is simple enough to understand too.
I havent followed this up, but this got integrated and is on mainline. The additional functionality is noted but not yet there. On Nov 27, 2013 11:22 AM, "Balazs Scheidler" <bazsi@balabit.hu> wrote:
Hi,
I have now updated my branch. The new functionality (extended statistics log message and log-fifo-size() reporting through stats) is not yet created, however a set of code reorganization would make this change much easier.
So the current patch set (published on the same branch, rebased since last time) uses the stats-freq() timer to prune unneeded counters, but only if they have already been reported by the statistics log message.
This solves the losing-data issue that was discussed earlier.
So this time, it is more of a code-review thing, could those interested in code review this in the coming days, prior to integration?
Thanks.
On Wed, 2013-11-20 at 14:47 +0100, Gergely Nagy wrote:
Balazs Scheidler <bazsi77@gmail.com> writes:
On Mon, 2013-11-18 at 18:22 +0100, Gergely Nagy wrote:
Evan Rempel <erempel@uvic.ca> writes:
Perhaps the same logic can be used to identify those counters that have expired meaning that the stats-lifetime() has been exceeded,but instead of dropping the stat counter at that time, the counter is just flagged for dropping.
Then it becomes the job of the statistics logging, based on the stats-freq() value, to log AND drop those counters that have been flagged as having exceeded the stats-lifetime().
This way a counter is never dropped until it has exceeded the stats-lifetime() AND has been logged.
That makes a lot of sense, but syslog-ng-ctl stats should not count (or perhaps only with a flag), precisely to avoid the scenario you outlined too.
This really makes sense, however my issue is that stats-freq() is often set to 0 which disables the Log statistics message currently. Relying the cleanup mechanism on that would disable cleanup altogether in a lot of setups.
hmm... maybe we should use stats-freq() if that's nonzero and stats-lifetime() when it is zero. This way the cleanup mechanism would kick in, without the risk of losing messages.
syslog-ng-ctl stats wouldn't prune counters.
This way, stats-freq() would be the one which actually clears counters, we get rid of an additional iteration over the set of counters.
This paves the way for an improved log statistics message that could be sent into graphite/logstash/whatever graphing application via standard syslog-ng destination drivers, and all this without the risk of losing counters.
What do you think?
Sounds very good to me. This is a big step towards what I need, and is simple enough to understand too.
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
participants (6)
-
Balazs Scheidler
-
Balazs Scheidler
-
Evan Rempel
-
Fabien Wernli
-
Fekete Róbert
-
Gergely Nagy