If the lag detector's logger is set to `DEBUG` then the master will capture the hot threads on the lagging node and report them in its logs. However it's quite possible for this log message to be many kB in size, and log messages are apparently truncated at 10kB by default.

We should find another way to report this information to avoid hitting this size limit. Perhaps simply split the hot threads output up across multiple log messages, or perhaps find a different way to report it.
server/src/test/java/org/elasticsearch/cluster/coordination/CoordinatorTests.java
try (Cluster cluster = new Cluster(randomIntBetween(3, 5))) {
            cluster.runRandomly();
            cluster.stabilise();
            final ClusterNode leader = cluster.getAnyLeader();
            final ClusterNode follower = cluster.getAnyNodeExcept(leader);
            logger.info("--> blackholing follower {}", follower);
            follower.blackhole();
            cluster.stabilise(
                Math.max(
                    
                    (defaultMillis(FOLLOWER_CHECK_INTERVAL_SETTING) + defaultMillis(FOLLOWER_CHECK_TIMEOUT_SETTING)) * defaultInt(
                        FOLLOWER_CHECK_RETRY_COUNT_SETTING
                    )
                        
                        + DEFAULT_CLUSTER_STATE_UPDATE_DELAY
                        
                        + DEFAULT_CLUSTER_STATE_UPDATE_DELAY,
                    
                    (defaultMillis(LEADER_CHECK_INTERVAL_SETTING) + defaultMillis(LEADER_CHECK_TIMEOUT_SETTING)) * defaultInt(
                        LEADER_CHECK_RETRY_COUNT_SETTING
                    )
                )
            );
            assertThat(cluster.getAnyLeader().getId(), equalTo(leader.getId()));
        }
    }
    /**
     * This test was added to verify that state recovery is properly reset on a node after it has become master and successfully
     * recovered a state (see {@link GatewayService}). The situation which triggers this with a decent likelihood is as follows:
     * 3 master-eligible nodes (leader, follower1, follower2), the followers are shut down (leader remains), when followers come back