當(dāng)我們遇到問題或者需要深入了解 Elasticsearch 的運行機制時，調(diào)整日志等級（?logging level?）到更詳細(xì)的級別，比如?DEBUG、TRACE?，會是一個有效且必須要掌握的方法。

Elasticsearch 提供了如下的接口來支持動態(tài)變更 logging level，logger 后面是 package name 或者 class name。

PUT _cluster/settings
{
  "persistent": {
    "logger": {
      "org.elasticsearch.action": "DEBUG"
    }
  }
}

當(dāng)然，你也可以去修改配置目錄下面的 log4j2.properties，然后重啟節(jié)點，但這種方法太過笨重，建議你不要用。

如果后續(xù)想要調(diào)整回默認(rèn)設(shè)置，操作也簡單，如下所示：

 
PUT _cluster/settings
{
  "persistent": {
    "logger": {
      "org.elasticsearch.action": null
    }
  }
}

上面的示例只是指定了一個 logger，當(dāng)然也可以在一次請求中設(shè)定多個 logger，如下所示：

PUT _cluster/settings
{
  "persistent": {
    "logger": {
      "_root": "INFO",
      "org.elasticsearch.action": "DEBUG",
      "org.elasticsearch.action.admin.cluster.health": "TRACE"
    }
  }
}

上面的設(shè)定中，調(diào)用者的意圖可能如下：

1. root 的日志等級（默認(rèn)所有 logger 的日志級別）設(shè)定為 INFO，雖然 log4j2.properties 中已經(jīng)設(shè)定過了，保險起見，這里再指定一次。
2. 設(shè)定 org.elasticsearch.action 這個 package 下所有 logger 的日志級別都為 DEBUG，需要查看下 transport action 的執(zhí)行日志。
3. 設(shè)定 org.elasticsearch.action.admin.cluster.health 這個 package 下所有 logger 的日志級別都為 TRACE，需要查看 Cluster Health 執(zhí)行的更多日志。

但實際去運行時，Elasticsearch 并沒有按照預(yù)期的結(jié)果去執(zhí)行，沒有相關(guān)?DEBUG?和?TRACE?級別的日志輸出。這里直接給出原因和解決方案。

原因是 elasticsearch 在設(shè)定 logging level 時，會優(yōu)先采用?_root?和?parent logger?的設(shè)定，這里和 log4j2.properties 中的設(shè)定有所差異。

上面的調(diào)用，最終結(jié)果是采用 _root 的設(shè)定，所有 logger 都是?INFO?，其他的設(shè)定都無效了。

解決方案如下，去除 _root 設(shè)定和 parent logger 的設(shè)定。

PUT _cluster/settings
{
  "persistent": {
    "logger": {
      "_root": null,
      "org.elasticsearch.action": null,
      "org.elasticsearch.action.admin.cluster.health": "TRACE"
    }
  }
}

下面就是源碼分析了，感興趣的可以繼續(xù)看下去~

源碼分析

相關(guān)實現(xiàn)邏輯在?ClusterSetting.LoggingSettingUpdater?里面，這里簡單給下定位的思路，感興趣的同學(xué)可以自己去翻下源碼。

1. rest 請求的入口是?RestClusterUpdateSettingsAction，這里會轉(zhuǎn)發(fā)請求到 master 節(jié)點
2. master 處理的入口是?TransportClusterUpdateSettingsAction，這里會去 update Cluster Setting，關(guān)鍵詞為?updater.updateSettings。
3. 在 updateSettings的時候會調(diào)用所有的 ClusterSettingUpdater，Logging 就是其中之一。

這里 apply setting 的代碼如下：

for (String key : value.keySet()) {
    assert loggerPredicate.test(key);
    String component = key.substring("logger.".length());
    if ("level".equals(component)) {
        continue;
    }
    if ("_root".equals(component)) {
        final String rootLevel = value.get(key);
        if (rootLevel == null) {
            Loggers.setLevel(LogManager.getRootLogger(), Loggers.LOG_DEFAULT_LEVEL_SETTING.get(settings));
        } else {
            Loggers.setLevel(LogManager.getRootLogger(), rootLevel);
        }
    } else {
        Loggers.setLevel(LogManager.getLogger(component), value.get(key));
    }
}

淺顯易懂，不廢話，而且這里的邏輯看起來很正常，那么繼續(xù)來看下 Loggers.setLevel代碼。

public static void setLevel(Logger logger, Level level) {
    if (!LogManager.ROOT_LOGGER_NAME.equals(logger.getName())) {
        Configurator.setLevel(logger.getName(), level);
    } else {
        final LoggerContext ctx = LoggerContext.getContext(false);
        final Configuration config = ctx.getConfiguration();
        final LoggerConfig loggerConfig = config.getLoggerConfig(logger.getName());
        loggerConfig.setLevel(level);
        ctx.updateLoggers();
    }

    // we have to descend the hierarchy
    final LoggerContext ctx = LoggerContext.getContext(false);
    for (final LoggerConfig loggerConfig : ctx.getConfiguration().getLoggers().values()) {
        if (LogManager.ROOT_LOGGER_NAME.equals(logger.getName()) || loggerConfig.getName().startsWith(logger.getName() + ".")) {
            Configurator.setLevel(loggerConfig.getName(), level);
        }
    }
}

最后的處理邏輯會在每個 logger 設(shè)定完成后，去重新刷一遍現(xiàn)有的 logger，應(yīng)用 root 或者 parent logger 的設(shè)定。

順著代碼的修改記錄，找到了當(dāng)初的修改 PR 如下：

[https://github.com/elastic/el...]()

其中也描述了修改的原因：

Today when setting the logging level via the command-line or an API
call, the expectation is that the logging level should trickle down the
hiearchy to descendant loggers. However, this is not necessarily the
case. For example, if loggers x and x.y are already configured then
setting the logging level on x will not descend to x.y. This is because
the logging config for x.y has already been forked from the logging
config for x. Therefore, we must explicitly descend the hierarchy when
setting the logging level and that is what this commit does.

從這段描述看，當(dāng)時要解決的問題是 x.y 沒有繼承 x logging level 的問題，所以加了這段顯示繼承的邏輯。

雖然這解決了繼承的問題，但其行為本身與 log4j2.properties 中 logger 的修改邏輯就不一致了，難免帶來困擾。

但考慮到這個配置是一個專家級別的配置，很少用戶會使用，自己心里明白正確的使用方法就好了^_^文章來源地址http://www.zghlxwxcb.cn/news/detail-807304.html

到了這里，關(guān)于你真的知道如何查看 Elasticsearch 的 Debug 日志嗎？!的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！