Description
Description
it is not uncommon for users to forget about logging config when upgrading a cluster. This means that when upgrading to a next major version users can end up with a broken log4j config. We changed configs from 6 ->7 and 7-> 8
Some of those changes are related to a code changes. For instance a 8.x ES cluster with 7.x config does not have a correctly deduplicated deprecation logs (#61474). This in pair with indexing deprecation logs can results with increased indexing traffic in that cluster.
Users might also want to tweak logging configuration in a way we did not test this before. Some of the changes in that config we envisioned (logging levels changes) are possibly and encouraged to be done via cluster settings api. https://www.elastic.co/guide/en/elasticsearch/reference/current/logging.html#configuring-logging-levels
Others like changes in log file sizes might cause cluster nodes to run out of disc space quicker than we anticipated in our sizing guidelines.
I think we should not expose log4j.properties file and keep it internal. The documentation on how to tweak that file should also be removed.
BWC considerations:
We should keep SHAs of the previously known config files and ignore the old config. This should not be considered breaking because as mentioned earlier, running a new cluster with old 'unchanged' config is a incorrect.
Users who tweaked their config (we don't know sha of the config they have) should get a bootstrap warning on startup and send that information via telemetry to Elastic