Во время рутинного O&M, когда кластер OpenSearch становится медленным, возвращает ошибку при запросе или показывает желтый статус, команде O&M необходимо сразу получать соответствующую информацию. CSS предоставляет функцию запроса логов, которая агрегирует базовые серверные логи в консоль, где их можно запросить по узлу и уровню лога за секунды. Анализируя журналы выполнения, журналы медленных запросов и журналы устаревания, вы быстро находите коренные причины сбоев и проблем. Кроме того, вы можете динамически изменять уровни логов и включать трассировочное логирование для отладки, получая самые подробные записи логов без перезапуска кластера.
Запрос недавних логов
Запрос недавно сгенерированных логов, которые ещё не архивированы.
- Войдите в консоль управления CSS.
- В панели навигации слева выберите Clusters > OpenSearch.
- В списке кластеров нажмите название целевого кластера. Отобразится страница информации о кластере.
- Выберите Logs > Log Search. Отобразится страница Log Search.
Вы можете искать записи по типу лога, узлу, уровню лога или ключевому слову. Подробное описание каждого типа логов см. в Log Types.
CautionКогда размер файла лога достигает 128 МБ или наступает 00:00 UTC, система автоматически сжимает и архивирует его. На странице поиска логов отображаются только неархивированные логи, тогда как архивированные логи остаются доступными через функцию резервного копирования логов. Подробнее см. в Backing Up Logs to OBS.
Динамическая настройка уровней логов
В кластерах OpenSearch в качестве компонента логов используется Log4j2. Поддерживается несколько уровней логов (ERROR, WARN, INFO, DEBUG и TRACE). Уровень логов по умолчанию — INFO. Для упрощения устранения неполадок и отладки вы можете динамически изменять уровни логов.
- INFO — уровень логов по умолчанию. Уровни, в порядке увеличения детализации, следующие: ERROR, WARN, INFO, DEBUG и TRACE. При установленном уровне INFO вы будете видеть логи этого уровня и всех более серьезных уровней (ERROR и WARN), тогда как более подробные уровни (DEBUG и TRACE) исключаются.
- Вы можете изменять уровень лога указанного модуля в реальном времени с помощью API OpenSearch.
- Войдите в OpenSearch Dashboards и перейдите на страницу выполнения команд. Кластеры OpenSearch поддерживают несколько методов доступа. В данном разделе в качестве примера используется OpenSearch Dashboards для описания процедур выполнения.
- Войдите в консоль управления CSS.
- В панели навигации слева выберите Clusters > OpenSearch.
- В списке кластеров найдите целевой кластер и нажмите Dashboards в столбце Operation, чтобы войти в OpenSearch Dashboards.
- В левой панели навигации выберите Dev Tools.
Левая часть консоли — это поле ввода команды, а треугольный значок в её правом верхнем углу является кнопкой выполнения. Правая часть отображает результат выполнения.
- Выполните следующую команду, чтобы изменить уровень журналирования, например, на DEBUG:PUT _cluster/settings{"persistent": {"logger": {"org.opensearch.action": "DEBUG"}}}
- Обновите страницу запроса журналов и проверьте, были ли сгенерированы журналы DEBUG. После завершения текущей задачи всегда следует возвращать уровень журналирования к настройке по умолчанию.
- Выполните следующую команду, чтобы восстановить уровень журналирования по умолчанию INFO:PUT _cluster/settings{"persistent": {"logger": {"org.opensearch.action": null}}}
Включение трассировочного журналирования
Для анализа деталей коммуникации на уровне HTTP или транспортного уровня можно включить трассировочное журналирование для модуля HTTP или Transport, чтобы получить подробные записи журналов.
- Войдите в OpenSearch Dashboards и перейдите на страницу выполнения команд. Кластеры OpenSearch поддерживают несколько методов доступа. В данном разделе в качестве примера используется OpenSearch Dashboards для описания процедур операций.
- Войдите в консоль управления CSS.
- В панели навигации слева выберите Clusters > OpenSearch.
- В списке кластеров найдите целевой кластер и нажмите Dashboards в столбце Operation, чтобы войти в OpenSearch Dashboards.
- В левой панели навигации выберите Dev Tools.
Левая часть console — это command input box, а triangle icon в её правом верхнем углу является execution button. Правая часть отображает execution result.
- Выполните следующую команду, чтобы включить trace logging:PUT _cluster/settings{"transient": {"logger.org.opensearch.transport.TransportService.tracer": "trace","transport.tracer.include": "","http.tracer.include": "","logger.org.opensearch.http.HttpTracer": "trace"}}Caution
Включение trace logging является непостоянной конфигурацией и будет отключено после перезапуска кластера. Обычно его используют для экстренного захвата пакетов и их анализа при устранении неполадок.
- Перейдите на log details page, чтобы просмотреть trace logs.
- В cluster list нажмите имя target cluster. Отобразится cluster information page.
- Выберите Logs > Log Search. Отобразится страница Log Search.
- Выберите все log levels (обязательно) и просмотрите trace logs.
Log Types
Log Type | Description | Purpose |
|---|---|---|
Run logs | Run logs, или main logs, фиксируют состояние кластера и ключевую информацию о операциях записи и запросов. Например, write logs фиксируют операции, такие как index creation, index mapping update и write queue exhaustion; а query logs фиксируют query queue status и query exceptions. | Проверьте состояние и операции записи и запросов каждого узла кластера, включая inter-node connectivity, full GC, создание или удаление индекса и ошибки запросов на уровне кластера. |
Slow indexing logs | Slow indexing logs фиксируют операции индексации (например bulk, index, update и delete), которые заняли длительное время, помогая вам выявлять узкие места в производительности. | В случае медленной записи вы можете выполнить запрос к Slow indexing logs, чтобы определить причину. |
Slow query logs | Slow query logs фиксируют запросы поиска, которые заняли длительное время. Они помогают вам мониторить и анализировать ресурсоёмкие запросы поиска, чтобы вы могли выявлять узкие места в производительности, оптимизировать SQL queries и повышать общую производительность системы. | В случае медленной производительности запросов вы можете выполнить запрос к Slow query logs, чтобы определить причину. |
Deprecation logs | Deprecation logs фиксируют предупреждения об устаревании. Предупреждения об устаревании записываются в этот журнал, когда вы используете API, конфигурации или функции, помеченные для удаления в будущих версиях. | Проверьте API или функции, которые скоро будут устаревать в будущих версиях. |
Access logs | Access logs фиксируют запросы доступа к кластеру, такие как путь запроса и исходный адрес. Вы не можете просматривать Access logs в консоли. Чтобы просмотреть их, необходимо сначала создать резервную копию в OBS bucket или перенести их в целевой кластер. | Если наблюдается всплеск запросов к сервису, вы можете проанализировать источники запросов и пути, проверив 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. Содержание журнала. В этом примере журнал записал продолжительность выполнения запроса, тип индекса и тело запроса индекса.
- Описание журнала медленных запросов
Журналы медленных запросов фиксируют поисковые запросы, выполнение которых заняло длительное время. Например, запись журнала ниже показывает поисковый запрос, который длился дольше установленного порога. Журнал содержит имя индекса, продолжительность и содержание запроса.
Рисунок 3 Пример журнала медленных запросов
Содержание журнала:
- 1. Время создания журнала
- 2. Уровень журнала, который может быть DEBUG, INFO, WARN или ERROR
- 3. Модуль, генерирующий журнал
- 4. Имя узла, генерирующего журнал
- 5. Имя индекса и shard ID
- 6. Содержание журнала. В этом примере журнал записал продолжительность запроса, количество совпадений и тело запроса.
- Описание журнала устаревания
Журналы устаревания фиксируют предупреждения об устаревании. Например, запись журнала ниже указывает, что GET /_cat/master устарел и его следует заменить на GET /_cat/cluster_manager.
Рисунок 4 Пример журнала устаревания
Содержимое журнала:
- 1. Время создания журнала
- 2. Уровень журнала, который может быть только DEPRECATION.
- 3. Модуль, генерирующий журнал
- 4. Имя узла, генерирующего журнал
- 5. Содержимое журнала
- Описание журнала доступа
Журналы доступа фиксируют запросы доступа к кластеру и исходные адреса. Например, запись журнала ниже содержит информацию об источнике для операции /_snapshot/my_backup/my_snapshot/_restore?pretty=true.
Рисунок 5 Пример журнала доступа
Содержимое журнала:
- 1. Время создания журнала
- 2. Имя узла, генерирующего журнал
- 3. Имя потока, генерирующего журнал
- 4. Уровень журнала, который может быть DEBUG, INFO, WARN или ERROR
- 5. Метод запроса журнала
- 6. Путь запроса
- 7. Исходные и целевые адреса запроса