This causes the resulting log line to be less than maxLogSizeKB (even though the value of maxLogSizeKB is reported in the line itself, in a way which suggests it has been truncated to this length), which is unexpected. For example, for the default value (10 KB), only about 7 KB is retained from a 10.5 KB log line, whereas a 9.5 KB log line will retain all its info (no truncation). Users might be surprised if they configure a custom value for maxLogSizeKB and then subsequently discover that less information has been retained.
Probably the maxLogLine / 3 occurrences should be replaced by (maxLogLine - length_of_truncation_warning) / 2 (the length of the truncation warning is about 100 bytes). Presumably the ~50 bytes for the timestamp, severity, component, and context, is not worth incorporating in the truncation length (since this is more about truncating the actual message, not necessarily the entire line).