Облачная платформаAdvanced

Запрос журналов

Эта статья полезна?

Язык статьи: Русский

Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Во время планового O&M, когда кластер Elasticsearch становится медленным, возвращает ошибку запроса или отображает желтый статус, команде O&M необходимо сразу получать соответствующую информацию. CSS предоставляет функцию log query, которая агрегирует журналы серверов в консоль, где вы можете выполнять запросы по узлу и log level за секунды. Анализируя run logs, slow query logs и deprecation logs, вы можете быстро определить коренные причины сбоев и проблем. Кроме того, вы можете динамически изменять log level и включать trace logging для отладки, получая самые подробные записи журналов без перезапуска кластера.

Запрос недавних журналов

Запрос недавно сгенерированных журналов, которые ещё не архивированы.

Войдите в консоль управления CSS.

В панели навигации слева выберите Clusters > Elasticsearch.

В списке кластеров нажмите название целевого кластера. Отобразится страница информации о кластере.

Выберите Logs > Log Search. Отобразится страница Log Search.

Вы можете искать записи по типу журнала, узлу, log level или ключевому слову. Подробное описание каждого типа журналов см. в Log Types.

Caution

Когда размер файла журнала достигает 128 МБ или наступает 00:00 UTC, система автоматически сжимает и архивирует его. На странице поиска журналов отображаются только неархивированные журналы, тогда как архивированные доступны через функцию log backup. Дополнительную информацию см. в Backing Up Logs to OBS.

Динамическое изменение log level

В кластерах Elasticsearch в качестве компонента журналирования используется Log4j2. Поддерживается несколько log level (ERROR, WARN, INFO, DEBUG и TRACE). Значение log level по умолчанию — INFO. Для упрощения устранения неполадок и отладки вы можете динамически изменять log level.

INFO — log level по умолчанию. Уровни, в порядке увеличения детализации, следующие: ERROR, WARN, INFO, DEBUG и TRACE. При установленном INFO вы будете видеть журналы этого уровня и всех более серьезных уровней (ERROR и WARN), тогда как более подробные уровни (DEBUG и TRACE) исключаются.

Вы можете изменить log level указанного модуля в реальном времени с помощью API Elasticsearch.

Войдите в Kibana и перейдите на страницу выполнения команд. Кластеры Elasticsearch поддерживают несколько методов доступа. В данном разделе в качестве примера используется Kibana для описания процедур выполнения.

Войдите в консоль управления CSS.

В панели навигации слева выберите Clusters > Elasticsearch.

В списке кластеров найдите целевой кластер и нажмите Kibana в столбце Operation, чтобы войти в консоль Kibana.

В левой панели навигации выберите Dev Tools.

Левая часть консоли — command input box, а треугольный значок в её правом верхнем углу — execution button. Правая часть показывает execution result.

Выполните следующую команду, чтобы изменить уровень журналирования, например, на DEBUG:

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

Обновите страницу log query и проверьте, были ли сгенерированы DEBUG‑журналы. После завершения текущей задачи всегда следует вернуть уровень журналирования к настройке по умолчанию.

Выполните следующую команду, чтобы восстановить уровень журналирования по умолчанию INFO:

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

Включение Trace Logging

Для анализа деталей коммуникации на уровне HTTP или транспортного уровня можно включить trace logging для модуля HTTP или Transport, чтобы получить подробные записи журналов.

Войдите в Kibana и перейдите на страницу command execution page. Кластеры Elasticsearch поддерживают несколько методов доступа. В этой теме в качестве примера используется Kibana для описания процедур выполнения.

Войдите в консоль управления CSS.

В панели навигации слева выберите Clusters > Elasticsearch.

В списке кластеров найдите целевой кластер и нажмите Kibana в столбце Operation, чтобы войти в консоль Kibana.

В левой панели навигации выберите Dev Tools.

Левая часть консоли — это command input box, а треугольный значок в её правом верхнем углу является execution button. Правая часть отображает результат выполнения.

Выполните следующую команду, чтобы включить trace logging:

PUT _cluster/settings
{
  "transient": {
    "logger.org.elasticsearch.transport.TransportService.tracer": "trace",
    "transport.tracer.include": "",
    "http.tracer.include": "",
    "logger.org.elasticsearch.http.HttpTracer": "trace"
  }
}

Caution

Включение trace logging является непостоянной конфигурацией и будет отключено после перезапуска кластера. Обычно оно используется для экстренного захвата пакетов и их анализа при устранении неполадок.

Перейдите на страницу log details, чтобы просмотреть trace logs.

В списке кластеров нажмите название target cluster. Отобразится страница cluster information.

Выберите Logs > Log Search. Отобразится страница Log Search.

Выберите все уровни журналов (обязательно) и просмотрите trace logs.

Типы журналов

Table 1 Представление различных типов журналов
Тип журнала	Описание	Назначение
Run logs	Run logs, или основные журналы, фиксируют состояние кластера и ключевую информацию о операциях записи и запросов. Например, журналы записи фиксируют такие операции, как создание индекса, обновление сопоставления индекса и исчерпание очереди записи; а журналы запросов фиксируют состояние очереди запросов и исключения запросов.	Проверьте состояние и операции записи и запросов каждого узла кластера, включая связность между узлами, полную сборку мусора (full GC), создание или удаление индексов и ошибки запросов на уровне кластера.
Slow indexing logs	Slow indexing logs записывают операции индексации (например bulk, index, update и delete), которые заняли длительное время, помогая вам выявлять узкие места в производительности.	В случае медленной записи вы можете выполнить запрос к slow indexing logs, чтобы определить причину.
Slow query logs	Slow query logs записывают запросы поиска, которые заняли длительное время. Они помогают вам мониторить и анализировать ресурсоёмкие запросы поиска, чтобы вы могли выявлять узкие места в производительности, оптимизировать SQL‑запросы и повышать общую производительность системы.	В случае медленной работы запросов вы можете выполнить запрос к slow query logs, чтобы определить причину.
Deprecation logs	Deprecation logs записывают предупреждения об устаревании. Предупреждения об устаревании записываются в этот журнал, когда вы используете API, конфигурации или функции, помеченные для удаления в будущих версиях.	Проверьте API или функции, которые скоро будут устаревать в будущих версиях.
Access logs	Access logs записывают запросы доступа к кластеру, такие как путь запроса и исходный адрес. Вы не можете просматривать access logs в консоли. Чтобы просмотреть их, необходимо сначала сохранить их в OBS bucket или перенести в target cluster.	Если наблюдается всплеск запросов к сервису, вы можете проанализировать источники запросов и пути, проверив access logs.

Run log description

Run logs записывают статус кластера и ключевую информацию о операциях записи и запросов. Например, запись журнала ниже показывает, что был создан индекс test, а затем статус кластера изменился с YELLOW на GREEN.

Рисунок 1 Пример журналов выполнения

Содержимое журнала:

1. Время создания журнала

2. Уровень журнала, который может быть DEBUG, INFO, WARN или ERROR

3. Модуль, генерирующий журнал

4. Имя узла, генерирующего журнал

5. Содержимое журнала

Описание журнала медленной индексации

Журналы медленной индексации фиксируют операции индексации, которые заняли длительное время. Например, запись журнала ниже показывает запрос индексации, продолжительность которого превысила установленный порог. Журнал содержит имя индекса, длительность и содержимое запроса.

Рисунок 2 Пример журналов медленной индексации

Содержимое журнала:

1. Время создания журнала

2. Уровень журнала, который может быть DEBUG, INFO, WARN или ERROR

3. Модуль, генерирующий журнал

4. Имя узла, генерирующего журнал

5. Имя индекса и ID

6. Содержание журнала. В этом примере журнал зафиксировал продолжительность выполнения запроса, тип индекса и тело запроса индекса.

Описание журнала медленных запросов

Журналы медленных запросов фиксируют поисковые запросы, выполнение которых заняло длительное время. Например, запись журнала ниже показывает поисковый запрос, который превысил установленный порог. Журнал содержит имя индекса, продолжительность и содержание запроса.

Figure 3 Пример журналов медленных запросов

Содержание журнала:

1. Время создания журнала

2. Уровень журнала, который может быть DEBUG, INFO, WARN или ERROR

3. Модуль, генерирующий журнал

4. Имя узла, генерирующего журнал

5. Имя индекса и ID шарда

6. Содержание журнала. В этом примере журнал зафиксировал продолжительность запроса, количество совпадений и тело запроса.

Описание журнала устаревших функций

Журналы устаревших функций фиксируют предупреждения об устаревании. Например, запись журнала ниже указывает, что GET /_cat/master устарела и должна быть заменена на GET /_cat/cluster_manager.

Figure 4 Пример журналов устаревших функций

Содержимое лога:

1. Время создания лога

2. Уровень лога, который может быть только DEPRECATION.

3. Модуль, генерирующий лог

4. Имя узла, генерирующего лог

5. Содержимое лога

Описание журнала доступа

Журналы доступа фиксируют запросы доступа к кластеру и исходные адреса. Например, запись журнала ниже содержит информацию об источнике для операции /_snapshot/my_backup/my_snapshot/_restore?pretty=true.

Рисунок 5 Пример журналов доступа