2015.06.30 - 번역 - Elasticsearch Logging Secrets ...

Like every other software out there, Elasticsearch provides some insight into what's happening with its internals while running. This is an informative process and can reveal quickly if something bad happened (in the form of an error message), or it can decisively determine the cause of a performance issue or why the cluster is behaving in a way users might not like.

다른 모든 SW와 마찬가지로, Elasticsearch는 실행 중 내부에서 어떤 일이 일어나고 있는지에 대한 정보를 제공한다. 이는 유용한 정보를 제공하는 process이며, (error 메시지의 형태로) 문제가 발생한 경우 신속하게 알려주거나, 성능 문제의 원인이나 사용자가 원치 않는 방식으로 cluster가 동작하는 이유를 확실하게  확인할 수 있게 한다.

The Basics

Main Elasticsearch logs are written to ES_HOME/logs/[cluster_name].log file. For this file the default level is INFO, thus being sufficient for a rather moderate amount of information and, at the same time, not create a huge log file.

기본 Elasticsearch log는 ES_HOME/logs/[cluster_name].log  file에 기록된다. 이 file의 기본 level은 INFO인데, 상당한 양의 정보이지만, 동시에 거대한 log file을 생성하지는 않는다.

Logging settings are specified in the logging.yml configuration file. While this is a convenient way of having the log settings in a single place, having to modify this file on every node every time you want to change the settings is painful because it requires nodes restart and unnecessary downtime.

log 설정은 logging.yml 설정 file에 지정된다. 이것은 한 곳에서 log 설정을 하는 편리한 방법이지만, 설정을 변경할 때마다 모든 node에서 이 file을 수정하는 것은, node를 다시 시작해야 하고, 불필요한 downtime이 필요하기 때문에, 매우 어렵다.

Good news! Elasticsearch allows you to  update the logging settings dynamically.

좋은 소식이 있다! Elasticsearch에서 log 설정을 동적으로 update할 수 있다.

The same applies to  the second type of logging that it provides: slowlogs. These provide a very useful insight into how fast or slow queries/indexing process/fetches are performing. The slowlog file will show the query itself, on which shards it ran and how much time it took to complete.

이는 slowlogs를 제공하는 두 번째 log 유형에도 동일하게 적용된다. 이러한 기능을 통해, query/indexing process/fetch가 얼마나 빨리 또는 느리게 수행되는지에 대해 매우 유용하게 이해할 수 있다. slowlog file은 query 자체와 그것이 실행된 shard와 소요 시간을 보여준다.

For the logs, there is a list of "levels" which indicate how granular the logs will be. In the order of granularity from low to high, we have: WARN, INFO, DEBUG, TRACE. Setting the log level to WARN will display only WARN logging messages. On the other hand, setting the level to INFO will display both WARN and INFO logging messages, so this is a "cumulative" set of log messages. Similarly, for TRACE every log message in Elasticsearch will be printed in the log files. Setting the level to TRACE will create a considerable amount of chatter.

log에는, log를 얼마나 자세히 기록할지를 나타내는 "levels" 목록이 있다. 낮은 순서에서 높은 순서로, WARN, INFO, DEBUG, TRACE가 있다. log level을 WARN으로 설정하면 WARN log message만 표시된다. 반면, level을 INFO로 설정하면 WARN 과 INFO log message가 모두 표시되므로, log message가 "누적된" 집합이 된다. 마찬가지로, TRACE의 경우 Elasticsearch의 모든 log message가 log file에 출력된다. level을 TRACE로 설정하면 상당한 양의 log가 발생한다.

Dynamically changing the root logger level

This is not necessarily a tricky task :-), but for completeness sake and to warm up before the following tips&tricks let's first change the logging level for the root logger (the one from which all other loggers inherit). You can run a query like the following, while the cluster is running of course:

꼭 까다로운 작업은 아니지만 :-), 하지만 완벽을 기하기 위해, 다음 tip과 trick을 적용하기 전에, 먼저 root logger(다른 모든 logger가 상속하는 logger)의 log level을 변경해 보자. cluster가 실행되는 동안 다음과 같은 query를 실행할 수 있다.

PUT /_cluster/settings
{"transient":{"logger._root":"DEBUG"}}

Very simple and quick. Now you should see some more interesting things in the logs, some messages that weren't available with INFO or WARN levels.

아주 간단하고 빠르다. 이제 log에서 조금 더 흥미로운 것을 볼 수 있다. INFO 또는 WARN level에서 볼수 없었던 message이다.

Dynamically changing the logger level per Java package

Many times it is very useful to see logging messages that are related to a certain part or functionality of Elasticsearch. Increasing the logging level globally in all modules in Elasticsearch would result in a potentially very large log file, so Elasticsearch allows  individual "sections" to be configured separately.

많은 경우에, Elasticseach의 특정 부분이나 기능과 관련된 log message를 보는 것은 매우 유용하다. Elasticsearch의 모든 module에서 전체적으로 level을 높이면, 잠재적으로 매우 큰 log file이 생성되므로, Elasticsearch는 각각의 "sections"을 개별적으로 설정할 수 있다.

These "sections" are the Java packages and the granularity logging level can be set per Java package. Let's take, for example, the package org.elasticsearch.discovery.zen. It contains classes that deal with Zen discovery in Elasticsearch. If you have an issue with nodes joining/leaving the cluster, or with master election, this would be the package to monitor in your logs:

이들 "sections"는 java package이며, java package별로 세분화된 log level을 설정할 수 있다. 예를 들어, org.elasticsearch.discovery.zen package를 보자.이것은 Elasticsearch에서 Zen discovery를 처리하는 class를 포함한다. node의 cluster joining/leaving 또는 master 선출과 관련된 문제가 있는 경우, log에서 모니터링할 package이다.

PUT /_cluster/settings
{"transient": {"logger.discovery.zen":"TRACE"}}

You notice in the command that "logger" is again present and, yes, it should always be. But, how did we choose "discovery.zen". You remember I mentioned above that the logging level can be set per Java package. Well, "discovery.zen" is just that, without the already present "org.elasticsearch". What if you are interested only in the master node fault detection messages? The Java package containing classes for master fault detection is org.elasticsearch.discovery.zen.fd. And the Elasticsearch command would be:

command에서 "logger"가 다시 나타난 것을 알 수 있다. 그렇다. 항상 그래야 한다. 그런데, 어떻게 "discovery.zen"을 선택했을까? 위에서 Java package별로 log level을 설정할 수 있다고 언급했던 것을 기억할 것이다. "discovery.zen"은, 이미 존재하는 "org.elasticsearch"가 없기 때문이다. master node 장애 감지 message만 관심이 있다면? master 장애 감지를 위한 class가 포함된 Java package는org.elasticsearch.discovery.zen.fd이다. 그래서 Elasticsearch command는 다음과 같다.

PUT /_cluster/settings
{"transient": {"logger.discovery.zen.fd":"TRACE"}}

You got the picture. Some ideas on what to monitor and when:

감 잡았을 것이다. 무엇을 언제 모니터링 할 지를 ...

• org.elasticsearch.env for logging messages referring to node's data paths
  node의 data path를 나타내는 log message
• org.elasticsearch.indices.recovery and <code>org.elasticsearch.index.gateway for logging messages referring to shards recoveries
  shard recovery를 나타내는 log message
• org.elasticsearch.cluster.action.shard for logging messages related to shard states (failed shards, shards starting etc)
  shard state(문제가 있는 shard, 시작하고 있는 shard 등)과 관련된 log message
• org.elasticsearch.snapshots for everything related to snapshots&restore
  snapshot, restore와 관련된 모든 것
• org.elasticsearch.http to monitor for any binding or connectivity/discovery issues between nodes
  binding이나 node간의 connectivity/discovery 문제에 대한 monitor
• org.elasticsearch.marvel.agent.exporter to monitor the Marvel agent
  marvel agent의 monitor

Slowlog settings at index level

You remember that I mentioned the logging settings can be dynamically changed, without nodes or cluster restart. This is valid for slow logs, as well. Imagine you have several tens of indices in your cluster and you suspect that one of the older indices is performing poorly. You'd want to investigate this index more closely and monitor the query response times. The first approach would be to set the slowlog logging level to DEBUG or TRACE cluster-wide and grep the resulting slowlog file for your index name.

node나 cluster를 다시 시작하지 안고, log 설정을 동적으로 변경할 수 있다고 언급한 것을 기억할 것이다. 이는 slow log에도 유효하다. cluster에 수십개의 index가 있고, 기존의 index 중 하나의 성능이 좋지 않다고 추측하는 상황을가정해 보자. 이 index를 더 자세히 조사하고 query response 시간을 모니터링하려 할 것이다. 첫번째 방법은 cluster 전체의 slow log level을 DEBUG 또는 TRACE로 설정하고, 그 결과로 생성되는 slowlog file을 index 이름으로 grep하는 것이다.

This will work, indeed, but why having to grep for the desired index name? Instead, set the slowlog settings at index level, only for the index you are interested into:

이것은 실제로 작동하지만, 원하는 index 이름으로 grep해야 할까? 대신 slowlog 설정을, 관심있는 index에 대해서만, index level로 설정하자.

PUT /test_index/_settings
{
  "index": {
    "search.slowlog.level": "trace",
    "search.slowlog.threshold.query.trace": "100ms"
  }
}

The settings above change the slowlog logging level and the threshold for only the  test_index. In this way you can monitor only the queries for that particular index without the overhead of enabling "trace" logging for all indices.

위의 설정은 test_index에 대해서만 slowlog log level과 임계값(threshold)을 변경한다. 이 방법으로 모든 index에 대해 "trace" log를 활성화하는 overhead 없이, 해당 특정 index에 대한 query만 모니터링할 수 있다.

Logging inside Groovy scripts

Another trick that I found myself using several times to debug Groovy scripts in Elasticsearch is logging inside the script itself to double check that the script is doing what I believe it's doing.

Elasticsearch에서 Groovy script를 debug하기 위해, 자주 사용하는 또 다른 트릭은  script가 하려는 것을 하고 있는지 이중으로 확인하기 위하여, script 자체 내에서 logging하는 것이다.

For example, you have an index with documents that hold a timestamp and you want to filter your documents considering a certain week of the year. Using a script this goes like this:

예를 들어, timestamp를 가지고 있는 document를 포함한 index가 있고, 특정 주(week)를 filtering한다고 해 보자. script를 사용하면, 다음과 같다.

{
  "query": {
    "filtered": {
      "filter": {
        "script": {
          "script": "weeks.contains((int)doc['timestamp'].date.toDateTime().getWeekOfWeekyear())",
          "params": {
            "weeks": [
              18,19,20
            ]
          },
          "lang": "groovy"
        }
      }
    }
  }
}

To check if the correct Groovy method for finding out the week of the year is getWeekOfWeekyear(), this logging can be added to the script, to print in the logs the actual value returned by that method:

년(year)에서 주(week)를 찾는 올바른 Groovy method가 getWeekOfWeekyear() 인지 확인하기 위하여, 이 logging을 script에 추가하여, 해당 method가 return한 실제 값을 log에 출력할 수 있다.

import  org.elasticsearch.common.logging.*;
ESLogger logger = ESLoggerFactory.getLogger('myscript');
logger.logger.log(org.apache.log4j.Level.INFO, (int)doc['timestamp'].date.toDateTime().getWeekOfWeekyear());

And the final query becomes:

그래서, 최종 query는 다음과 같다.

{
  "query": {
    "filtered": {
      "filter": {
        "script": {
          "script": "import  org.elasticsearch.common.logging.*; ESLogger logger=ESLoggerFactory.getLogger('myscript'); logger.logger.log(org.apache.log4j.Level.INFO,(int)doc['timestamp'].date.toDateTime().getWeekOfWeekyear());values.contains((int)doc['timestamp'].date.toDateTime().getWeekOfWeekyear())",
          "params": {
            "values": [
              18,19,20
            ]
          },
          "lang": "groovy"
        }
      }
    }
  }
}

Deprecation Logging in 2.0

Among many other planned goodies in the 2.0 release of Elasticsearch, we also added a new deprecation log to notify users when they use any settings, features, parameters etc which have been deprecated.

Elasticsearch 2.0 의 기타 여러가지 계획된 장점 가운데, deplicate된 설정, 기능, parameter 등이 사용되었을 경우 사용자에게 알리기 위하여 새로운 deprecation log사가 추가되었다.

원문 : Elasticsearch Logging Secrets