正文

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

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

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

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

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

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

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

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

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

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

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

原因是 elasticsearch 在設(shè)定 logging level 時(shí)，會(huì)優(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)實(shí)現(xiàn)邏輯在 ClusterSetting.LoggingSettingUpdater 里面，這里簡單給下定位的思路，感興趣的同學(xué)可以自己去翻下源碼。

• rest 請(qǐng)求的入口是 RestClusterUpdateSettingsAction，這里會(huì)轉(zhuǎn)發(fā)請(qǐng)求到 master 節(jié)點(diǎn)
• master 處理的入口是 TransportClusterUpdateSettingsAction，這里會(huì)去 update Cluster Setting，關(guān)鍵詞為 updater.updateSettings。
• 在 updateSettings的時(shí)候會(huì)調(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);
        }
    }
}

最后的處理邏輯會(huì)在每個(gè) 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)時(shí)要解決的問題是 x.y 沒有繼承 x logging level 的問題，所以加了這段顯示繼承的邏輯。

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

但考慮到這個(gè)配置是一個(gè)專家級(jí)別的配置，很少用戶會(huì)使用，自己心里明白正確的使用方法就好了^_^

以上就是詳解如何查看Elasticsearch的Debug日志的詳細(xì)內(nèi)容，更多關(guān)于Elasticsearch Debug日志查看的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論