[MXS-823] Log Throttling Created: 2016-08-08 Updated: 2016-08-11 Resolved: 2016-08-11 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Type: | Task | Priority: | Major |
| Reporter: | Johan Wikman | Assignee: | Johan Wikman |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Description |
|
In some circumstances, if MaxScale due to a persistent error, failure or some configuration issue fails to do something, it logs an error and tries again, leading to a situation where the log is flooded with the same error or set of errors being reported over and over again. In general, MaxScale should be prepared for and deal explicitly with such situations; for instance, in some cases just aborting the connection, in others retrying with ever increasing intervals, or something else, so that the situation is dealt with without the log being flooded. However, making sure that MaxScale would never flood the log is difficult, so a backup mechanism that simply throttles the logging, that is, a mechanism that deals with the symptom and not the cause, is needed. |
| Comments |
| Comment by Johan Wikman [ 2016-08-11 ] |
|
In the global section of the MaxScale configuration file, you can specify: {log_throttling = X, Y, Z}where X denotes the number of times a particular error or warning message can occur in a time window of length Y, before it is suppressed for Z milliseconds. For instance, an entry like {log_throttling = 10, 1000, 10000}would mean that if an error or warning occurs 10 times within 1 second, then that error will thereafter be suppressed for 10 seconds. Note that notice, info and debug messages are not throttled. The rationale is that notice messages are not used in a context where throttling would be needed, and info and debug messages are only used when debugging something, and in that case you probably want to see everything. |