> I'm open to any feedback. I've tried to keep the details vague while calling out for non-technical users that it is possible to have transactions complete without associated logs making it to disk. > > Another change I'd like to know your thoughts on is whether changing the existing wording that says "The logging collector is designed to never lose messages." is appropriate. This statement reads like a strong guarantee to me. I think it could be helpful to phrase it in a way that makes it clearer that the logging collector will delay the application if it can't keep up with logging volume without saying something as strong as "never lose messages". > If you think it is a good idea I can add a change in the patch to reword it to something weaker like "The logging collector is designed to avoid losing messages."
Since the point of this description seems that the logging collector does not have something like well-known syslog's rate-limiting behavior (i.e., dropping messages under very high log volume), I'd prefer wording like:
The logging collector is designed to avoid dropping messages even under very high log volume.
Thought?
+ The logging collector writes to disk asynchronously. The server + losing power or errors when writing to the log file + can result in messages not being persisted.
"writes to disk asynchronously" feels a bit ambiguous to me. How about something like:
The logging collector does not guarantee that log messages have reached durable storage. A system crash, power loss, or an error while writing the log file can still result in messages being lost.
