documenting rateLimit wich leads to the confusion of #28641#670
documenting rateLimit wich leads to the confusion of #28641#670mdlinville merged 2 commits intodocker:masterfrom
Conversation
|
Deploy preview ready! Built with commit 6bda312 |
The format for node advertisement in swarm and docker engine (for networking) is the same, and can be shared. Doing so allows us to start toward removing the swarm-join container, and improves our HA situation after engine discovery is run. Resolves docker#670. Specifically, swarm was previously somewhat HA: if you set up 1 controller, 2 replicas and 1 node, then you could lose the controller and still remain functional unless the swarm node needed to restart. This change improves HA by removing the above failure mode as long as engine discovery has been run and is up to date. See also docker-archive/classicswarm#1368 which implemented this flag, and lays out the future scenario we hope to achieve, and also docker#1032 which is our goal of removing swarm join with automatical engine discovery.
The format for node advertisement in swarm and docker engine (for networking) is the same, and can be shared. Doing so allows us to start toward removing the swarm-join container, and improves our HA situation after engine discovery is run. Resolves docker#670. Specifically, swarm was previously somewhat HA: if you set up 1 controller, 2 replicas and 1 node, then you could lose the controller and still remain functional unless the swarm node needed to restart. This change improves HA by removing the above failure mode as long as engine discovery has been run and is up to date. See also docker-archive/classicswarm#1368 which implemented this flag, and lays out the future scenario we hope to achieve, and also docker#1032 which is our goal of removing swarm join with automatical engine discovery.
mdlinville
left a comment
There was a problem hiding this comment.
Thanks for tackling this. Please consider my rewording suggestions and please rebase against master and resolve the merge conflict if possible. Let me know if you need help with the rebase.
engine/admin/logging/journald.md
Outdated
| ## Journald configuration | ||
|
|
||
| Docker hosts with many containers may produce massive amounts of log-messages. | ||
| The default configuration of journald is to limit the number of messages stored per service per time-unit. |
There was a problem hiding this comment.
Please put back-ticks around journald. Consider rewriting to something like "By default, journald limits the number of messages stored per service per time-unit."
engine/admin/logging/journald.md
Outdated
| Docker hosts with many containers may produce massive amounts of log-messages. | ||
| The default configuration of journald is to limit the number of messages stored per service per time-unit. | ||
|
|
||
| Applications with need for large-scale logging wil probably need to configure `RateLimitIntervalSec` and `RateLimitBurst` in the journald configuration file. |
There was a problem hiding this comment.
typo: "wil"
Consider rewording because applications don't configure. "If your applications need large-scale logging, configure RateLimitIntervalSec and RateLimitBurst in the journald configuration file."
6bda312 to
0ddda59
Compare
|
I rebased your commits and used this as an opportunity to improve the formatting in the rest of the file. I'll merge after the PR finishes running tests. |
Describe the proposed changes
Documenting the fact that
journaldby default will skip messages if it exceeds a certain rateRelated issue
Relates to my issue #28641 where i blame the logging driver, when the problem were system configuration.