Currently, Kibana's numeric log rolling strategy is applied so the most-recently-rotated file has the lowest number (kibana-1.log) and the oldest file has the largest number (kibana-10.log).

This means that on every log rotation, all rotated files are renamed (assuming max: 10):

1. kibana-10.log is deleted
2. kibana-9.log is renamed to kibana-10.log
3. kibana-8.log -> kibana-9.log
4. ...
5. kibana-1.log -> kibana-2.log
6. kibana.log -> kibana-1.log

This matches how log4j's DefaultRolloverStrategy works if specified the option fileIndex="min".

However, some folks prefer their log rotation to happen in a way that the highest number is the most recent (default DefaultRolloverStrategy):

1. kibana.log -> kibana-1.log
2. kibana.log -> kibana-2.log (leaving kibana-1.log untouched)

We may also consider adding the nomax behaviour for feature parity.

Refer to https://logging.apache.org/log4j/2.x/manual/appenders.html > Rollover Strategies for better examples of how the Rollover Strategies work in log4j.