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

Управление журналами кластера OpenSearch

Эта статья полезна?
Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

CSS предоставляет запрос журналов и бэкап журналов, позволяя вам легко управлять и анализировать журналы для эффективного обнаружения неисправностей, оптимизации производительности и повышения безопасности системы.

  • Запрос журналов: На странице управления журналами консоли управления CSS вы можете выполнять запрос последних записей журналов по узлу, типу журнала и другим критериям, чтобы быстро находить или диагностировать проблемы.
  • Бэкап журналов: Журналы кластера периодически синхронезируются в OBS бакеты. Вы можете загружать их для глубокого анализа в любое время. Вы можете настроить пользовательские политики бэкапа журналов, указав расписания бэкапа и места хранения. Система делает бэкап всех критических журналов, включая журналы выполнения, журналы медленных запросов и журналы устаревших функций. Они предоставляют исчерпывающие данные для целей аудита и устранения неполадок.

Влияние на Billing

Когда бэкап журналов включен, сгенерированные бэкапы журналов сохраняются в OBS бакетах, что приведёт к дополнительным расходам. Для подробностей см. .

Требования

Создан OBS бакет, используемый для хранения бэкапов журналов. OBS бакет должен соответствовать следующим требованиям:

  • Класс хранения: Стандарт.
  • Регион: такой же, как у кластера.

Log Search

  1. Войдите в консоль управления CSS.
  2. В левой навигационной панели выберите Clusters > OpenSearch.
  3. В списке кластеров щёлкните имя целевого кластера. Отображается страница информации о кластере.
  4. Выберите Logs > Log Search. The Log Search страница отображается.

    Вы можете искать записи по типу журнала, узлу, уровню журнала или ключевому слову. Для детального описания каждого типа журналов см Log Introduction.

    Когда размер лог‑файла достигает 128 МБ или наступает время 00:00 UTC, система автоматически сжимает и архивирует его. Только неархивированные логи отображаются на странице поиска логов, тогда как архивированные логи остаются доступными через функцию лог бэкап.

Лог Бэкап

Логи кластера могут быть резервированы в бакеты OBS, где их можно скачать для углублённого анализа в любое время.

  1. Войдите в консоль управления CSS.
  2. В навигационной панели слева выберите Кластеры > OpenSearch.
  3. В списке кластеров нажмите имя целевого кластера. Отображается страница информации о кластере.
  4. Выберите Логи > Лог Бэкап. The Лог Бэкап страница отображается.
  5. Включить лог бэкап.

    Выполните следующие шаги, чтобы включить лог бэкап. Если он уже включён, пропустите этот шаг.

    1. Нажмите Включить Бэкап. В отображаемом диалоговом окне укажите необходимые параметры.
      Таблица 1 Настройки бэкапа журналов

      Параметр

      Описание

      OBS Бакет

      Выберите OBS Бакет для хранения бэкапов журналов из раскрывающегося списка.

      Если ни один OBS Бакет не соответствует вашим требованиям, нажмите Создать Бакет чтобы перейти в консоль OBS и создать её.

      Чтобы предоставить пользователю IAM доступ к OBS Бакету, необходимо предоставить GetBucketStoragePolicy, GetBucketLocation, ListBucket, и ListAllMyBuckets разрешения этому пользователю.

      Путь бэкапа

      Укажите расположение хранилища лога в OBS бакет.

      Путь бэкапа не может:

      • Содержать следующие символы: \:*?"<>|'{}
      • Начинаться со слеша (/).
      • Начинаться или заканчиваться точкой (.).
      • Содержать более двух последовательных слешей (/) или точек (.).
      • Превышать 512 символов.

      IAM Agency

      Чтобы выполнить бэкап данных в OBS бакет, необходимо иметь разрешение на запись в него. Настроив IAM agency, вы можете предоставить CSS доступ к ресурсам OBS через связанный аккаунт.

      • Если вы настраиваете агентство в первый раз, нажмите Автоматически создать IAM Agency чтобы создать css-obs-agency.
      • Если ранее было автоматически создано IAM‑агентство, вы можете щелкнуть Авторизация в один клик чтобы разрешения OBS Administrator удалялись автоматически, а вместо этого автоматически добавлялись следующие пользовательские политики для реализации более тонкого контроля разрешений.
        "obs:bucket:GetBucketLocation",
        "obs:object:GetObjectVersion",
        "obs:object:GetObject",
        "obs:object:DeleteObject",
        "obs:bucket:HeadBucket",
        "obs:bucket:GetBucketStoragePolicy",
        "obs:object:DeleteObjectVersion",
        "obs:bucket:ListBucketVersions",
        "obs:bucket:ListBucket",
        "obs:object:PutObject"
      • Когда в бакетах OBS используется шифрование SSE-KMS, IAM‑агентству должны быть предоставлены разрешения KMS. Вы можете щелкнуть Автоматически создать IAM‑агентство и Авторизация в один клик чтобы следующие пользовательские политики создавались автоматически.
        "kms:cmk:create",
        "kms:dek:create",
        "kms:cmk:get",
        "kms:dek:decrypt",
        "kms:cmk:list"
      • Чтобы использовать Автоматически создать IAM‑агентство и Авторизация в один клик, требуются следующие минимальные разрешения:
        "iam:agencies:listAgencies",
        "iam:roles:listRoles",
        "iam:agencies:getAgency",
        "iam:agencies:createAgency",
        "iam:permissions:listRolesForAgency",
        "iam:permissions:grantRoleToAgency",
        "iam:permissions:listRolesForAgencyOnProject",
        "iam:permissions:revokeRoleFromAgency",
        "iam:roles:createRole"
      • Чтобы использовать IAM‑агентство, требуются следующие минимальные разрешения:
        "iam:agencies:listAgencies",
        "iam:agencies:getAgency",
        "iam:permissions:listRolesForAgencyOnProject",
        "iam:permissions:listRolesForAgency"

      ПРЕДУПРЕЖДЕНИЕ:

      Имя агентства может содержать только буквы (чувствительные к регистру), цифры, символы подчёркивания (_) и дефисы (-). В противном случае резервное копирование завершится неудачей.

      Определить, включать ли Автоматическое резервное копирование на основе требований сервиса.

      • Чтобы включить автоматическое, периодическое резервное копирование журналов, выберите Автоматическое резервное копирование, и задайте политику резервного копирования. Для получения дополнительной информации см. Таблица 2.
      • Если ручное резервное копирование журналов достаточно, снимите выделение Автоматическое резервное копирование.

    2. Нажмите OK чтобы включить резервное копирование журналов.

      Информация о конфигурации будет отображена на Резервное копирование журналов вкладке.

  6. Бэкап логов. Доступны два варианта: автоматический или вручную.

    Автоматический бэкап логов: Логи резервируются периодически в соответствии с предустановленной политикой.

    1. На Бэкап логов странице, нажмите Изменить настройки справа.
    2. В Изменить настройки диалоговом окне, выберите Автоматический бэкап, а также настройте политику автоматического бэкапа.
      Таблица 2 Настройки автоматического бэкапа

      Параметр

      Описание

      Часовой пояс

      Выберите часовой пояс для времени начала бэкапа.

      Время начала бэкапа

      Укажите время начала автоматического бэкапа.

      Выберите значение из выпадающего списка. Диапазон значений от 00:00 до 23:00. Бэкап всегда происходит в начале часа.

    3. Нажмите OK чтобы включить автоматический бэкап журналов.

      Задачи автоматического бэкапа журналов отображаются в списке задач. Когда Статус задачи в списке задач меняется на Успешно, бэкап выполнен успешно.

    4. Если автоматический бэкап журналов не требуется, нажмите Изменить настройки. В отображаемом диалоговом окне снимите выделение Автоматический бэкап, и нажмите OK. В отображаемом диалоговом окне подтверждения нажмите OK.

      Отключение лог Бэкапа не приводит к автоматическому удалению ранее автоматически созданных лог Бэкапов. Вместо этого вам необходимо вручную удалить их в консоли OBS.

    Ручной лог Бэкап: Сразу сделайте резервную копию логов.

    1. На Лог Бэкап странице, нажмите Резервное копирование вручную в Задачи лог Бэкапа.
    2. В отображаемом диалоговом окне подтвердите путь лог бэкапа и нажмите OK.

      Задача лог бэкапа отображается в списке задач. Когда Статус задачи в списке задач меняется на Успешно, бэкап выполнен успешно.

  7. Проверьте резервные лог-файлы.

    Логи резервируются инкрементно. После успешного бэкапа вы можете получить доступ к целевому OBS бакету, чтобы получить полные лог-файлы, щёлкнув Путь к логам.

    Таблица 3 перечисляет типы логов, где clustername указывает имя кластера.

    Таблица 3 Типы логов

    Имя лога

    Описание

    clustername_deprecation.log

    Файл журнала устареваний

    clustername_index_indexing_slowlog.log

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

    clustername_index_search_slowlog.log

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

    clustername.log

    Файл журнала запуска

    clustername_access.log

    Файл журнала доступа

  8. Если функция лог бэкапа более не нужна, вы можете отключить её.

    На Лог Бэкап страница, щелкните Отключить Бэкап. В отображаемом диалоговом окне щелкните OK. Отключение лог бэкапа не удаляет автоматически существующие бэкапы логов. Вместо этого вам необходимо вручную удалить их в консоли OBS.

Введение в лог

Таблица 4 Введение в лог

Тип лога

Описание

Назначение

Логи выполнения

Логи выполнения, или основные логи, фиксируют состояние кластера и ключевую информацию о операциях записи и запросах. Например, логи записи фиксируют операции, такие как создание индекса, обновление сопоставления индекса и исчерпание очереди записи; а логи запросов фиксируют статус очереди запросов и исключения запросов.

Проверьте статус и операции записи и запросов каждого узла кластера, включая связность между узлами, full GC, создание или удаление индекса и ошибки запросов на уровне кластера.

Логи медленной индексации

Логи медленной индексации фиксируют операции индексации (например, bulk, index, update и delete), которые заняли продолжительное время для завершения, помогая выявлять узкие места в производительности.

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

Логи медленных запросов

Логи медленных запросов фиксируют поисковые запросы, которые заняли продолжительное время для завершения. Они помогают мониторить и анализировать длительные поисковые запросы, чтобы выявлять узкие места в производительности, оптимизировать SQL‑запросы и улучшать общую производительность системы.

В случае медленной работы запросов вы можете запросить логи медленных запросов, чтобы определить причину.

Логи устареваний

Логи устареваний фиксируют предупреждения об устаревании. Предупреждения об устаревании записываются в этот Лог, когда вы используете API, конфигурации или функции, отмеченные для удаления в будущих версиях.

Проверьте API или функции, срок действия которых истекает в будущих версиях.

Логи доступа

Логи доступа фиксируют запросы к кластеру, такие как путь запроса и адрес источника.

Вы не можете проверять логи доступа в консоли. Чтобы проверить их, вам необходимо создать резервную копию в OBS Бакет или сначала перенести их в целевой кластер.

Если наблюдается всплеск запросов к сервису, вы можете проанализировать источники запросов и пути, проверяя логи доступа.

  • Описание лога выполнения

    Логи выполнения фиксируют статус кластера и ключевую информацию о операциях записи и запросов. Например, запись в логе ниже указывает, что индекс с именем 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. Имя индекса и 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. Исходные и целевые адреса запроса

FAQ: Как изменить уровни лога?

Log4j2 используется как компонент лога в кластерах OpenSearch. Поддерживаются несколько уровней лога (ERROR, WARN, INFO, DEBUG и TRACE). Уровень лога по умолчанию – INFO. Для облегчения поиска и устранения неполадок вы можете динамически изменять уровни лога.

  • INFO — уровень логов по умолчанию. Уровни в порядке увеличения детализации: ERROR, WARN, INFO, DEBUG и TRACE. Когда установлен INFO, вы будете видеть логи для него и всех уровней более высокой серьёзности (ERROR и WARN), в то время как более детальные уровни (DEBUG и TRACE) исключаются.
  • Вы можете изменить уровень логов указанного модуля в реальном времени через API OpenSearch.

Пример

  1. Войдите в OpenSearch Dashboards и перейдите на страницу выполнения команд. Кластеры OpenSearch поддерживают несколько методов доступа. В этой теме OpenSearch Dashboards используется как пример для описания процедур операций.
    1. Войдите в консоль управления CSS.
    2. В навигационной панели слева выберите Кластеры > OpenSearch.
    3. В списке кластеров найдите целевой кластер и нажмите Dashboards в Операция столбце, чтобы войти в OpenSearch Dashboards.
    4. В левой навигационной панели выберите Инструменты разработки.

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

  2. Выполните следующую команду, чтобы изменить уровень журнала модуля действия на DEBUG:
    PUT _cluster/settings
    {
      "persistent": {
        "logger": {
          "org.opensearch.action": "DEBUG"
        }
      }
    }
  3. Выполните следующую команду, чтобы восстановить уровень журнала по умолчанию INFO:
    PUT _cluster/settings
    {
      "persistent": {
        "logger": {
          "org.opensearch.action": null
        }
      }
    }

FAQ: Как включить трассировку журналов?

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

Включение трассировки журналов является непостоянной конфигурацией и будет отключено при перезапуске кластера.

Руководство по эксплуатации

  1. Войдите в OpenSearch Dashboards и перейдите на страницу выполнения команд. Кластеры OpenSearch поддерживают несколько методов доступа. В этой теме в качестве примера используется OpenSearch Dashboards для описания процедур выполнения.
    1. Войдите в консоль управления CSS.
    2. В навигационной панели слева выберите Кластеры > OpenSearch.
    3. В списке кластеров найдите целевой кластер и нажмите Dashboards в Операция столбце, чтобы войти в OpenSearch Dashboards.
    4. В левой навигационной панели выберите Dev Tools.

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

  2. Выполните следующую команду, чтобы включить 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"
      }
    }
  3. Перейдите на страницу деталей журнала, чтобы просмотреть трассировочные логи.
    1. В списке кластеров щелкните имя целевого кластера. Страница информации о кластере отображается.
    2. Выберите Логи > Поиск логов. The Поиск логов страница отображается.
    3. Выберите все уровни логов (обязательно) и просмотрите трассировочные логи.
Поддержка Юридические документы
© 2026 Cloud.ru