Install and upgrade OpenSearch

• 1: Установка OpenSearch
• 1.1: Docker
• 1.2: Установка OpenSearch на Debian
• 2: Установка OpenSearch Dashboards
• 2.1: Запуск OpenSearch Dashboards с использованием Docker
• 2.2: Установка OpenSearch Dashboards (Debian)
• 2.3: Настройка TLS для OpenSearch Dashboards
• 3: configuring opensearch
• 3.1: Настройки доступности и восстановления
• 3.2: Конфигурация и системные настройки
• 3.3: Сетевые настройки
• 3.4: Настройки обнаружения и шлюза
• 3.5: Настройки безопасности
• 3.6: Настройки предохранителей
• 3.7: Настройка кластера
• 3.8: Настройка индекса
• 3.9: Настройки поиска
• 3.10: Настройки плагинов
• 3.11: Экспериментальные флаги функций
• 3.12: Logs
• 4: Сравнение ОС
• 5: Настройка OpenSearch Dashboards
• 6: Upgrading OpenSearch
• 6.1: Приложение по обновлениям
• 6.2: Постепенное обновление
• 6.3: Лаборатория последовательного обновления
• 7: Установка плагинов
• 7.1: Дополнительные плагины
• 7.2: mapper-size
• 7.3: ingest-attachment
• 8: Управление плагинами OpenSearch Dashboards

1 - Установка OpenSearch

Рекомендации по файловой системе

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

Совместимость с Java

Распределение OpenSearch для Linux поставляется с совместимой версией JDK Adoptium Java в каталоге jdk. Чтобы узнать версию JDK, выполните команду ./jdk/bin/java -version. Например, архив OpenSearch 1.0.0 поставляется с Java 15.0.1+9 (не LTS), OpenSearch 1.3.0 поставляется с Java 11.0.14.1+1 (LTS), а OpenSearch 2.0.0 поставляется с Java 17.0.2+8 (LTS). OpenSearch тестируется со всеми совместимыми версиями Java.

Чтобы использовать другую установку Java, установите переменную окружения OPENSEARCH_JAVA_HOME или JAVA_HOME на расположение установки Java. Например:

export OPENSEARCH_JAVA_HOME=/path/to/opensearch-3.1.0/jdk

Сетевые требования

Следующие порты необходимо открыть для компонентов OpenSearch.

Важные настройки

Для рабочих нагрузок в производственной среде убедитесь, что настройка Linux vm.max_map_count установлена как минимум на 262144. Даже если вы используете образ Docker, установите это значение на хост-машине. Чтобы проверить текущее значение, выполните следующую команду:

cat /proc/sys/vm/max_map_count

Чтобы увеличить значение, добавьте следующую строку в файл /etc/sysctl.conf:

vm.max_map_count=262144

Затем выполните команду sudo sysctl -p, чтобы перезагрузить настройки.

Для рабочих нагрузок Windows вы можете установить vm.max_map_count, выполнив следующие команды:

wsl -d docker-desktop
sysctl -w vm.max_map_count=262144

Пример файла docker-compose.yml

Файл docker-compose.yml также содержит несколько ключевых настроек:

bootstrap.memory_lock: true

Эта настройка отключает свопинг (вместе с memlock). Свопинг может значительно снизить производительность и стабильность, поэтому вы должны убедиться, что он отключен на производственных кластерах.

Включение настройки bootstrap.memory_lock заставит JVM зарезервировать всю необходимую память. Руководство по настройке сборки мусора Java SE Hotspot VM документирует резервирование 1 гигабайта (ГБ) нативной памяти для метаданных классов по умолчанию. В сочетании с кучей Java это может привести к ошибке из-за нехватки нативной памяти на ВМ с меньшим объемом памяти, чем эти требования. Чтобы предотвратить ошибки, ограничьте размер резервируемой памяти с помощью -XX:CompressedClassSpaceSize или -XX:MaxMetaspaceSize и установите размер кучи Java, чтобы убедиться, что у вас достаточно системной памяти.

OPENSEARCH_JAVA_OPTS: -Xms512m -Xmx512m

Эта настройка устанавливает размер кучи Java (рекомендуем использовать половину системной ОЗУ).

OpenSearch по умолчанию использует -Xms1g -Xmx1g для выделения памяти кучи, что имеет приоритет над конфигурациями, указанными с использованием процентной нотации (-XX:MinRAMPercentage, -XX:MaxRAMPercentage). Например, если вы установите OPENSEARCH_JAVA_OPTS=-XX:MinRAMPercentage=30 -XX:MaxRAMPercentage=70, предустановленные значения -Xms1g -Xmx1g переопределят эти настройки. При использовании OPENSEARCH_JAVA_OPTS для определения выделения памяти убедитесь, что вы используете нотацию -Xms и -Xmx.

nofile: 65536

Эта настройка устанавливает лимит в 65536 открытых файлов для пользователя OpenSearch.

port: 9600

Эта настройка позволяет вам получить доступ к Анализатору производительности на порту 9600.

Не объявляйте одни и те же параметры JVM в нескольких местах, так как это может привести к непредсказуемому поведению или сбою запуска службы OpenSearch. Если вы объявляете параметры JVM с помощью переменной окружения, такой как OPENSEARCH_JAVA_OPTS=-Xms3g -Xmx3g, то вам следует закомментировать любые ссылки на этот параметр JVM в config/jvm.options. Напротив, если вы определяете параметры JVM в config/jvm.options, то не следует определять эти параметры JVM с помощью переменных окружения.

Важные системные свойства

OpenSearch имеет ряд системных свойств, перечисленных в следующей таблице, которые вы можете указать в файле config/jvm.options или в переменной OPENSEARCH_JAVA_OPTS, используя нотацию аргументов командной строки -D.

1.1 - Docker

Docker значительно упрощает процесс настройки и управления вашими кластерами OpenSearch. Вы можете загружать официальные образы из Docker Hub или Amazon Elastic Container Registry (Amazon ECR) и быстро развернуть кластер, используя Docker Compose и любой из примеров файлов Docker Compose, включенных в этот гид. Опытные пользователи OpenSearch могут дополнительно настроить свое развертывание, создав собственный файл Docker Compose.

Контейнеры Docker являются портативными и будут работать на любом совместимом хосте, который поддерживает Docker (таких как Linux, MacOS или Windows). Портативность контейнера Docker предлагает гибкость по сравнению с другими методами установки, такими как RPM или ручная установка из Tarball, которые требуют дополнительной конфигурации после загрузки и распаковки.

Этот гид предполагает, что вы уверенно работаете с интерфейсом командной строки (CLI) Linux. Вы должны понимать, как вводить команды, перемещаться между директориями и редактировать текстовые файлы. Для получения помощи по Docker или Docker Compose обратитесь к официальной документации на их веб-сайтах.

Установка Docker и Docker Compose

Посетите страницу Get Docker для получения рекомендаций по установке и настройке Docker для вашей среды. Если вы устанавливаете Docker Engine с помощью CLI, то по умолчанию Docker не будет иметь никаких ограничений на доступные ресурсы хоста. В зависимости от вашей среды вы можете настроить ограничения ресурсов в Docker. См. раздел Runtime options with Memory, CPUs, and GPUs для получения информации.

Пользователи Docker Desktop должны установить использование памяти хоста на минимум 4 ГБ, открыв Docker Desktop и выбрав Settings → Resources.

Docker Compose — это утилита, которая позволяет пользователям запускать несколько контейнеров с одной командой. Вы передаете файл Docker Compose при его вызове. Docker Compose читает эти настройки и запускает запрашиваемые контейнеры. Docker Compose устанавливается автоматически с Docker Desktop, но пользователи, работающие в командной строке, должны установить Docker Compose вручную. Вы можете найти информацию о установке Docker Compose на официальной странице Docker Compose GitHub.

Если вам нужно установить Docker Compose вручную и ваш хост поддерживает Python, вы можете использовать pip для автоматической установки пакета Docker Compose.

Настройка важных параметров хоста

Перед установкой OpenSearch с использованием Docker настройте следующие параметры. Это самые важные настройки, которые могут повлиять на производительность ваших сервисов, но для дополнительной информации смотрите раздел о важных системных настройках.

Настройки для Linux

Для среды Linux выполните следующие команды:

1. Отключите производительность памяти с помощью свопинга для улучшения производительности:

   sudo swapoff -a
   

2. Увеличьте количество доступных для OpenSearch карт памяти:

   # Отредактируйте файл конфигурации sysctl
   sudo vi /etc/sysctl.conf
   
   # Добавьте строку для определения желаемого значения
   # или измените значение, если ключ существует,
   # а затем сохраните изменения.
   vm.max_map_count=262144
   
   # Перезагрузите параметры ядра с помощью sysctl
   sudo sysctl -p
   
   # Проверьте, что изменение было применено, проверив значение
   cat /proc/sys/vm/max_map_count
   

Настройки для Windows

Для рабочих нагрузок Windows, использующих WSL через Docker Desktop, выполните следующие команды в терминале, чтобы установить vm.max_map_count:

wsl -d docker-desktop
sysctl -w vm.max_map_count=262144

Запуск OpenSearch в контейнере Docker

Официальные образы OpenSearch размещены на Docker Hub и Amazon ECR. Если вы хотите просмотреть образы, вы можете загружать их по отдельности, используя команду docker pull, как в следующих примерах.

Docker Hub:

docker pull opensearchproject/opensearch:3
docker pull opensearchproject/opensearch-dashboards:3

Amazon ECR:

docker pull public.ecr.aws/opensearchproject/opensearch:3
docker pull public.ecr.aws/opensearchproject/opensearch-dashboards:3

Чтобы загрузить конкретную версию OpenSearch или OpenSearch Dashboards, отличную от последней доступной версии, измените тег образа, где он упоминается (либо в командной строке, либо в файле Docker Compose). Например, opensearchproject/opensearch:3.1.0 загрузит версию OpenSearch 3.1.0. Чтобы загрузить последнюю версию, используйте opensearchproject/opensearch:latest. Обратитесь к официальным репозиториям образов для доступных версий.

Перед тем как продолжить, вы должны убедиться, что Docker работает корректно, развернув OpenSearch в одном контейнере.

Запуск OpenSearch в контейнере Docker

1. Выполните следующую команду:

# Эта команда сопоставляет порты 9200 и 9600, устанавливает тип обнаружения на "single-node" и запрашивает самый новый образ OpenSearch
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" opensearchproject/opensearch:latest

Для OpenSearch версии 2.12 или выше установите новый пользовательский пароль администратора перед установкой, используя следующую команду:

docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>" opensearchproject/opensearch:latest

2. Отправьте запрос на порт 9200. Имя пользователя и пароль по умолчанию — admin.

curl https://localhost:9200 -ku admin:<custom-admin-password>

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

{
  "name" : "a937e018cee5",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "GLAjAG6bTeWErFUy_d-CLw",
  "version" : {
    "distribution" : "opensearch",
    "number" : "<version>",
    "build_type" : "<build-type>",
    "build_hash" : "<build-hash>",
    "build_date" : "<build-date>",
    "build_snapshot" : false,
    "lucene_version" : "<lucene-version>",
    "minimum_wire_compatibility_version" : "7.10.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

3. Перед остановкой работающего контейнера отобразите список всех работающих контейнеров и скопируйте идентификатор контейнера для узла OpenSearch, который вы тестируете. В следующем примере идентификатор контейнера — a937e018cee5:

$ docker container ls
CONTAINER ID   IMAGE                                 COMMAND                  CREATED          STATUS          PORTS                                                                NAMES
a937e018cee5   opensearchproject/opensearch:latest   "./opensearch-docker…"   19 minutes ago   Up 19 minutes   0.0.0.0:9200->9200/tcp, 9300/tcp, 0.0.0.0:9600->9600/tcp, 9650/tcp   wonderful_boyd

4. Остановите работающий контейнер, передав идентификатор контейнера в команду docker stop.

docker stop <containerId>

Помните, что команда docker container ls не отображает остановленные контейнеры. Если вы хотите просмотреть остановленные контейнеры, используйте команду docker container ls -a. Вы можете удалить ненужные контейнеры вручную с помощью команды docker container rm <containerId_1> <containerId_2> <containerId_3> [...] (укажите все идентификаторы контейнеров, которые вы хотите остановить, разделенные пробелами), или, если вы хотите удалить все остановленные контейнеры, вы можете использовать более короткую команду docker container prune.

Развертывание кластера OpenSearch с использованием Docker Compose

Хотя технически возможно создать кластер OpenSearch, создавая контейнеры по одной команде за раз, гораздо проще определить вашу среду в YAML-файле и позволить Docker Compose управлять кластером. В следующем разделе содержатся примеры YAML-файлов, которые вы можете использовать для запуска предопределенного кластера с OpenSearch и OpenSearch Dashboards. Эти примеры полезны для тестирования и разработки, но не подходят для производственной среды. Если у вас нет опыта работы с Docker Compose, вам может быть полезно ознакомиться со спецификацией Docker Compose для получения рекомендаций по синтаксису и форматированию перед внесением изменений в структуры словарей в примерах.

Файл YAML, который определяет среду, называется файлом Docker Compose. По умолчанию команды docker-compose сначала проверяют вашу текущую директорию на наличие файла, который соответствует любому из следующих имен:

• docker-compose.yml
• docker-compose.yaml
• compose.yml
• compose.yaml

Если ни один из этих файлов не существует в вашей текущей директории, команда docker-compose завершится с ошибкой.

Вы можете указать пользовательское местоположение и имя файла при вызове docker-compose с помощью флага -f:

# Используйте относительный или абсолютный путь к файлу.
docker compose -f /path/to/your-file.yml up

Если вы впервые запускаете кластер OpenSearch с использованием Docker Compose, используйте следующий пример файла docker-compose.yml. Сохраните его в домашнем каталоге вашего хоста и назовите его docker-compose.yml. Этот файл создает кластер, который содержит три контейнера: два контейнера, работающих с сервисом OpenSearch, и один контейнер, работающий с OpenSearch Dashboards. Эти контейнеры общаются через мостовую сеть под названием opensearch-net и используют два тома, по одному для каждого узла OpenSearch. Поскольку этот файл явно не отключает демонстрационную конфигурацию безопасности, устанавливаются самоподписанные TLS-сертификаты, и создаются внутренние пользователи с именами и паролями по умолчанию.

Установка пользовательского пароля администратора

Начиная с OpenSearch 2.12, для настройки демонстрационной конфигурации безопасности требуется пользовательский пароль администратора. Выполните одно из следующих действий:

1. Перед запуском docker-compose.yml установите новый пользовательский пароль администратора, используя следующую команду:

   export OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>
   

2. Создайте файл .env в той же папке, что и ваш файл docker-compose.yml, с переменной OPENSEARCH_INITIAL_ADMIN_PASSWORD и значением надежного пароля.

Требования к паролям

OpenSearch по умолчанию обеспечивает высокую безопасность паролей, используя библиотеку оценки прочности паролей zxcvbn, разработанную компанией Dropbox.

Эта библиотека оценивает пароли на основе энтропии, а не жестких правил сложности, используя следующие рекомендации:

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

2. Избегайте общих шаблонов и слов из словаря: Библиотека zxcvbn обнаруживает распространенные шаблоны и слова из словаря, что помогает предотвратить использование легко угадываемых паролей.

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

Sample docker-compose.yml

services:
  opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/)
    image: opensearchproject/opensearch:latest # Specifying the latest available image - modify if you want a specific version
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Name the cluster
      - node.name=opensearch-node1 # Name the node that will run in this container
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager
      - bootstrap.memory_lock=true # Disable JVM heap memory swapping
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}    # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later
    ulimits:
      memlock:
        soft: -1 # Set memlock to unlimited (no soft or hard limit)
        hard: -1
      nofile:
        soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Performance Analyzer
    networks:
      - opensearch-net # All of the containers will join the same Docker bridge network
  opensearch-node2:
    image: opensearchproject/opensearch:latest # This should be the same image used for opensearch-node1 to avoid issues
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node2
      - discovery.seed_hosts=opensearch-node1,opensearch-node2
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD}
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
    networks:
      - opensearch-net
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:latest # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Map host port 5601 to container port 5601
    expose:
      - "5601" # Expose port 5601 for web access to OpenSearch Dashboards
    environment:
      OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query
    networks:
      - opensearch-net

volumes:
  opensearch-data1:
  opensearch-data2:

networks:
  opensearch-net:

Если вы переопределяете настройки opensearch_dashboards.yml, используя переменные окружения в вашем файле Compose, используйте все заглавные буквы и заменяйте точки на подчеркивания. Например, для opensearch.hosts используйте OPENSEARCH_HOSTS.

Это поведение отличается от переопределения настроек opensearch.yml, где преобразование заключается только в изменении оператора присваивания. Например, discovery.type: single-node в opensearch.yml определяется как discovery.type=single-node в docker-compose.yml.

Запуск и управление контейнерами OpenSearch с использованием Docker Compose

1. Создайте и запустите контейнеры в фоновом режиме из домашнего каталога вашего хоста (содержащего docker-compose.yml):

   docker compose up -d
   

2. Проверьте, что сервисные контейнеры запустились корректно:

   docker compose ps
   

3. Если контейнер не удалось запустить, вы можете просмотреть логи сервиса:

   # Если вы не укажете имя сервиса, docker compose покажет логи всех узлов
   docker compose logs <serviceName>
   

4. Проверьте доступ к OpenSearch Dashboards, подключившись к http://localhost:5601 из браузера. Для OpenSearch версии 2.12 и выше вы должны использовать ваш настроенный логин и пароль. Для более ранних версий логин и пароль по умолчанию — admin. Мы не рекомендуем использовать эту конфигурацию на хостах, доступных из публичного интернета, пока вы не настроите конфигурацию безопасности вашего развертывания.

   Помните, что localhost не может быть доступен удаленно. Если вы развертываете эти контейнеры на удаленном хосте, вам нужно установить сетевое соединение и заменить localhost на IP-адрес или DNS-запись, соответствующую хосту.

5. Остановите работающие контейнеры в вашем кластере:

   docker compose down
   

Команда docker compose down остановит работающие контейнеры, но не удалит Docker-тома, которые существуют на хосте. Если вам не важны содержимое этих томов, используйте опцию -v, чтобы удалить все тома, например:

docker compose down -v

Настройка OpenSearch

В отличие от RPM-распределения OpenSearch, которое требует значительного объема конфигурации после установки, запуск кластеров OpenSearch с помощью Docker позволяет вам определить среду еще до создания контейнеров. Это возможно как при использовании Docker, так и при использовании Docker Compose.

Пример команды Docker

Рассмотрим следующую команду:

docker run \
  -p 9200:9200 -p 9600:9600 \
  -e "discovery.type=single-node" \
  -v /path/to/custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml \
  opensearchproject/opensearch:latest

Разберем каждую часть команды:

• Сопоставляет порты 9200 и 9600 (HOST_PORT:CONTAINER_PORT).
• Устанавливает discovery.type в single-node, чтобы проверки загрузки не завершились неудачей для этого развертывания с одним узлом.
• Использует флаг -v, чтобы передать локальный файл с именем custom-opensearch.yml в контейнер, заменяя файл opensearch.yml, включенный в образ.
• Запрашивает образ opensearchproject/opensearch:latest из Docker Hub.
• Запускает контейнер.

Если вы сравните эту команду с примером файла docker-compose.yml, вы можете заметить некоторые общие настройки, такие как сопоставление портов и ссылка на образ. Однако эта команда только развертывает один контейнер, работающий с OpenSearch, и не создает контейнер для OpenSearch Dashboards. Более того, если вы хотите использовать пользовательские TLS-сертификаты, пользователей или роли, или определить дополнительные тома и сети, то эта “однострочная” команда быстро становится непрактичной. Вот где полезность Docker Compose становится очевидной.

Использование Docker Compose

Когда вы строите свой кластер OpenSearch с помощью Docker Compose, вам может быть проще передавать пользовательские файлы конфигурации с вашего хоста в контейнер, вместо того чтобы перечислять каждую отдельную настройку в docker-compose.yml. Аналогично тому, как в примере команды docker run был смонтирован том с хоста в контейнер с помощью флага -v, файлы Compose могут указывать тома для монтирования как подопцию для соответствующей службы. Следующий сокращенный YAML-файл демонстрирует, как смонтировать файл или директорию в контейнер:

services:
  opensearch-node1:
    volumes:
      - opensearch-data1:/usr/share/opensearch/data
      - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml
  opensearch-node2:
    volumes:
      - opensearch-data2:/usr/share/opensearch/data
      - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml
  opensearch-dashboards:
    volumes:
      - ./custom-opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml

Обратите внимание, что в этом примере каждый узел OpenSearch использует один и тот же файл конфигурации, что упрощает управление настройками. Для получения более подробной информации о использовании томов и синтаксисе обратитесь к официальной документации Docker по томам.

Пример файла Docker Compose для разработки

Если вы хотите создать свой собственный файл compose на основе примера, ознакомьтесь с следующим образцом файла docker-compose.yml. Этот образец создает два узла OpenSearch и один узел OpenSearch Dashboards с отключенным плагином безопасности. Вы можете использовать этот образец в качестве отправной точки, просматривая Настройка основных параметров безопасности.

services:
  opensearch-node1:
    image: opensearchproject/opensearch:latest
    container_name: opensearch-node1
    environment:
      - cluster.name=opensearch-cluster # Название кластера
      - node.name=opensearch-node1 # Название узла, который будет работать в этом контейнере
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Узлы, которые будут использоваться для обнаружения кластера
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Узлы, которые могут служить менеджерами кластера
      - bootstrap.memory_lock=true # Отключить свопинг памяти кучи JVM
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Установить минимальный и максимальный размеры кучи JVM не менее 50% от системной оперативной памяти
      - "DISABLE_INSTALL_DEMO_CONFIG=true" # Предотвращает выполнение встроенного демо-скрипта, который устанавливает демо-сертификаты и конфигурации безопасности в OpenSearch
      - "DISABLE_SECURITY_PLUGIN=true" # Отключает плагин безопасности
    ulimits:
      memlock:
        soft: -1 # Установить memlock на неограниченное (без мягкого или жесткого ограничения)
        hard: -1
      nofile:
        soft: 65536 # Максимальное количество открытых файлов для пользователя opensearch - установить не менее 65536
        hard: 65536
    volumes:
      - opensearch-data1:/usr/share/opensearch/data # Создает том с именем opensearch-data1 и монтирует его в контейнер
    ports:
      - 9200:9200 # REST API
      - 9600:9600 # Анализатор производительности
    networks:
      - opensearch-net # Все контейнеры будут присоединены к одной и той же сети Docker bridge
  opensearch-node2:
    image: opensearchproject/opensearch:latest
    container_name: opensearch-node2
    environment:
      - cluster.name=opensearch-cluster # Название кластера
      - node.name=opensearch-node2 # Название узла, который будет работать в этом контейнере
      - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Узлы, которые будут использоваться для обнаружения кластера
      - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Узлы, которые могут служить менеджерами кластера
      - bootstrap.memory_lock=true # Отключить свопинг памяти кучи JVM
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Установить минимальный и максимальный размеры кучи JVM не менее 50% от системной оперативной памяти
      - "DISABLE_INSTALL_DEMO_CONFIG=true" # Предотвращает выполнение встроенного демо-скрипта, который устанавливает демо-сертификаты и конфигурации безопасности в OpenSearch
      - "DISABLE_SECURITY_PLUGIN=true" # Отключает плагин безопасности
    ulimits:
      memlock:
        soft: -1 # Установить memlock на неограниченное (без мягкого или жесткого ограничения)
        hard: -1
      nofile:
        soft: 65536 # Максимальное количество открытых файлов для пользователя opensearch - установить не менее 65536
        hard: 65536
    volumes:
      - opensearch-data2:/usr/share/opensearch/data # Создает том с именем opensearch-data2 и монтирует его в контейнер
    networks:
      - opensearch-net # Все контейнеры будут присоединены к одной и той же сети Docker bridge
  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:latest
    container_name: opensearch-dashboards
    ports:
      - 5601:5601 # Привязка порта хоста 5601 к порту контейнера 5601
    expose:
      - "5601" # Открыть порт 5601 для веб-доступа к OpenSearch Dashboards
    environment:
      - 'OPENSEARCH_HOSTS=["http://opensearch-node1:9200","http://opensearch-node2:9200"]' # Указать узлы OpenSearch для Dashboards
      - "DISABLE_SECURITY_DASHBOARDS_PLUGIN=true" # Отключает плагин безопасности в OpenSearch Dashboards
    networks:
      - opensearch-net

volumes:
  opensearch-data1: {} # Создает том opensearch-data1
  opensearch-data2: {} # Создает том opensearch-data2

networks:
  opensearch-net: {} # Создает сеть opensearch-net

Настройка основных параметров безопасности

Перед тем как сделать ваш кластер OpenSearch доступным для внешних хостов, рекомендуется ознакомиться с конфигурацией безопасности развертывания. Вы можете вспомнить из первого примера файла docker-compose.yml, что, если не отключить плагин безопасности, установив DISABLE_SECURITY_PLUGIN=true, встроенный скрипт применит стандартную демо-конфигурацию безопасности к узлам в кластере. Поскольку эта конфигурация используется для демонстрационных целей, стандартные имена пользователей и пароли известны. Поэтому мы рекомендуем создать собственные файлы конфигурации безопасности и использовать тома для передачи этих файлов в контейнеры. Для получения конкретных рекомендаций по настройке безопасности OpenSearch смотрите Конфигурация безопасности.

Чтобы использовать свои собственные сертификаты в конфигурации, добавьте все необходимые сертификаты в раздел томов файла compose:

volumes:
  - ./root-ca.pem:/usr/share/opensearch/config/root-ca.pem
  - ./admin.pem:/usr/share/opensearch/config/admin.pem
  - ./admin-key.pem:/usr/share/opensearch/config/admin-key.pem
  - ./node1.pem:/usr/share/opensearch/config/node1.pem
  - ./node1-key.pem:/usr/share/opensearch/config/node1-key.pem

Когда вы добавляете сертификаты TLS к узлам OpenSearch с помощью томов Docker Compose, вы также должны включить пользовательский файл opensearch.yml, который определяет эти сертификаты. Например:

volumes:
  - ./root-ca.pem:/usr/share/opensearch/config/root-ca.pem
  - ./admin.pem:/usr/share/opensearch/config/admin.pem
  - ./admin-key.pem:/usr/share/opensearch/config/admin-key.pem
  - ./node1.pem:/usr/share/opensearch/config/node1.pem
  - ./node1-key.pem:/usr/share/opensearch/config/node1-key.pem
  - ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml

Помните, что сертификаты, которые вы указываете в файле compose, должны совпадать с сертификатами, определенными в вашем пользовательском файле opensearch.yml. Вам следует заменить корневые, администраторские и узловые сертификаты на свои собственные. Для получения дополнительной информации смотрите Настройка сертификатов TLS.

Пример конфигурации в вашем пользовательском файле opensearch.yml может выглядеть следующим образом, добавляя сертификаты TLS и отличительное имя (DN) сертификата администратора, определяя несколько разрешений и включая подробное аудиторское логирование:

plugins.security.ssl.transport.pemcert_filepath: node1.pem
plugins.security.ssl.transport.pemkey_filepath: node1-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.transport.enforce_hostname_verification: false
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: node1.pem
plugins.security.ssl.http.pemkey_filepath: node1-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem
plugins.security.allow_default_init_securityindex: true
plugins.security.authcz.admin_dn:
  - CN=A,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA
plugins.security.nodes_dn:
  - 'CN=N,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA'
plugins.security.audit.type: internal_opensearch
plugins.security.enable_snapshot_restore_privilege: true
plugins.security.check_snapshot_restore_write_privileges: true
plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
cluster.routing.allocation.disk.threshold_enabled: false
opendistro_security.audit.config.disabled_rest_categories: NONE
opendistro_security.audit.config.disabled_transport_categories: NONE

Полный список настроек

Для получения полного списка настроек смотрите Безопасность.

Используйте тот же процесс для указания конфигурации Backend в файле /usr/share/opensearch/config/opensearch-security/config.yml, а также для создания новых внутренних пользователей, ролей, сопоставлений, групп действий и арендаторов в соответствующих YAML-файлах.

После замены сертификатов и создания собственных внутренних пользователей, ролей, сопоставлений, групп действий и арендаторов, используйте Docker Compose для запуска кластера:

docker compose up -d

Работа с плагинами

Чтобы использовать образ OpenSearch с пользовательским плагином, вам сначала нужно создать Dockerfile. Ознакомьтесь с официальной документацией Docker для получения информации о создании Dockerfile.

FROM opensearchproject/opensearch:latest
RUN /usr/share/opensearch/bin/opensearch-plugin install --batch <pluginId>

Затем выполните следующие команды:

# Создание образа из Dockerfile
docker build --tag=opensearch-custom-plugin .
# Запуск контейнера из пользовательского образа
docker run -p 9200:9200 -p 9600:9600 -v /usr/share/opensearch/data opensearch-custom-plugin

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

FROM opensearchproject/opensearch:latest
RUN /usr/share/opensearch/bin/opensearch-plugin remove opensearch-security

Вы также можете использовать Dockerfile для передачи своих собственных сертификатов для использования с плагином безопасности:

FROM opensearchproject/opensearch:latest
COPY --chown=opensearch:opensearch opensearch.yml /usr/share/opensearch/config/
COPY --chown=opensearch:opensearch my-key-file.pem /usr/share/opensearch/config/
COPY --chown=opensearch:opensearch my-certificate-chain.pem /usr/share/opensearch/config/
COPY --chown=opensearch:opensearch my-root-cas.pem /usr/share/opensearch/config/

1.2 - Установка OpenSearch на Debian

Установка OpenSearch с использованием менеджера пакетов Advanced Packaging Tool (APT) значительно упрощает процесс по сравнению с методом Tarball. Несколько технических аспектов, таких как путь установки, расположение конфигурационных файлов и создание службы, управляемой systemd, обрабатываются автоматически менеджером пакетов.

В общем, установка OpenSearch из дистрибутива Debian может быть разбита на несколько шагов:

1. Скачать и установить OpenSearch.
2. Установить вручную из Debian-пакета или из APT-репозитория.
3. (Необязательно) Протестировать OpenSearch.
   • Подтвердите, что OpenSearch может работать, прежде чем применять какую-либо пользовательскую конфигурацию.
   • Это можно сделать без какой-либо безопасности (без пароля, без сертификатов) или с демо-конфигурацией безопасности, которая может быть применена с помощью упакованного скрипта.
4. Настроить OpenSearch для вашей среды.
   • Примените основные настройки к OpenSearch и начните использовать его в вашей среде.

Дистрибутив Debian предоставляет все необходимое для запуска OpenSearch внутри дистрибутивов Linux на базе Debian, таких как Ubuntu.

Этот гид предполагает, что вы уверенно работаете с интерфейсом командной строки (CLI) Linux. Вы должны понимать, как вводить команды, перемещаться между директориями и редактировать текстовые файлы. Некоторые примеры команд ссылаются на текстовый редактор vi, но вы можете использовать любой доступный текстовый редактор.

Шаг 1: Скачивание и установка OpenSearch

Установка OpenSearch из пакета

Скачайте Debian-пакет для желаемой версии непосредственно с страницы загрузок OpenSearch. Debian-пакет можно скачать как для архитектуры x64, так и для arm64.

Из командной строки установите пакет с помощью dpkg:

Для новых установок OpenSearch 2.12 и более поздних версий необходимо определить пользовательский пароль администратора для настройки демо-конфигурации безопасности. Используйте одну из следующих команд для определения пользовательского пароля администратора:

# x64
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> dpkg -i opensearch-3.1.0-linux-x64.deb

# arm64
sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> dpkg -i opensearch-3.1.0-linux-arm64.deb

Используйте следующую команду для версий OpenSearch 2.11 и более ранних:

# x64
sudo dpkg -i opensearch-3.1.0-linux-x64.deb

# arm64
sudo dpkg -i opensearch-3.1.0-linux-arm64.deb

После успешной установки включите OpenSearch как службу:

sudo systemctl enable opensearch

Запустите службу OpenSearch:

sudo systemctl start opensearch

Проверьте, что OpenSearch запустился корректно:

sudo systemctl status opensearch

Проверка отпечатка

Debian-пакет не подписан. Если вы хотите проверить отпечаток, проект OpenSearch предоставляет файл .sig, а также пакет .deb для использования с GNU Privacy Guard (GPG).

Скачайте желаемый Debian-пакет:

curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch/3.1.0/opensearch-3.1.0-linux-x64.deb

Скачайте соответствующий файл подписи:

curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch/3.1.0/opensearch-3.1.0-linux-x64.deb.sig

Скачайте и импортируйте GPG-ключ:

curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | gpg --import -

Проверьте подпись:

gpg --verify opensearch-3.1.0-linux-x64.deb.sig opensearch-3.1.0-linux-x64.deb

Установка OpenSearch из APT-репозитория

APT, основной инструмент управления пакетами для операционных систем на базе Debian, позволяет загружать и устанавливать Debian-пакет из APT-репозитория.

1. Установите необходимые пакеты:

sudo apt-get update && sudo apt-get -y install lsb-release ca-certificates curl gnupg2

2. Импортируйте публичный GPG-ключ. Этот ключ используется для проверки подписи APT-репозитория:

curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-release-keyring

3. Создайте APT-репозиторий для OpenSearch:

echo "deb [signed-by=/usr/share/keyrings/opensearch-release-keyring] https://artifacts.opensearch.org/releases/bundle/opensearch/3.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-3.x.list

4. Проверьте, что репозиторий был успешно создан:

sudo apt-get update

5. С добавленной информацией о репозитории перечислите все доступные версии OpenSearch:

sudo apt list -a opensearch

6. Выбор версии OpenSearch для установки

• Если не указано иное, будет установлена последняя доступная версия OpenSearch.

# Для новых установок OpenSearch 2.12 и более поздних версий необходимо определить пользовательский пароль администратора для настройки демо-конфигурации безопасности. 
# Используйте одну из следующих команд для определения пользовательского пароля:

sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> apt-get install opensearch

# Для версий OpenSearch 2.11 и более ранних используйте следующую команду:

sudo apt-get install opensearch

• Установка конкретной версии OpenSearch

# Чтобы установить конкретную версию OpenSearch, укажите версию вручную, используя `opensearch=<version>`:

# Для новых установок OpenSearch 2.12 и более поздних версий:

sudo env OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password> apt-get install opensearch=3.1.0

# Для версий OpenSearch 2.11 и более ранних:

sudo apt-get install opensearch=3.1.0

7. Во время установки установщик предоставит вам отпечаток GPG-ключа. Убедитесь, что информация совпадает с указанной ниже:

Fingerprint: c5b7 4989 65ef d1c2 924b a9d5 39d3 1987 9310 d3fc

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

sudo systemctl enable opensearch

9. Запуск OpenSearch

Чтобы запустить OpenSearch, выполните следующую команду:

sudo systemctl start opensearch

10. Проверка статуса OpenSearch

После запуска проверьте, что OpenSearch запустился корректно, с помощью следующей команды:

sudo systemctl status opensearch

Шаг 2: (Необязательно) Тестирование OpenSearch

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

Когда OpenSearch установлен с использованием Debian-пакета, некоторые демо-настройки безопасности автоматически применяются. Это включает в себя самоподписанные TLS-сертификаты и несколько пользователей и ролей. Если вы хотите настроить их самостоятельно, смотрите раздел Настройка OpenSearch в вашей среде.

Узел OpenSearch в своей стандартной конфигурации (с демо-сертификатами и пользователями с стандартными паролями) не подходит для производственной среды. Если вы планируете использовать узел в производственной среде, вам следует, как минимум, заменить демо TLS-сертификаты на ваши собственные и обновить список внутренних пользователей и паролей. Смотрите Конфигурация безопасности для получения дополнительной информации, чтобы убедиться, что ваши узлы настроены в соответствии с вашими требованиями безопасности.

Отправка запросов на сервер

Отправьте запросы на сервер, чтобы проверить, что OpenSearch работает. Обратите внимание на использование флага --insecure, который необходим, поскольку TLS-сертификаты самоподписаны.

Отправьте запрос на порт 9200:

curl -X GET https://localhost:9200 -u 'admin:<custom-admin-password>' --insecure

Ожидаемый ответ

Вы должны получить ответ, который выглядит примерно так:

{
    "name": "hostname",
    "cluster_name": "opensearch",
    "cluster_uuid": "QqgpHCbnSRKcPAizqjvoOw",
    "version": {
        "distribution": "opensearch",
        "number": <version>,
        "build_type": <build-type>,
        "build_hash": <build-hash>,
        "build_date": <build-date>,
        "build_snapshot": false,
        "lucene_version": <lucene-version>,
        "minimum_wire_compatibility_version": "7.10.0",
        "minimum_index_compatibility_version": "7.0.0"
    },
    "tagline": "The OpenSearch Project: https://opensearch.org/"
}

Запрос к конечной точке плагинов

Запросите конечную точку плагинов:

curl -X GET https://localhost:9200/_cat/plugins?v -u 'admin:<custom-admin-password>' --insecure

Этот запрос вернет список установленных плагинов, что также подтвердит, что OpenSearch работает корректно.

Ожидаемый ответ для запроса к конечной точке плагинов

Шаг 3: Настройка OpenSearch в вашей среде

Пользователи, не имеющие предварительного опыта работы с OpenSearch, могут захотеть получить список рекомендуемых настроек для начала работы с сервисом. По умолчанию OpenSearch не привязан к сетевому интерфейсу и не может быть доступен внешними хостами. Кроме того, настройки безопасности заполняются стандартными именами пользователей и паролями. Следующие рекомендации позволят пользователю привязать OpenSearch к сетевому интерфейсу, создать и подписать TLS-сертификаты, а также настроить базовую аутентификацию.

Рекомендуемые настройки

Следующие настройки позволят вам:

• Привязать OpenSearch к IP-адресу или сетевому интерфейсу на хосте.
• Установить начальные и максимальные размеры кучи JVM.
• Определить переменную окружения, указывающую на встроенный JDK.
• Настроить собственные TLS-сертификаты — сторонний центр сертификации (CA) не требуется.
• Создать администратора с пользовательским паролем.

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

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

1. Открытие файла opensearch.yml

Откройте файл opensearch.yml:

sudo vi /etc/opensearch/opensearch.yml

2. Добавление следующих строк

Добавьте следующие строки в файл:

# Привязать OpenSearch к правильному сетевому интерфейсу. Используйте 0.0.0.0
# для включения всех доступных интерфейсов или укажите IP-адрес,
# назначенный конкретному интерфейсу.
network.host: 0.0.0.0

# Если вы еще не настроили кластер, установите
# discovery.type в single-node, иначе проверки загрузки
# не пройдут, когда вы попытаетесь запустить службу.
discovery.type: single-node

# Если вы ранее отключили плагин безопасности в opensearch.yml,
# обязательно включите его снова. В противном случае вы можете пропустить эту настройку.
plugins.security.disabled: false

3. Сохраните изменения и закройте файл

4. Укажите начальные и максимальные размеры кучи JVM

• Откройте файл jvm.options:

vi /etc/opensearch/jvm.options

• Измените значения для начального и максимального размеров кучи. В качестве отправной точки вы должны установить эти значения на половину доступной системной памяти. Для выделенных хостов это значение можно увеличить в зависимости от ваших рабочих требований.

• Например, если у хост-машины 8 ГБ памяти, вы можете установить начальные и максимальные размеры кучи на 4 ГБ:

-Xms4g
-Xmx4g

• Сохраните изменения и закройте файл.

Настройка TLS

Сертификаты TLS обеспечивают дополнительную безопасность для вашего кластера, позволяя клиентам подтверждать личность хостов и шифровать трафик между клиентом и хостом. Для получения дополнительной информации обратитесь к разделам “Настройка сертификатов TLS” и “Генерация сертификатов”, которые включены в документацию по плагину безопасности. Для работы в среде разработки обычно достаточно самоподписанных сертификатов. Этот раздел проведет вас через основные шаги, необходимые для генерации собственных сертификатов TLS и их применения к вашему хосту OpenSearch.

1. Перейдите в директорию, где будут храниться сертификаты

cd /etc/opensearch

2. Удалите демонстрационные сертификаты

sudo rm -f *pem

3. Сгенерируйте корневой сертификат

Это то, что вы будете использовать для подписания других сертификатов.

# Создайте закрытый ключ для корневого сертификата
sudo openssl genrsa -out root-ca-key.pem 2048

# Используйте закрытый ключ для создания самоподписанного корневого сертификата. Обязательно
# замените аргументы, переданные в -subj, чтобы они отражали ваш конкретный хост.
sudo openssl req -new -x509 -sha256 -key root-ca-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=ROOT" -out root-ca.pem -days 730

4. Создайте сертификат администратора

Этот сертификат используется для получения повышенных прав для выполнения административных задач, связанных с плагином безопасности.

# Создайте закрытый ключ для сертификата администратора
sudo openssl genrsa -out admin-key-temp.pem 2048

# Преобразуйте закрытый ключ в PKCS#8
sudo openssl pkcs8 -inform PEM -outform PEM -in admin-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out admin-key.pem

# Создайте запрос на подпись сертификата (CSR). Общим именем (CN) "A" можно пользоваться, так как этот сертификат
# используется для аутентификации повышенного доступа и не привязан к хосту.
sudo openssl req -new -key admin-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=A" -out admin.csr

# Подпишите сертификат администратора с помощью корневого сертификата и закрытого ключа, которые вы создали ранее.
sudo openssl x509 -req -in admin.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -sha256 -out admin.pem -days 730

5. Создайте закрытый ключ для сертификата узла

sudo openssl genrsa -out node1-key-temp.pem 2048

# Преобразуйте закрытый ключ в PKCS#8

sudo openssl pkcs8 -inform PEM -outform PEM -in node1-key-temp.pem -topk8 -nocrypt -v1 PBE-SHA1-3DES -out node1-key.pem

# Создайте CSR и замените аргументы, переданные в -subj, чтобы они отражали ваш конкретный хост

# Обратите внимание, что CN должен соответствовать DNS A записи для хоста — не используйте имя хоста.

sudo openssl req -new -key node1-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=node1.dns.a-record" -out node1.csr

# Создайте файл расширений, который определяет SAN DNS имя для хоста

# Этот файл должен соответствовать DNS A записи хоста.

sudo sh -c 'echo subjectAltName=DNS:node1.dns.a-record > node1.ext'

# Подпишите сертификат узла с помощью корневого сертификата и закрытого ключа, которые вы создали ранее

sudo openssl x509 -req -in node1.csr -CA root-ca.pem -CAkey root-ca-key.pem -CAcreateserial -sha256 -out node1.pem -days 730 -extfile node1.ext

6. Удалите временные файлы, которые больше не нужны

sudo rm -f *temp.pem *csr *ext

7. Убедитесь, что оставшиеся сертификаты принадлежат пользователю opensearch

sudo chown opensearch:opensearch admin-key.pem admin.pem node1-key.pem node1.pem root-ca-key.pem root-ca.pem root-ca.srl

8. Добавьте эти сертификаты в opensearch.yml

Как описано в разделе “Генерация сертификатов”. Продвинутые пользователи также могут выбрать добавление настроек с помощью скрипта.

#! /bin/bash

# Before running this script, make sure to replace the CN in the 
# node's distinguished name with a real DNS A record.

echo "plugins.security.ssl.transport.pemcert_filepath: /etc/opensearch/node1.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.transport.pemkey_filepath: /etc/opensearch/node1-key.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/opensearch/root-ca.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.enabled: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.pemcert_filepath: /etc/opensearch/node1.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.pemkey_filepath: /etc/opensearch/node1-key.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.ssl.http.pemtrustedcas_filepath: /etc/opensearch/root-ca.pem" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.allow_default_init_securityindex: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.authcz.admin_dn:" | sudo tee -a /etc/opensearch/opensearch.yml
echo "  - 'CN=A,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA'" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.nodes_dn:" | sudo tee -a /etc/opensearch/opensearch.yml
echo "  - 'CN=node1.dns.a-record,OU=UNIT,O=ORG,L=TORONTO,ST=ONTARIO,C=CA'" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.audit.type: internal_opensearch" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.enable_snapshot_restore_privilege: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.check_snapshot_restore_write_privileges: true" | sudo tee -a /etc/opensearch/opensearch.yml
echo "plugins.security.restapi.roles_enabled: [\"all_access\", \"security_rest_api_access\"]" | sudo tee -a /etc/opensearch/opensearch.yml

9. (Необязательно) Добавление доверия к самоподписанному корневому сертификату

# Скопируйте корневой сертификат в правильную директорию

sudo cp /etc/opensearch/root-ca.pem /etc/pki/ca-trust/source/anchors/

# Добавьте доверие

sudo update-ca-trust

Настройка пользователя

Пользователи определяются и аутентифицируются OpenSearch различными способами. Один из методов, который не требует дополнительной инфраструктуры на стороне сервера, — это ручная настройка пользователей в файле internal_users.yml. В следующих шагах объясняется, как добавить нового внутреннего пользователя и как заменить пароль по умолчанию для администратора с помощью скрипта.

1. Перейдите в директорию инструментов плагина безопасности

cd /usr/share/opensearch/plugins/opensearch-security/tools

2. Запустите hash.sh для генерации нового пароля

• Этот скрипт завершится с ошибкой, если путь к JDK не был определен.

# Пример вывода, если JDK не найден...
$ ./hash.sh
**************************************************************************
** Этот инструмент будет устаревшим в следующем крупном релизе OpenSearch **
** https://github.com/opensearch-project/security/issues/1755           **
**************************************************************************
which: no java in (/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/user/.local/bin:/home/user/bin)
WARNING: nor OPENSEARCH_JAVA_HOME nor JAVA_HOME is set, will use 
./hash.sh: line 35: java: command not found

• Объявите переменную окружения при вызове скрипта, чтобы избежать проблем

OPENSEARCH_JAVA_HOME=/usr/share/opensearch/jdk ./hash.sh

• Введите желаемый пароль на запросе и запомните хэш, который будет выведен

3. Откройте файл internal_users.yml

sudo vi /etc/opensearch/opensearch-security/internal_users.yml

4. Добавьте нового внутреннего пользователя и замените хэш внутри internal_users.yml на вывод, предоставленный hash.sh на шаге 2

Файл должен выглядеть примерно так:

---
# This is the internal user database
# The hash value is a bcrypt hash and can be generated with plugin/tools/hash.sh

_meta:
   type: "internalusers"
   config_version: 2

# Define your internal users here

admin:
   hash: "$2y$1EXAMPLEQqwS8TUcoEXAMPLEeZ3lEHvkEXAMPLERqjyh1icEXAMPLE."
   reserved: true
   backend_roles:
   - "admin"
   description: "Admin user"

user1:
   hash: "$2y$12$zoHpvTCRjjQr6h0PEaabueCaGam3/LDvT6rZZGDGMusD7oehQjw/O"
   reserved: false
   backend_roles: []
   description: "New internal user"

# Other users 
...

Применение изменений

Теперь, когда сертификаты TLS установлены, а демонстрационные пользователи были удалены или им были назначены новые пароли, последний шаг — применить изменения конфигурации. Этот последний шаг конфигурации требует вызова securityadmin.sh, пока OpenSearch работает на хосте.

Убедитесь, что OpenSearch запущен

OpenSearch должен быть запущен, чтобы securityadmin.sh мог применить изменения. Если вы внесли изменения в opensearch.yml, перезапустите OpenSearch:

sudo systemctl restart opensearch

Откройте отдельную сессию терминала на хосте и перейдите в директорию, содержащую securityadmin.sh

# Перейдите в правильную директорию
cd /usr/share/opensearch/plugins/opensearch-security/tools

Вызовите скрипт

Смотрите раздел “Применение изменений с помощью securityadmin.sh” для определения аргументов, которые вы должны передать.

# Вы можете опустить переменную окружения, если вы объявили ее в вашем $PATH.
OPENSEARCH_JAVA_HOME=/usr/share/opensearch/jdk ./securityadmin.sh -cd /etc/opensearch/opensearch-security/ -cacert /etc/opensearch/root-ca.pem -cert /etc/opensearch/admin.pem -key /etc/opensearch/admin-key.pem -icl -nhnv

Параметры скрипта:

• -cd: указывает директорию конфигурации.
• -cacert: указывает путь к корневому сертификату.
• -cert: указывает путь к сертификату администратора.
• -key: указывает путь к закрытому ключу администратора.
• -icl: включает режим конфигурации.
• -nhnv: отключает проверку хоста и не выводит информацию о версии.

Проверка работы сервиса

OpenSearch теперь работает на вашем хосте с пользовательскими сертификатами TLS и безопасным пользователем для базовой аутентификации. Вы можете проверить внешнюю доступность, отправив API-запрос к вашему узлу OpenSearch с другого хоста.

Во время предыдущего теста вы направляли запросы на localhost. Теперь, когда сертификаты TLS были применены и новые сертификаты ссылаются на фактическую DNS-запись вашего хоста, запросы к localhost не пройдут проверку CN, и сертификат будет считаться недействительным. Вместо этого запросы должны быть отправлены на адрес, который вы указали при генерации сертификата.

Перед отправкой запросов вы должны добавить доверие к корневому сертификату на вашем клиенте. Если вы не добавите доверие, вам нужно будет использовать опцию -k, чтобы cURL игнорировал проверку CN и корневого сертификата.

$ curl https://your.host.address:9200 -u admin:yournewpassword -k
{
   "name":"hostname",
   "cluster_name":"opensearch",
   "cluster_uuid":"QqgpHCbnSRKcPAizqjvoOw",
   "version":{
      "distribution":"opensearch",
      "number":<version>,
      "build_type":<build-type>,
      "build_hash":<build-hash>,
      "build_date":<build-date>,
      "build_snapshot":false,
      "lucene_version":<lucene-version>,
      "minimum_wire_compatibility_version":"7.10.0",
      "minimum_index_compatibility_version":"7.0.0"
   },
   "tagline":"The OpenSearch Project: https://opensearch.org/"
}

Обновление до новой версии

Экземпляры OpenSearch, установленные с помощью dpkg или apt-get, можно легко обновить до более новой версии.

Ручное обновление с помощью DPKG

Скачайте Debian-пакет для желаемой версии обновления непосредственно со страницы загрузок OpenSearch Project.

Перейдите в директорию, содержащую дистрибутив, и выполните следующую команду:

sudo dpkg -i opensearch-3.1.0-linux-x64.deb

Обновление с помощью APT-GET

Чтобы обновить до последней версии OpenSearch с помощью apt-get, выполните:

sudo apt-get upgrade opensearch

Вы также можете обновить до конкретной версии OpenSearch:

sudo apt-get upgrade opensearch=<version>

Автоматическая перезагрузка сервиса после обновления пакета (2.13.0+)

Чтобы автоматически перезапустить OpenSearch после обновления пакета, включите opensearch.service через systemd:

sudo systemctl enable opensearch.service

2 - Установка OpenSearch Dashboards

OpenSearch Dashboards предоставляет полностью интегрированное решение для визуального изучения, обнаружения и запроса ваших данных наблюдаемости. Вы можете установить OpenSearch Dashboards с помощью одного из следующих вариантов:

• Docker
• Tarball
• RPM
• Debian
• Helm
• Windows

Совместимость с браузерами

OpenSearch Dashboards поддерживает следующие веб-браузеры:

• Chrome
• Firefox
• Safari
• Edge (Chromium)

Другие браузеры на основе Chromium также могут работать. Internet Explorer и Microsoft Edge Legacy не поддерживаются.

Совместимость с Node.js

OpenSearch Dashboards требует бинарный файл среды выполнения Node.js для работы. Один из них включен в дистрибутивные пакеты, доступные на странице загрузок OpenSearch.

OpenSearch Dashboards версии 2.8.0 и новее могут использовать версии Node.js 14, 16 и 18. Дистрибутивные пакеты для OpenSearch Dashboards версии 2.10.0 и новее включают Node.js 18 и 14 (для обратной совместимости).

Чтобы использовать бинарный файл среды выполнения Node.js, отличный от включенных в дистрибутивные пакеты, выполните следующие шаги:

1. Скачайте и установите Node.js; совместимые версии: >=14.20.1 <19.

2. Установите путь установки в переменные окружения NODE_HOME или NODE_OSD_HOME.

   • На UNIX, если Node.js установлен в /usr/local/nodejs, а бинарный файл среды выполнения находится по пути /usr/local/nodejs/bin/node:

     export NODE_HOME=/usr/local/nodejs
     

   • Если Node.js установлен с помощью NVM, а бинарный файл среды выполнения находится по пути /Users/user/.nvm/versions/node/v18.19.0/bin/node:

     export NODE_HOME=/Users/user/.nvm/versions/node/v18.19.0
     # или, если NODE_HOME используется для чего-то другого:
     export NODE_OSD_HOME=/Users/user/.nvm/versions/node/v18.19.0
     

   • На Windows, если Node.js установлен в C:\Program Files\nodejs, а бинарный файл среды выполнения находится по пути C:\Program Files\nodejs\node.exe:

     set "NODE_HOME=C:\Program Files\nodejs"
     # или с использованием PowerShell:
     $Env:NODE_HOME = 'C:\Program Files\nodejs'
     

3. Ознакомьтесь с документацией вашей операционной системы, чтобы внести постоянные изменения в переменные окружения.

Скрипт запуска OpenSearch Dashboards, bin/opensearch-dashboards, ищет бинарный файл среды выполнения Node.js, используя NODE_OSD_HOME, затем NODE_HOME, прежде чем использовать бинарные файлы, включенные в дистрибутивные пакеты. Если подходящий бинарный файл среды выполнения Node.js не найден, скрипт запуска попытается найти его в системном PATH, прежде чем завершить работу с ошибкой.

Конфигурация

Чтобы узнать, как настроить TLS для OpenSearch Dashboards, смотрите раздел Настройка TLS.

2.1 - Запуск OpenSearch Dashboards с использованием Docker

1. Выполните команду для загрузки образа OpenSearch Dashboards:

   docker pull opensearchproject/opensearch-dashboards:2
   

2. Создайте файл docker-compose.yml, соответствующий вашей среде. Пример файла, который включает OpenSearch Dashboards, доступен на странице установки OpenSearch Docker.

3. Так же, как и для opensearch.yml, вы можете передать пользовательский файл opensearch_dashboards.yml в контейнер в файле Docker Compose.

4. Запустите команду:

   docker compose up
   

5. Подождите, пока контейнеры запустятся. Затем ознакомьтесь с документацией OpenSearch Dashboards.

6. Когда закончите, выполните команду:

   docker compose down
   

2.2 - Установка OpenSearch Dashboards (Debian)

Установка OpenSearch Dashboards с использованием менеджера пакетов Advanced Packaging Tool (APT) значительно упрощает процесс по сравнению с методом Tarball. Например, менеджер пакетов обрабатывает несколько технических аспектов, таких как путь установки, расположение конфигурационных файлов и создание службы, управляемой systemd.

Перед установкой OpenSearch Dashboards необходимо настроить кластер OpenSearch. Обратитесь к руководству по установке OpenSearch для Debian для получения инструкций.

Данное руководство предполагает, что вы уверенно работаете с интерфейсом командной строки (CLI) Linux. Вы должны понимать, как вводить команды, перемещаться между директориями и редактировать текстовые файлы. Некоторые примеры команд ссылаются на текстовый редактор vi, но вы можете использовать любой доступный текстовый редактор.

Установка OpenSearch Dashboards из пакета

1. Скачайте пакет Debian для нужной версии непосредственно с страницы загрузок OpenSearch. Пакет Debian доступен для архитектур x64 и arm64.

2. Установите пакет с помощью dpkg из командной строки:

   • Для x64:

     sudo dpkg -i opensearch-dashboards-3.1.0-linux-x64.deb
     

   • Для arm64:

     sudo dpkg -i opensearch-dashboards-3.1.0-linux-arm64.deb
     

3. После завершения установки перезагрузите конфигурацию менеджера systemd:

   sudo systemctl daemon-reload
   

4. Включите OpenSearch как службу:

   sudo systemctl enable opensearch-dashboards
   

5. Запустите службу OpenSearch:

   sudo systemctl start opensearch-dashboards
   

6. Проверьте, что OpenSearch запустился корректно:

   sudo systemctl status opensearch-dashboards
   

Проверка подписи

Пакет Debian не подписан. Если вы хотите проверить подпись, проект OpenSearch предоставляет файл .sig, а также .deb пакет для использования с GNU Privacy Guard (GPG).

1. Скачайте нужный пакет Debian:

   curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/3.1.0/opensearch-dashboards-3.1.0-linux-x64.deb
   

2. Скачайте соответствующий файл подписи:

   curl -SLO https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/3.1.0/opensearch-dashboards-3.1.0-linux-x64.deb.sig
   

3. Скачайте и импортируйте GPG-ключ:

   curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | gpg --import -
   

4. Проверьте подпись:

   gpg --verify opensearch-dashboards-3.1.0-linux-x64.deb.sig opensearch-dashboards-3.1.0-linux-x64.deb
   

Установка OpenSearch Dashboards из репозитория APT

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

1. Установите необходимые пакеты:

   sudo apt-get update && sudo apt-get -y install lsb-release ca-certificates curl gnupg2
   

2. Импортируйте публичный GPG-ключ. Этот ключ используется для проверки подписи репозитория APT:

   curl -o- https://artifacts.opensearch.org/publickeys/opensearch-release.pgp | sudo gpg --dearmor --batch --yes -o /usr/share/keyrings/opensearch-release-keyring
   

3. Создайте репозиторий APT для OpenSearch:

   echo "deb [signed-by=/usr/share/keyrings/opensearch-release-keyring] https://artifacts.opensearch.org/releases/bundle/opensearch-dashboards/3.x/apt stable main" | sudo tee /etc/apt/sources.list.d/opensearch-dashboards-3.x.list
   

4. Проверьте, что репозиторий был успешно создан:

   sudo apt-get update
   

5. С добавленной информацией о репозитории, перечислите все доступные версии OpenSearch:

   sudo apt list -a opensearch-dashboards
   

6. Выберите версию OpenSearch, которую хотите установить:

   • Если не указано иное, будет установлена последняя доступная версия OpenSearch:

     sudo apt-get install opensearch-dashboards
     

   • Чтобы установить конкретную версию OpenSearch Dashboards, укажите номер версии после имени пакета:

     # Укажите версию вручную с помощью opensearch=<version>
     sudo apt-get install opensearch-dashboards=3.1.0
     

7. После завершения установки включите OpenSearch:

   sudo systemctl enable opensearch-dashboards
   

8. Запустите OpenSearch:

   sudo systemctl start opensearch-dashboards
   

9. Проверьте, что OpenSearch запустился корректно:

   sudo systemctl status opensearch-dashboards
   

Изучение OpenSearch Dashboards

По умолчанию OpenSearch Dashboards, как и OpenSearch, связывается с localhost при первоначальной установке. В результате OpenSearch Dashboards недоступен с удаленного хоста, если конфигурация не обновлена.

1. Откройте файл opensearch_dashboards.yml:

   sudo vi /etc/opensearch-dashboards/opensearch_dashboards.yml
   

2. Укажите сетевой интерфейс, к которому должен связываться OpenSearch Dashboards:

   # Используйте 0.0.0.0, чтобы связаться с любым доступным интерфейсом.
   server.host: 0.0.0.0
   

3. Сохраните изменения и выйдите из редактора.

4. Перезапустите OpenSearch Dashboards, чтобы применить изменения конфигурации:

   sudo systemctl restart opensearch-dashboards
   

5. В веб-браузере перейдите к OpenSearch Dashboards. Порт по умолчанию — 5601.

6. Войдите с использованием имени пользователя admin и пароля admin. (Для OpenSearch 2.12 и новее пароль должен быть пользовательским паролем администратора.)

7. Посетите раздел “Начало работы с OpenSearch Dashboards”, чтобы узнать больше.

Обновление до новой версии

Экземпляры OpenSearch Dashboards, установленные с помощью dpkg или apt-get, можно легко обновить до новой версии.

Ручное обновление с помощью DPKG

1. Скачайте пакет Debian для желаемой версии обновления непосредственно со страницы загрузок проекта OpenSearch.

2. Перейдите в директорию, содержащую дистрибутив, и выполните следующую команду:

   sudo dpkg -i opensearch-dashboards-3.1.0-linux-x64.deb
   

Обновление с помощью APT-GET

Чтобы обновить до последней версии OpenSearch Dashboards с помощью apt-get, выполните следующую команду:

sudo apt-get upgrade opensearch-dashboards

Вы также можете обновить до конкретной версии OpenSearch Dashboards, указав номер версии:

sudo apt-get upgrade opensearch-dashboards=<version>

Автоматический перезапуск службы после обновления пакета (2.13.0+)

Чтобы автоматически перезапустить OpenSearch Dashboards после обновления пакета, включите службу opensearch-dashboards.service через systemd:

sudo systemctl enable opensearch-dashboards.service

2.3 - Настройка TLS для OpenSearch Dashboards

Пример конфигурации opensearch_dashboards.yml

Следующая конфигурация opensearch_dashboards.yml показывает, как OpenSearch и OpenSearch Dashboards могут работать на одной машине с демонстрационной конфигурацией:

server.host: '0.0.0.0'
server.ssl.enabled: true
server.ssl.certificate: /usr/share/opensearch-dashboards/config/client-cert.pem
server.ssl.key: /usr/share/opensearch-dashboards/config/client-cert-key.pem
opensearch.hosts: ["https://localhost:9200"]
opensearch.ssl.verificationMode: full
opensearch.ssl.certificateAuthorities: [ "/usr/share/opensearch-dashboards/config/root-ca.pem", "/usr/share/opensearch-dashboards/config/intermediate-ca.pem" ]
opensearch.username: "kibanaserver"
opensearch.password: "kibanaserver"
opensearch.requestHeadersAllowlist: [ authorization,securitytenant ]
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
opensearch_security.cookie.secure: true

Если вы используете опцию установки через Docker, вы можете передать пользовательский файл opensearch_dashboards.yml в контейнер. Чтобы узнать больше, посетите страницу установки Docker.

После включения этих настроек и запуска приложения вы можете подключиться к OpenSearch Dashboards по адресу https://localhost:5601. Возможно, вам потребуется подтвердить предупреждение браузера, если ваши сертификаты самоподписанные. Чтобы избежать такого предупреждения (или полной несовместимости с браузером), рекомендуется использовать сертификаты от доверенного центра сертификации (CA).

3 - configuring opensearch

Динамические настройки

Динамические настройки индекса — это настройки, которые вы можете обновлять в любое время. Вы можете настраивать динамические параметры OpenSearch через API настроек кластера. Для получения подробной информации смотрите раздел Обновление настроек кластера с помощью API.

При возможности используйте API настроек кластера; файл opensearch.yml локален для каждого узла, в то время как API применяет настройки ко всем узлам в кластере.

Статические настройки

Некоторые операции являются статическими и требуют изменения конфигурационного файла opensearch.yml и перезапуска кластера. В общем, эти настройки относятся к сетевым параметрам, формированию кластера и локальной файловой системе. Чтобы узнать больше, смотрите раздел Формирование кластера.

Указание настроек в виде переменных окружения

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

Аргументы при запуске

Вы можете указать переменные окружения в качестве аргументов, используя -E при запуске OpenSearch:

./opensearch -Ecluster.name=opensearch-cluster -Enode.name=opensearch-node1 -Ehttp.host=0.0.0.0 -Ediscovery.type=single-node

Непосредственно в среде оболочки

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

export OPENSEARCH_JAVA_OPTS="-Xms2g -Xmx2g"
export OPENSEARCH_PATH_CONF="/etc/opensearch"
./opensearch

Файл службы systemd

При запуске OpenSearch как службы, управляемой systemd, вы можете указать переменные окружения в файле службы, как показано в следующем примере:

# /etc/systemd/system/opensearch.service.d/override.conf
[Service]
Environment="OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g"
Environment="OPENSEARCH_PATH_CONF=/etc/opensearch"

После создания или изменения файла перезагрузите конфигурацию systemd и перезапустите службу с помощью следующих команд:

sudo systemctl daemon-reload
sudo systemctl restart opensearch

Переменные окружения Docker

При запуске OpenSearch в Docker вы можете указать переменные окружения, используя опцию -e с командой docker run, как показано в следующей команде:

docker run -e "OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g" -e "OPENSEARCH_PATH_CONF=/usr/share/opensearch/config" opensearchproject/opensearch:latest

Обновление настроек кластера с помощью API

Первый шаг в изменении настройки — это просмотр текущих настроек, отправив следующий запрос:

GET _cluster/settings?include_defaults=true

Для более краткого резюме нестандартных настроек отправьте следующий запрос:

GET _cluster/settings

В API настроек кластера существуют три категории настроек: постоянные, временные и стандартные. Постоянные настройки сохраняются после перезапуска кластера. После перезапуска OpenSearch очищает временные настройки.

Если вы указываете одну и ту же настройку в нескольких местах, OpenSearch использует следующий порядок приоритета:

1. Временные настройки
2. Постоянные настройки
3. Настройки из opensearch.yml
4. Стандартные настройки

Чтобы изменить настройку, используйте API настроек кластера и укажите новое значение как постоянное или временное. Этот пример показывает форму плоских настроек:

PUT _cluster/settings
{
  "persistent" : {
    "action.auto_create_index" : false
  }
}

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

PUT _cluster/settings
{
  "persistent": {
    "action": {
      "auto_create_index": false
    }
  }
}

Конфигурационный файл

Вы можете найти файл opensearch.yml по следующему пути:

• Для Docker: /usr/share/opensearch/config/opensearch.yml
• Для большинства дистрибутивов Linux: /etc/opensearch/opensearch.yml

Вы можете отредактировать переменную OPENSEARCH_PATH_CONF=/etc/opensearch, чтобы изменить расположение каталога конфигурации. Эта переменная берется из /etc/default/opensearch (для Debian-пакета) и /etc/sysconfig/opensearch (для RPM-пакета).

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

В файле opensearch.yml вы не помечаете настройки как постоянные или временные, и настройки используют плоскую форму:

cluster.name: my-application
action.auto_create_index: true
compatibility.override_main_response_version: true

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

(Необязательно) Конфигурация заголовков CORS

Если вы работаете над клиентским приложением, которое взаимодействует с кластером OpenSearch на другом домене, вы можете настроить заголовки в opensearch.yml, чтобы разрешить разработку локального приложения на той же машине. Используйте механизм Cross Origin Resource Sharing (CORS), чтобы ваше приложение могло делать вызовы к API OpenSearch, работающему локально. Добавьте следующие строки в ваш файл custom-opensearch.yml (обратите внимание, что символ “-” должен быть первым символом в каждой строке):

- http.host: 0.0.0.0
- http.port: 9200
- http.cors.allow-origin: "http://localhost"
- http.cors.enabled: true
- http.cors.allow-headers: X-Requested-With,X-Auth-Token,Content-Type,Content-Length,Authorization
- http.cors.allow-credentials: true

3.1 - Настройки доступности и восстановления

• Снимки
• Ограничение задач менеджера кластера
• Хранение с удаленной поддержкой
• Обратное давление при поиске
• Обратное давление при индексации шардов
• Репликация сегментов
• Репликация между кластерами

Чтобы узнать больше о статических и динамических настройках, см. Настройка OpenSearch.

Настройки снимков

OpenSearch поддерживает следующие настройки снимков:

• snapshot.max_concurrent_operations (Динамическое, целое число): Максимальное количество одновременных операций снимков. По умолчанию 1000.

Настройки снимков, связанные с безопасностью

Для настроек снимков, связанных с безопасностью, см. Настройки безопасности.

Настройки файловой системы

Для получения информации о настройках файловой системы см. Общая файловая система.

Настройки Amazon S3

Для получения информации о настройках репозитория Amazon S3 см. Amazon S3.

Настройки ограничения задач менеджера кластера

Для получения информации о настройках ограничения задач менеджера кластера см. Установка пределов ограничения.

Настройки хранения с удаленной поддержкой

OpenSearch поддерживает следующие настройки хранения с удаленной поддержкой на уровне кластера:

• cluster.remote_store.translog.buffer_interval (Динамическое, единица времени): Значение по умолчанию для интервала буфера транзакционного лога, используемого при выполнении периодических обновлений транзакционного лога. Эта настройка эффективна только в том случае, если настройка индекса index.remote_store.translog.buffer_interval отсутствует.

• remote_store.moving_average_window_size (Динамическое, целое число): Размер окна скользящего среднего, используемый для расчета значений скользящей статистики, доступных через API статистики удаленного хранилища. По умолчанию 20. Минимально допустимое значение - 5.

Для получения дополнительной информации о настройках хранения с удаленной поддержкой см. Хранение с удаленной поддержкой и Настройка хранения с удаленной поддержкой.

Для получения информации о настройках обратного давления сегментов см. Настройки обратного давления сегментов.

Настройки обратного давления при поиске

Обратное давление при поиске - это механизм, используемый для выявления ресурсоемких запросов на поиск и их отмены, когда узел испытывает нагрузку. Для получения дополнительной информации см. Настройки обратного давления при поиске.

Настройки обратного давления при индексации шардов

Обратное давление при индексации шардов - это механизм умного отклонения на уровне шардов, который динамически отклоняет запросы на индексацию, когда ваш кластер испытывает нагрузку. Для получения дополнительной информации см. Настройки обратного давления при индексации шардов.

Настройки репликации сегментов

Для получения информации о настройках репликации сегментов см. Репликация сегментов.

Для получения информации о настройках обратного давления репликации сегментов см. Обратное давление репликации сегментов.

Настройки репликации между кластерами

Для получения информации о настройках репликации между кластерами см. Настройки репликации.

3.2 - Конфигурация и системные настройки

Для получения обзора создания кластера OpenSearch и примеров настроек конфигурации см. раздел Создание кластера. Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

OpenSearch поддерживает следующие системные настройки:

• cluster.name (Статическая, строка): Имя кластера.

• node.name (Статическая, строка): Описательное имя для узла.

• node.roles (Статическая, список): Определяет одну или несколько ролей для узла OpenSearch. Допустимые значения: cluster_manager, data, ingest, search, ml, remote_cluster_client и coordinating_only.

• path.data (Статическая, строка): Путь к директории, где хранятся ваши данные. Разделяйте несколько местоположений запятыми.

• path.logs (Статическая, строка): Путь к файлам журналов.

• bootstrap.memory_lock (Статическая, логическое): Блокирует память при запуске. Рекомендуется установить размер кучи примерно на половину доступной памяти в системе и убедиться, что владелец процесса имеет право использовать этот лимит. OpenSearch работает неэффективно, когда система использует свопинг памяти.

3.3 - Сетевые настройки

Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

OpenSearch поддерживает следующие общие сетевые настройки:

• network.host (Статическая, список): Привязывает узел OpenSearch к адресу. Используйте 0.0.0.0, чтобы включить все доступные сетевые интерфейсы, или укажите IP-адрес, назначенный конкретному интерфейсу. Настройка network.host является комбинацией network.bind_host и network.publish_host, если они имеют одинаковое значение. Альтернативой network.host является отдельная настройка network.bind_host и network.publish_host по мере необходимости. См. раздел Расширенные сетевые настройки.

• http.port (Статическая, одно значение или диапазон): Привязывает узел OpenSearch к пользовательскому порту или диапазону портов для HTTP-связи. Вы можете указать адрес или диапазон адресов. По умолчанию — 9200-9300.

• transport.port (Статическая, одно значение или диапазон): Привязывает узел OpenSearch к пользовательскому порту для связи между узлами. Вы можете указать адрес или диапазон адресов. По умолчанию — 9300-9400.

Расширенные сетевые настройки

OpenSearch поддерживает следующие расширенные сетевые настройки:

• network.bind_host (Статическая, список): Привязывает узел OpenSearch к адресу или адресам для входящих соединений. По умолчанию — значение из network.host.

• network.publish_host (Статическая, список): Указывает адрес или адреса, которые узел OpenSearch публикует для других узлов в кластере, чтобы они могли подключиться к нему.

Расширенные HTTP-настройки

OpenSearch поддерживает следующие расширенные сетевые настройки для HTTP-связи:

• http.host (Статическая, список): Устанавливает адрес узла OpenSearch для HTTP-связи. Настройка http.host является комбинацией http.bind_host и http.publish_host, если они имеют одинаковое значение. Альтернативой http.host является отдельная настройка http.bind_host и http.publish_host по мере необходимости.

• http.bind_host (Статическая, список): Указывает адрес или адреса, к которым узел OpenSearch привязывается для прослушивания входящих HTTP-соединений.

• http.publish_host (Статическая, список): Указывает адрес или адреса, которые узел OpenSearch публикует для других узлов для HTTP-связи.

• http.compression (Статическая, логическое): Включает поддержку сжатия с использованием Accept-Encoding, когда это применимо. Когда включен HTTPS, по умолчанию — false, в противном случае — true. Отключение сжатия для HTTPS помогает снизить потенциальные риски безопасности, такие как атаки BREACH. Чтобы включить сжатие для HTTPS-трафика, явно установите http.compression в true.

• http.max_header_size (Статическая, строка): Максимальный общий размер всех HTTP-заголовков, разрешенный в запросе. По умолчанию — 16KB.

Расширенные транспортные настройки

OpenSearch поддерживает следующие расширенные сетевые настройки для транспортной связи:

• transport.host (Статическая, список): Устанавливает адрес узла OpenSearch для транспортной связи. Настройка transport.host является комбинацией transport.bind_host и transport.publish_host, если они имеют одинаковое значение. Альтернативой transport.host является отдельная настройка transport.bind_host и transport.publish_host по мере необходимости.

• transport.bind_host (Статическая, список): Указывает адрес или адреса, к которым узел OpenSearch привязывается для прослушивания входящих транспортных соединений.

• transport.publish_host (Статическая, список): Указывает адрес или адреса, которые узел OpenSearch публикует для других узлов для транспортной связи.OpenSearch использует настройки HTTP для конфигурации связи с внешними клиентами через REST API и транспортные настройки для внутренней связи между узлами в OpenSearch.

Выбор транспорта

По умолчанию OpenSearch использует транспорт, предоставляемый модулем transport-netty4, который использует движок Netty 4 как для внутренней TCP-связи между узлами в кластере, так и для внешней HTTP-связи с клиентами. Эта связь полностью асинхронна и неблокирующая. В следующей таблице перечислены другие доступные плагины транспорта, которые могут использоваться взаимозаменяемо.

Установка

./bin/opensearch-plugin install transport-reactor-netty4

Конфигурация (с использованием opensearch.yml)

http.type: reactor-netty4
http.type: reactor-netty4-secure

3.4 - Настройки обнаружения и шлюза

Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

Настройки обнаружения

Процесс обнаружения используется при формировании кластера. Он включает в себя обнаружение узлов и выбор узла-менеджера кластера. OpenSearch поддерживает следующие настройки обнаружения:

• discovery.seed_hosts (Статическая, список): Список хостов, которые выполняют обнаружение при запуске узла. По умолчанию список хостов: ["127.0.0.1", "[::1]"].

• discovery.seed_providers (Статическая, список): Указывает типы провайдеров начальных хостов, которые будут использоваться для получения адресов начальных узлов с целью запуска процесса обнаружения.

• discovery.type (Статическая, строка): По умолчанию OpenSearch формирует кластер с несколькими узлами. Установите discovery.type в single-node, чтобы сформировать кластер с одним узлом.

• cluster.initial_cluster_manager_nodes (Статическая, список): Список узлов, имеющих право быть узлами-менеджерами кластера, используемых для начальной загрузки кластера.

Настройки шлюза

Локальный шлюз хранит состояние кластера и данные шардов, которые используются при перезапуске кластера. OpenSearch поддерживает следующие настройки локального шлюза:

• gateway.recover_after_nodes (Статическая, целое число): После полного перезапуска кластера количество узлов, которые должны присоединиться к кластеру, прежде чем может начаться восстановление.

• gateway.recover_after_data_nodes (Статическая, целое число): После полного перезапуска кластера количество узлов данных, которые должны присоединиться к кластеру, прежде чем может начаться восстановление.

• gateway.expected_data_nodes (Статическая, целое число): Ожидаемое количество узлов данных, которые должны существовать в кластере. После того как ожидаемое количество узлов присоединится к кластеру, может начаться восстановление локальных шардов.

• gateway.recover_after_time (Статическая, значение времени): Количество времени, которое нужно подождать перед началом восстановления, если количество узлов данных меньше ожидаемого количества узлов данных.

3.5 - Настройки безопасности

Для полного списка файлов конфигурации плагина безопасности см. раздел Изменение файлов YAML.

Следующие разделы описывают настройки, связанные с безопасностью, в файле opensearch.yml. Вы можете найти opensearch.yml в <OPENSEARCH_HOME>/config/opensearch.yml. Чтобы узнать больше о статических и динамических настройках, см. раздел Настройка OpenSearch.

Общие настройки

Плагин безопасности поддерживает следующие общие настройки:

• plugins.security.nodes_dn (Статическая): Указывает список отличительных имен (DN), обозначающих другие узлы в кластере. Эта настройка поддерживает подстановочные знаки и регулярные выражения. Список DN также считывается из индекса безопасности, помимо конфигурации YAML, когда plugins.security.nodes_dn_dynamic_config_enabled установлено в true. Если эта настройка не настроена правильно, кластер не сможет сформироваться, так как узлы не смогут доверять друг другу, что приведет к следующей ошибке: “Аутентификация транспортного клиента больше не поддерживается”.

• plugins.security.nodes_dn_dynamic_config_enabled (Статическая): Актуально для сценариев использования кросс-кластера, где необходимо управлять разрешенными узлами DN без необходимости перезапускать узлы каждый раз, когда настраивается новый удаленный кросс-кластер. Установка nodes_dn_dynamic_config_enabled в true включает доступные для супер-администратора API для отличительных имен, которые предоставляют средства для динамического обновления или получения узлов DN. Эта настройка имеет эффект только если plugins.security.cert.intercluster_request_evaluator_class не установлено. По умолчанию — false.

• plugins.security.authcz.admin_dn (Статическая): Определяет DN сертификатов, к которым должны быть назначены административные привилегии. Обязательно.

• plugins.security.roles_mapping_resolution (Статическая): Определяет, как бэкенд-ролям сопоставляются роли безопасности. Поддерживаются следующие значения:

  • MAPPING_ONLY (По умолчанию): Сопоставления должны быть явно настроены в roles_mapping.yml.
  • BACKENDROLES_ONLY: Бэкенд-роли сопоставляются с ролями безопасности напрямую. Настройки в roles_mapping.yml не имеют эффекта.
  • BOTH: Бэкенд-роли сопоставляются с ролями безопасности как напрямую, так и через roles_mapping.yml.

• plugins.security.dls.mode (Статическая): Устанавливает режим оценки безопасности на уровне документа (DLS). По умолчанию — адаптивный. См. раздел Как установить режим оценки DLS.

• plugins.security.compliance.salt (Статическая): Соль, используемая при генерации хеш-значения для маскирования полей. Должна содержать не менее 32 символов. Разрешены только ASCII-символы. Необязательно.

• plugins.security.compliance.immutable_indices (Статическая): Документы в индексах, помеченных как неизменяемые, следуют парадигме “запись один раз, чтение много раз”. Документы, созданные в этих индексах, не могут быть изменены и, следовательно, являются неизменяемыми.

• config.dynamic.http.anonymous_auth_enabled (Статическая): Включает анонимную аутентификацию. Это приведет к тому, что все HTTP-аутентификаторы не будут вызывать запросы на аутентификацию. По умолчанию — false.

• http.detailed_errors.enabled (Статическая): Включает подробное сообщение об ошибке для REST-вызовов, выполненных против кластера OpenSearch. Если установлено в true, предоставляет root_cause вместе с кодом ошибки. По умолчанию — true.

Настройки API управления REST

Плагин безопасности поддерживает следующие настройки API управления REST:

• plugins.security.restapi.roles_enabled (Статическая): Включает доступ к API управления REST на основе ролей для указанных ролей. Роли разделяются запятой. По умолчанию — пустой список (ни одна роль не имеет доступа к API управления REST). См. раздел Контроль доступа для API.

• plugins.security.restapi.endpoints_disabled.. (Статическая): Отключает конкретные конечные точки и их HTTP-методы для ролей. Значения для этой настройки составляют массив HTTP-методов. Например: plugins.security.restapi.endpoints_disabled.all_access.ACTIONGROUPS: ["PUT","POST","DELETE"]. По умолчанию все конечные точки и методы разрешены. Существующие конечные точки включают ACTIONGROUPS, CACHE, CONFIG, ROLES, ROLESMAPPING, INTERNALUSERS, SYSTEMINFO, PERMISSIONSINFO и LICENSE. См. раздел Контроль доступа для API.

• plugins.security.restapi.password_validation_regex (Статическая): Указывает регулярное выражение для задания критериев для пароля при входе. Для получения дополнительной информации см. раздел Настройки пароля.

• plugins.security.restapi.password_validation_error_message (Статическая): Указывает сообщение об ошибке, которое отображается, когда пароль не проходит проверку. Эта настройка используется вместе с plugins.security.restapi.password_validation_regex.

• plugins.security.restapi.password_min_length (Статическая): Устанавливает минимальное количество символов для длины пароля при использовании оценщика силы пароля на основе баллов. По умолчанию — 8. Это также является минимальным значением. Для получения дополнительной информации см. раздел Настройки пароля.

• plugins.security.restapi.password_score_based_validation_strength (Статическая): Устанавливает порог для определения, является ли пароль сильным или слабым. Допустимые значения: fair, good, strong и very_strong. Эта настройка используется вместе с plugins.security.restapi.password_min_length.

• plugins.security.unsupported.restapi.allow_securityconfig_modification (Статическая): Включает использование методов PUT и PATCH для API конфигурации.

Расширенные настройки

Плагин безопасности поддерживает следующие расширенные настройки:

• plugins.security.authcz.impersonation_dn (Статическая): Включает подмену на уровне транспортного слоя. Это позволяет DN выдавать себя за других пользователей. См. раздел Подмена пользователей.

• plugins.security.authcz.rest_impersonation_user (Статическая): Включает подмену на уровне REST. Это позволяет пользователям выдавать себя за других пользователей. См. раздел Подмена пользователей.

• plugins.security.allow_default_init_securityindex (Статическая): При установке в true OpenSearch Security автоматически инициализирует индекс конфигурации с файлами из директории /config, если индекс не существует.

  Это будет использовать известные стандартные пароли. Используйте только в частной сети/окружении.

• plugins.security.allow_unsafe_democertificates (Статическая): При установке в true OpenSearch запускается с демонстрационными сертификатами. Эти сертификаты выданы только для демонстрационных целей.

  Эти сертификаты хорошо известны и, следовательно, небезопасны для использования в производственной среде. Используйте только в частной сети/окружении.

• plugins.security.system_indices.permission.enabled (Статическая): Включает функцию разрешений для системных индексов. При установке в true функция включена, и пользователи с разрешением на изменение ролей могут создавать роли, которые включают разрешения, предоставляющие доступ к системным индексам. При установке в false разрешение отключено, и только администраторы с административным сертификатом могут вносить изменения в системные индексы. По умолчанию разрешение установлено в false в новом кластере.

Настройки уровня эксперта

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

Плагин безопасности поддерживает следующие настройки уровня эксперта:

• plugins.security.config_index_name (Статическая): Имя индекса, в котором .opendistro_security хранит свою конфигурацию.

• plugins.security.cert.oid (Статическая): Определяет идентификатор объекта (OID) сертификатов узлов сервера.

• plugins.security.cert.intercluster_request_evaluator_class (Статическая): Указывает реализацию org.opensearch.security.transport.InterClusterRequestEvaluator, которая используется для оценки межкластерных запросов. Экземпляры org.opensearch.security.transport.InterClusterRequestEvaluator должны реализовывать конструктор с одним аргументом, принимающим объект org.opensearch.common.settings.Settings.

• plugins.security.enable_snapshot_restore_privilege (Статическая): При установке в false эта настройка отключает восстановление снимков для обычных пользователей. В этом случае принимаются только запросы на восстановление снимков, подписанные административным TLS-сертификатом. При установке в true (по умолчанию) обычные пользователи могут восстанавливать снимки, если у них есть привилегии cluster:admin/snapshot/restore, indices:admin/create и indices:data/write/index.

  Снимок можно восстановить только в том случае, если он не содержит глобального состояния и не восстанавливает индекс .opendistro_security.

• plugins.security.check_snapshot_restore_write_privileges (Статическая): При установке в false дополнительные проверки индекса пропускаются. При установке по умолчанию в true попытки восстановить снимки оцениваются на наличие привилегий indices:admin/create и indices:data/write/index.

• plugins.security.cache.ttl_minutes (Статическая): Определяет, как долго кэш аутентификации будет действителен. Кэш аутентификации помогает ускорить аутентификацию, временно храня объекты пользователей, возвращаемые из бэкенда, чтобы плагин безопасности не требовал повторных запросов к ним. Установите значение в минутах. По умолчанию — 60. Отключите кэширование, установив значение в 0.

• plugins.security.disabled (Статическая): Отключает OpenSearch Security.

  Отключение этого плагина может подвергнуть вашу конфигурацию (включая пароли) публичному доступу.

• plugins.security.protected_indices.enabled (Статическая): Если установлено в true, включает защищенные индексы. Защищенные индексы более безопасны, чем обычные индексы. Эти индексы требуют роли для доступа, как и любой другой традиционный индекс, и требуют дополнительной роли для видимости. Эта настройка используется вместе с настройками plugins.security.protected_indices.roles и plugins.security.protected_indices.indices.

• plugins.security.protected_indices.roles (Статическая): Указывает список ролей, к которым пользователь должен быть сопоставлен для доступа к защищенным индексам.

• plugins.security.protected_indices.indices (Статическая): Указывает список индексов, которые следует пометить как защищенные. Эти индексы будут видны только пользователям, сопоставленным с ролями, указанными в plugins.security.protected_indices.roles. После выполнения этого требования пользователю все равно потребуется быть сопоставленным с традиционной ролью, используемой для предоставления разрешения на доступ к индексу.

• plugins.security.system_indices.enabled (Статическая): Если установлено в true, включает системные индексы. Системные индексы аналогичны индексу безопасности, за исключением того, что их содержимое не зашифровано. Индексы, настроенные как системные индексы, могут быть доступны либо супер-администратором, либо пользователем с ролью, включающей разрешение на системный индекс. Для получения дополнительной информации о системных индексах см. раздел Системные индексы.

• plugins.security.system_indices.indices (Статическая): Список индексов, которые будут использоваться как системные индексы. Эта настройка контролируется настройкой plugins.security.system_indices.enabled.

• plugins.security.allow_default_init_securityindex (Статическая): При установке в true устанавливает плагин безопасности в его стандартные настройки безопасности, если попытка создать индекс безопасности завершается неудачей при запуске OpenSearch. Стандартные настройки безопасности хранятся в YAML-файлах, находящихся в директории opensearch-project/security/config. По умолчанию — false.

• plugins.security.cert.intercluster_request_evaluator_class (Статическая): Класс, который будет использоваться для оценки межкластерной связи.

• plugins.security.enable_snapshot_restore_privilege (Статическая): Включает предоставление привилегии восстановления снимков. Необязательно. По умолчанию — true.

• plugins.security.check_snapshot_restore_write_privileges (Статическая): Обеспечивает оценку привилегий записи при создании снимков. По умолчанию — true.

Если вы измените любое из следующих свойств хеширования паролей, вам необходимо повторно хешировать все внутренние пароли для обеспечения совместимости и безопасности.

• plugins.security.password.hashing.algorithm (Статическая): Указывает алгоритм хеширования паролей, который следует использовать. Поддерживаются следующие значения:

  • BCrypt (По умолчанию)
  • PBKDF2
  • Argon2

• plugins.security.password.hashing.bcrypt.rounds (Статическая): Указывает количество раундов, используемых для хеширования паролей с помощью BCrypt. Допустимые значения находятся в диапазоне от 4 до 31, включая. По умолчанию — 12.

• plugins.security.password.hashing.bcrypt.minor (Статическая): Указывает минорную версию алгоритма BCrypt, используемую для хеширования паролей. Поддерживаются следующие значения:

  • A
  • B
  • Y (По умолчанию)

• plugins.security.password.hashing.pbkdf2.function (Статическая): Указывает псевдослучайную функцию, применяемую к паролю. Поддерживаются следующие значения:

  • SHA1
  • SHA224
  • SHA256 (По умолчанию)
  • SHA384
  • SHA512

• plugins.security.password.hashing.pbkdf2.iterations (Статическая): Указывает количество раз, которое псевдослучайная функция применяется к паролю. По умолчанию — 600,000.

• plugins.security.password.hashing.pbkdf2.length (Статическая): Указывает желаемую длину окончательного производного ключа. По умолчанию — 256.

• plugins.security.password.hashing.argon2.iterations (Статическая): Указывает количество проходов по памяти, которые выполняет алгоритм. Увеличение этого значения увеличивает время вычислений на ЦП и улучшает устойчивость к атакам грубой силы. По умолчанию — 3.

• plugins.security.password.hashing.argon2.memory (Статическая): Указывает количество памяти (в кибибайтах), используемой во время хеширования. По умолчанию — 65536 (64 МиБ).

• plugins.security.password.hashing.argon2.parallelism (Статическая): Указывает количество параллельных потоков, используемых для вычислений. По умолчанию — 1.

• plugins.security.password.hashing.argon2.length (Статическая): Указывает длину (в байтах) результирующего хеш-выхода. По умолчанию — 32.

• plugins.security.password.hashing.argon2.type (Статическая): Указывает, какой вариант Argon2 использовать. Поддерживаются следующие значения:

  • Argon2i
  • Argon2d
  • Argon2id (по умолчанию)

• plugins.security.password.hashing.argon2.version (Статическая): Указывает, какую версию Argon2 использовать. Поддерживаются следующие значения:

  • 16
  • 19 (по умолчанию)

Настройки журнала аудита

Плагин безопасности поддерживает следующие настройки журнала аудита:

• plugins.security.audit.enable_rest (Динамическая): Включает или отключает ведение журнала REST-запросов. По умолчанию установлено в true (включено).

• plugins.security.audit.enable_transport (Динамическая): Включает или отключает ведение журнала запросов на уровне транспорта. По умолчанию установлено в false (выключено).

• plugins.security.audit.resolve_bulk_requests (Динамическая): Включает или отключает ведение журнала пакетных запросов. При включении все подзапросы в пакетных запросах также записываются в журнал. По умолчанию установлено в false (выключено).

• plugins.security.audit.config.disabled_categories (Динамическая): Отключает указанные категории событий.

• plugins.security.audit.ignore_requests (Динамическая): Исключает указанные запросы из ведения журнала. Поддерживает подстановочные знаки и регулярные выражения, содержащие действия или пути REST-запросов.

• plugins.security.audit.threadpool.size (Статическая): Определяет количество потоков в пуле потоков, используемом для ведения журнала событий. По умолчанию установлено в 10. Установка этого значения в 0 отключает пул потоков, что означает, что плагин ведет журнал событий синхронно.

• plugins.security.audit.threadpool.max_queue_len (Статическая): Устанавливает максимальную длину очереди на поток. По умолчанию установлено в 100000.

• plugins.security.audit.ignore_users (Динамическая): Массив пользователей. Запросы аудита от пользователей в списке не будут записываться в журнал.

• plugins.security.audit.type (Статическая): Назначение событий журнала аудита. Допустимые значения: internal_opensearch, external_opensearch, debug и webhook.

• plugins.security.audit.config.http_endpoints (Статическая): Список конечных точек для localhost.

• plugins.security.audit.config.index (Статическая): Индекс журнала аудита. По умолчанию установлен auditlog6. Индекс может быть статическим или индексом, который включает дату, чтобы он вращался ежедневно, например, “‘auditlog6-‘YYYY.MM.dd”. В любом случае убедитесь, что индекс защищен должным образом.

• plugins.security.audit.config.type (Статическая): Укажите тип журнала аудита как auditlog.

• plugins.security.audit.config.username (Статическая): Имя пользователя для конфигурации журнала аудита.

• plugins.security.audit.config.password (Статическая): Пароль для конфигурации журнала аудита.

• plugins.security.audit.config.enable_ssl (Статическая): Включает или отключает SSL для ведения журнала аудита.

• plugins.security.audit.config.verify_hostnames (Статическая): Включает или отключает проверку имени хоста для SSL/TLS сертификатов. По умолчанию установлено в true (включено).

• plugins.security.audit.config.enable_ssl_client_auth (Статическая): Включает или отключает аутентификацию клиента SSL/TLS. По умолчанию установлено в false (выключено).

• plugins.security.audit.config.cert_alias (Статическая): Псевдоним для сертификата, используемого для доступа к журналу аудита.

• plugins.security.audit.config.pemkey_filepath (Статическая): Относительный путь к файлу ключа Privacy Enhanced Mail (PEM), используемого для ведения журнала аудита.

• plugins.security.audit.config.pemkey_content (Статическая): Содержимое PEM-ключа, закодированное в base64, используемого для ведения журнала аудита. Это альтернатива …config.pemkey_filepath.

• plugins.security.audit.config.pemkey_password (Статическая): Пароль для частного ключа в формате PEM, используемого клиентом.

• plugins.security.audit.config.pemcert_filepath (Статическая): Относительный путь к файлу PEM-сертификата, используемого для ведения журнала аудита.

• plugins.security.audit.config.pemcert_content (Статическая): Содержимое PEM-сертификата, закодированное в base64, используемого для ведения журнала аудита. Это альтернатива указанию пути к файлу с помощью …config.pemcert_filepath.

• plugins.security.audit.config.pemtrustedcas_filepath (Статическая): Относительный путь к файлу доверенного корневого центра сертификации.

• plugins.security.audit.config.pemtrustedcas_content (Статическая): Содержимое корневого центра сертификации, закодированное в base64. Это альтернатива …config.pemtrustedcas_filepath.

• plugins.security.audit.config.webhook.url (Статическая): URL вебхука.

• plugins.security.audit.config.webhook.format (Статическая): Формат, используемый для вебхука. Допустимые значения: URL_PARAMETER_GET, URL_PARAMETER_POST, TEXT, JSON и SLACK.

• plugins.security.audit.config.webhook.ssl.verify (Статическая): Включает или отключает проверку любых SSL/TLS сертификатов, отправленных с любым запросом вебхука. По умолчанию установлено в true (включено).

• plugins.security.audit.config.webhook.ssl.pemtrustedcas_filepath (Статическая): Относительный путь к файлу доверенного центра сертификации, против которого проверяются запросы вебхука.

• plugins.security.audit.config.webhook.ssl.pemtrustedcas_content (Статическая): Содержимое центра сертификации, используемого для проверки запросов вебхука, закодированное в base64. Это альтернатива …config.pemtrustedcas_filepath.

• plugins.security.audit.config.log4j.logger_name (Статическая): Пользовательское имя для логгера Log4j.

• plugins.security.audit.config.log4j.level (Статическая): Устанавливает уровень журнала по умолчанию для логгера Log4j. Допустимые значения: OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE и ALL. По умолчанию установлено в INFO.

• opendistro_security.audit.config.disabled_rest_categories (Динамическая): Список категорий REST, которые будут игнорироваться логгером. Допустимые значения: AUTHENTICATED и GRANTED_PRIVILEGES.

• opendistro_security.audit.config.disabled_transport_categories (Динамическая): Список категорий на транспортном уровне, которые будут игнорироваться логгером. Допустимые значения: AUTHENTICATED и GRANTED_PRIVILEGES.

Настройки проверки имени хоста и DNS

Плагин безопасности поддерживает следующие настройки проверки имени хоста и DNS:

• plugins.security.ssl.transport.enforce_hostname_verification (Статическая): Указывает, следует ли проверять имена хостов на транспортном уровне. Необязательно. По умолчанию установлено в true.

• plugins.security.ssl.transport.resolve_hostname (Статическая): Указывает, следует ли разрешать имена хостов через DNS на транспортном уровне. Необязательно. По умолчанию установлено в true. Работает только если включена проверка имени хоста.

Для получения дополнительной информации см. раздел Проверка имени хоста и разрешение DNS.

Настройки аутентификации клиента

Плагин безопасности поддерживает следующую настройку аутентификации клиента:

• plugins.security.ssl.http.clientauth_mode (Статическая): Режим аутентификации клиента TLS, который следует использовать. Допустимые значения: OPTIONAL (по умолчанию), REQUIRE и NONE. Необязательно.

Для получения дополнительной информации см. раздел Аутентификация клиента.

Настройки включенных шифров и протоколов

Плагин безопасности поддерживает следующие настройки включенных шифров и протоколов. Каждая настройка должна быть выражена в массиве:

• plugins.security.ssl.http.enabled_ciphers (Статическая): Включенные шифры TLS для REST-уровня. Поддерживается только формат Java.

• plugins.security.ssl.http.enabled_protocols (Статическая): Включенные протоколы TLS для REST-уровня. Поддерживается только формат Java.

• plugins.security.ssl.transport.enabled_ciphers (Статическая): Включенные шифры TLS для транспортного уровня. Поддерживается только формат Java.

• plugins.security.ssl.transport.enabled_protocols (Статическая): Включенные протоколы TLS для транспортного уровня. Поддерживается только формат Java.

Для получения дополнительной информации см. раздел Включенные шифры и протоколы.

Файлы хранилища ключей и доверенных сертификатов — настройки TLS на транспортном уровне

Плагин безопасности поддерживает следующие настройки хранилища ключей и доверенных сертификатов для транспортного уровня TLS:

• plugins.security.ssl.transport.keystore_type (Статическая): Тип файла хранилища ключей. Необязательно. Допустимые значения: JKS или PKCS12/PFX. По умолчанию установлено в JKS.

• plugins.security.ssl.transport.keystore_filepath (Статическая): Путь к файлу хранилища ключей, который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.transport.keystore_alias (Статическая): Имя псевдонима хранилища ключей. Необязательно. По умолчанию используется первый псевдоним.

• plugins.security.ssl.transport.keystore_password (Статическая): Пароль для хранилища ключей. По умолчанию установлено в changeit.

• plugins.security.ssl.transport.truststore_type (Статическая): Тип файла доверенного хранилища. Необязательно. Допустимые значения: JKS или PKCS12/PFX. По умолчанию установлено в JKS.

• plugins.security.ssl.transport.truststore_filepath (Статическая): Путь к файлу доверенного хранилища, который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.transport.truststore_alias (Статическая): Имя псевдонима доверенного хранилища. Необязательно. По умолчанию используются все сертификаты.

• plugins.security.ssl.transport.truststore_password (Статическая): Пароль для доверенного хранилища. По умолчанию установлено в changeit.

Для получения дополнительной информации о файлах хранилища ключей и доверенных сертификатов см. раздел TLS на транспортном уровне.

Файлы хранилища ключей и доверенных сертификатов — настройки TLS на уровне REST

Плагин безопасности поддерживает следующие настройки хранилища ключей и доверенных сертификатов для уровня REST TLS:

• plugins.security.ssl.http.enabled (Статическая): Указывает, следует ли включить TLS на уровне REST. Если включено, разрешен только HTTPS. Необязательно. По умолчанию установлено в false.

• plugins.security.ssl.http.keystore_type (Статическая): Тип файла хранилища ключей. Необязательно. Допустимые значения: JKS или PKCS12/PFX. По умолчанию установлено в JKS.

• plugins.security.ssl.http.keystore_filepath (Статическая): Путь к файлу хранилища ключей, который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.http.keystore_alias (Статическая): Имя псевдонима хранилища ключей. Необязательно. По умолчанию используется первый псевдоним.

• plugins.security.ssl.http.keystore_password (Статическая): Пароль для хранилища ключей. По умолчанию установлено в changeit.

• plugins.security.ssl.http.truststore_type (Статическая): Тип файла доверенного хранилища. Необязательно. Допустимые значения: JKS или PKCS12/PFX. По умолчанию установлено в JKS.

• plugins.security.ssl.http.truststore_filepath (Статическая): Путь к файлу доверенного хранилища, который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.http.truststore_alias (Статическая): Имя псевдонима доверенного хранилища. Необязательно. По умолчанию используются все сертификаты.

• plugins.security.ssl.http.truststore_password (Статическая): Пароль для доверенного хранилища. По умолчанию установлено в changeit.

Для получения дополнительной информации см. раздел TLS на уровне REST.

X.509 PEM-сертификаты и ключи PKCS #8 — настройки TLS на транспортном уровне

Плагин безопасности поддерживает следующие настройки TLS на транспортном уровне, связанные с X.509 PEM-сертификатами и ключами PKCS #8:

• plugins.security.ssl.transport.pemkey_filepath (Статическая): Путь к файлу ключа сертификата (PKCS #8), который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.transport.pemkey_password (Статическая): Пароль для ключа. Укажите эту настройку, если у ключа есть пароль. Необязательно.

• plugins.security.ssl.transport.pemcert_filepath (Статическая): Путь к цепочке сертификатов узла X.509 (формат PEM), который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.transport.pemtrustedcas_filepath (Статическая): Путь к корневым центрам сертификации (формат PEM), который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

Для получения дополнительной информации см. раздел TLS на транспортном уровне.

X.509 PEM-сертификаты и ключи PKCS #8 — настройки TLS на уровне REST

Плагин безопасности поддерживает следующие настройки TLS на уровне REST, связанные с X.509 PEM-сертификатами и ключами PKCS #8:

• plugins.security.ssl.http.enabled (Статическая): Указывает, следует ли включить TLS на уровне REST. Если включено, разрешен только HTTPS. Необязательно. По умолчанию установлено в false.

• plugins.security.ssl.http.pemkey_filepath (Статическая): Путь к файлу ключа сертификата (PKCS #8), который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.http.pemkey_password (Статическая): Пароль для ключа. Укажите эту настройку, если у ключа есть пароль. Необязательно.

• plugins.security.ssl.http.pemcert_filepath (Статическая): Путь к цепочке сертификатов узла X.509 (формат PEM), который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

• plugins.security.ssl.http.pemtrustedcas_filepath (Статическая): Путь к корневым центрам сертификации (формат PEM), который должен находиться в каталоге конфигурации и указываться с использованием относительного пути. Обязательно.

Для получения дополнительной информации см. раздел TLS на уровне REST.

Настройки безопасности на транспортном уровне

Плагин безопасности поддерживает следующие настройки безопасности на транспортном уровне:

• plugins.security.ssl.transport.enabled (Статическая): Указывает, следует ли включить TLS на уровне REST.

• plugins.security.ssl.transport.client.pemkey_password (Статическая): Пароль для частного ключа в формате PEM, используемого клиентом на транспортном уровне.

• plugins.security.ssl.transport.keystore_keypassword (Статическая): Пароль для ключа внутри хранилища ключей.

• plugins.security.ssl.transport.server.keystore_keypassword (Статическая): Пароль для ключа внутри хранилища ключей сервера.

• plugins.security.ssl.transport.server.keystore_alias (Статическая): Имя псевдонима для хранилища ключей сервера.

• plugins.security.ssl.transport.client.keystore_alias (Статическая): Имя псевдонима для хранилища ключей клиента.

• plugins.security.ssl.transport.server.truststore_alias (Статическая): Имя псевдонима для доверенного хранилища сервера.

• plugins.security.ssl.transport.client.truststore_alias (Статическая): Имя псевдонима для доверенного хранилища клиента.

• plugins.security.ssl.client.external_context_id (Статическая): Предоставляет клиенту на транспортном уровне идентификатор для использования внешнего SSL-контекста.

• plugins.security.ssl.transport.principal_extractor_class (Статическая): Указывает класс, реализующий извлечение, чтобы использовать пользовательскую часть сертификата в качестве основного.

• plugins.security.ssl.http.crl.file_path (Статическая): Путь к файлу списка отозванных сертификатов (CRL).

• plugins.security.ssl.http.crl.validate (Статическая): Включает проверку списка отозванных сертификатов (CRL). По умолчанию установлено в false (выключено).

• plugins.security.ssl.http.crl.prefer_crlfile_over_ocsp (Статическая): Указывает, следует ли предпочитать запись сертификата CRL перед записью протокола статуса сертификата в режиме онлайн (OCSP), если сертификат содержит обе записи. Необязательно. По умолчанию установлено в false.

• plugins.security.ssl.http.crl.check_only_end_entities (Статическая): Если установлено в true, проверяются только конечные сертификаты. По умолчанию установлено в true.

• plugins.security.ssl.http.crl.disable_ocsp (Статическая): Отключает OCSP. По умолчанию установлено в false (OCSP включен).

• plugins.security.ssl.http.crl.disable_crldp (Статическая): Отключает конечные точки CRL в сертификатах. По умолчанию установлено в false (конечные точки CRL включены).

• plugins.security.ssl.allow_client_initiated_renegotiation (Статическая): Включает или отключает повторнуюNegotiation, инициированную клиентом. По умолчанию установлено в false (повторнаяNegotiation, инициированная клиентом, не разрешена).

Примеры настроек плагина безопасности

# Common configuration settings
plugins.security.nodes_dn:
  - "CN=*.example.com, OU=SSL, O=Test, L=Test, C=DE"
  - "CN=node.other.com, OU=SSL, O=Test, L=Test, C=DE"
  - "CN=node.example.com, OU=SSL\\, Inc., L=Test, C=DE" # escape additional comma with `\\`
plugins.security.authcz.admin_dn:
  - CN=kirk,OU=client,O=client,L=test, C=de
plugins.security.roles_mapping_resolution: MAPPING_ONLY
plugins.security.ssl.transport.pemcert_filepath: esnode.pem
plugins.security.ssl.transport.pemkey_filepath: esnode-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem
plugins.security.ssl.transport.enforce_hostname_verification: false
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: esnode.pem
plugins.security.ssl.http.pemkey_filepath: esnode-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem
plugins.security.allow_unsafe_democertificates: true
plugins.security.allow_default_init_securityindex: true
plugins.security.nodes_dn_dynamic_config_enabled: false
plugins.security.cert.intercluster_request_evaluator_class: # need example value for this.
plugins.security.audit.type: internal_opensearch
plugins.security.enable_snapshot_restore_privilege: true
plugins.security.check_snapshot_restore_write_privileges: true
plugins.security.cache.ttl_minutes: 60
plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
plugins.security.system_indices.enabled: true
plugins.security.system_indices.indices: [".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opendistro-notifications-*", ".opendistro-notebooks", ".opendistro-asynchronous-search-response*"]
node.max_local_storage_nodes: 3
plugins.security.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[^a-zA-Z\d])(?=.*[0-9])(?=.*[a-z]).{8,}'
plugins.security.restapi.password_validation_error_message: "Password must be minimum 8 characters long and must contain at least one uppercase letter, one lowercase letter, one digit, and one special character."
plugins.security.allow_default_init_securityindex: true
plugins.security.cache.ttl_minutes: 60
#
# REST Management API configuration settings
plugins.security.restapi.roles_enabled: ["all_access","xyz_role"]
plugins.security.restapi.endpoints_disabled.all_access.ACTIONGROUPS: ["PUT","POST","DELETE"] # Alternative example: plugins.security.restapi.endpoints_disabled.xyz_role.LICENSE: ["DELETE"] #
# Audit log configuration settings
plugins.security.audit.enable_rest: true
plugins.security.audit.enable_transport: false
plugins.security.audit.resolve_bulk_requests: false
plugins.security.audit.config.disabled_categories: ["AUTHENTICATED","GRANTED_PRIVILEGES"]
plugins.security.audit.ignore_requests: ["indices:data/read/*","*_bulk"]
plugins.security.audit.threadpool.size: 10
plugins.security.audit.threadpool.max_queue_len: 100000
plugins.security.audit.ignore_users: ['kibanaserver','some*user','/also.*regex possible/']
plugins.security.audit.type: internal_opensearch
#
# external_opensearch settings
plugins.security.audit.config.http_endpoints: ['localhost:9200','localhost:9201','localhost:9202']
plugins.security.audit.config.index: "'auditlog6-'2023.06.15"
plugins.security.audit.config.type: auditlog
plugins.security.audit.config.username: auditloguser
plugins.security.audit.config.password: auditlogpassword
plugins.security.audit.config.enable_ssl: false
plugins.security.audit.config.verify_hostnames: false
plugins.security.audit.config.enable_ssl_client_auth: false
plugins.security.audit.config.cert_alias: mycert
plugins.security.audit.config.pemkey_filepath: key.pem
plugins.security.audit.config.pemkey_content: <...pem base 64 content>
plugins.security.audit.config.pemkey_password: secret
plugins.security.audit.config.pemcert_filepath: cert.pem
plugins.security.audit.config.pemcert_content: <...pem base 64 content>
plugins.security.audit.config.pemtrustedcas_filepath: ca.pem
plugins.security.audit.config.pemtrustedcas_content: <...pem base 64 content>
#
# Webhook settings
plugins.security.audit.config.webhook.url: "http://mywebhook/endpoint"
plugins.security.audit.config.webhook.format: JSON
plugins.security.audit.config.webhook.ssl.verify: false
plugins.security.audit.config.webhook.ssl.pemtrustedcas_filepath: ca.pem
plugins.security.audit.config.webhook.ssl.pemtrustedcas_content: <...pem base 64 content>
#
# log4j settings
plugins.security.audit.config.log4j.logger_name: auditlogger
plugins.security.audit.config.log4j.level: INFO
#
# Advanced configuration settings
plugins.security.authcz.impersonation_dn:
  "CN=spock,OU=client,O=client,L=Test,C=DE":
    - worf
  "cn=webuser,ou=IT,ou=IT,dc=company,dc=com":
    - user2
    - user1
plugins.security.authcz.rest_impersonation_user:
  "picard":
    - worf
  "john":
    - steve
    - martin
plugins.security.allow_default_init_securityindex: false
plugins.security.allow_unsafe_democertificates: false
plugins.security.cache.ttl_minutes: 60
plugins.security.restapi.password_validation_regex: '(?=.*[A-Z])(?=.*[^a-zA-Z\d])(?=.*[0-9])(?=.*[a-z]).{8,}'
plugins.security.restapi.password_validation_error_message: "A password must be at least 8 characters long and contain at least one uppercase letter, one lowercase letter, one digit, and one special character."
plugins.security.restapi.password_min_length: 8
plugins.security.restapi.password_score_based_validation_strength: very_strong
#
# Advanced SSL settings - use only if you understand SSL ins and outs
plugins.security.ssl.transport.client.pemkey_password: superSecurePassword1
plugins.security.ssl.transport.keystore_keypassword: superSecurePassword2
plugins.security.ssl.transport.server.keystore_keypassword: superSecurePassword3
plugins.security.ssl.http.keystore_keypassword: superSecurePassword4
plugins.security.ssl.http.clientauth_mode: REQUIRE
plugins.security.ssl.transport.enabled: true
plugins.security.ssl.transport.server.keystore_alias: my_alias
plugins.security.ssl.transport.client.keystore_alias: my_other_alias
plugins.security.ssl.transport.server.truststore_alias: trustore_alias_1
plugins.security.ssl.transport.client.truststore_alias: trustore_alias_2
plugins.security.ssl.client.external_context_id: my_context_id
plugins.security.ssl.transport.principal_extractor_class: org.opensearch.security.ssl.ExampleExtractor
plugins.security.ssl.http.crl.file_path: ssl/crl/revoked.crl
plugins.security.ssl.http.crl.validate: true
plugins.security.ssl.http.crl.prefer_crlfile_over_ocsp: true
plugins.security.ssl.http.crl.check_only_end_entitites: false
plugins.security.ssl.http.crl.disable_ocsp: true
plugins.security.ssl.http.crl.disable_crldp: true
plugins.security.ssl.allow_client_initiated_renegotiation: true
#
# Expert settings - use only if you understand their use completely: accidental values can potentially cause security risks or failures to OpenSearch Security.
plugins.security.config_index_name: .opendistro_security
plugins.security.cert.oid: '1.2.3.4.5.5'
plugins.security.cert.intercluster_request_evaluator_class: org.opensearch.security.transport.DefaultInterClusterRequestEvaluator
plugins.security.enable_snapshot_restore_privilege: true
plugins.security.check_snapshot_restore_write_privileges: true
plugins.security.cache.ttl_minutes: 60
plugins.security.disabled: false
plugins.security.protected_indices.enabled: true
plugins.security.protected_indices.roles: ['all_access']
plugins.security.protected_indices.indices: []
plugins.security.system_indices.enabled: true
plugins.security.system_indices.indices: ['.opendistro-alerting-config', '.opendistro-ism-*', '.opendistro-reports-*', '.opensearch-notifications-*', '.opensearch-notebooks', '.opensearch-observability', '.opendistro-asynchronous-search-response*', '.replication-metadata-store']

3.6 - Настройки предохранителей

Родительский предохранитель указывает общее доступное количество памяти для всех дочерних предохранителей. Дочерние предохранители указывают общее доступное количество памяти для себя.

Для получения дополнительной информации о статических и динамических настройках см. раздел Конфигурация OpenSearch.

Настройки родительского предохранителя

OpenSearch поддерживает следующие настройки родительского предохранителя:

• indices.breaker.total.use_real_memory (Статическая, логическая): Если установлено в true, родительский предохранитель учитывает фактическое использование памяти. В противном случае родительский предохранитель учитывает количество памяти, зарезервированной дочерними предохранителями. По умолчанию установлено в true.

• indices.breaker.total.limit (Динамическая, процент): Указывает начальный лимит памяти для родительского предохранителя. Если indices.breaker.total.use_real_memory установлено в true, по умолчанию составляет 95% кучи JVM. Если indices.breaker.total.use_real_memory установлено в false, по умолчанию составляет 70% кучи JVM.

Настройки предохранителя данных полей

Предохранитель данных полей ограничивает объем памяти кучи, необходимый для загрузки поля в кэш данных полей. OpenSearch поддерживает следующие настройки предохранителя данных полей:

• indices.breaker.fielddata.limit (Динамическая, процент): Указывает лимит памяти для предохранителя данных полей. По умолчанию составляет 40% кучи JVM.

• indices.breaker.fielddata.overhead (Динамическая, дробное число): Константа, на которую умножаются оценки данных полей для определения окончательной оценки. По умолчанию составляет 1.03.

Настройки предохранителя запросов

Предохранитель запросов ограничивает объем памяти, необходимый для построения структур данных, необходимых для запроса (например, при вычислении агрегатов). OpenSearch поддерживает следующие настройки предохранителя запросов:

• indices.breaker.request.limit (Динамическая, процент): Указывает лимит памяти для предохранителя запросов. По умолчанию составляет 60% кучи JVM.

• indices.breaker.request.overhead (Динамическая, дробное число): Константа, на которую умножаются оценки запросов для определения окончательной оценки. По умолчанию составляет 1.

Настройки предохранителя текущих запросов

Предохранитель текущих запросов ограничивает использование памяти для всех текущих входящих запросов на транспортном и HTTP-уровне. Использование памяти для запроса основано на длине содержимого запроса и включает память, необходимую для необработанного запроса и структурированного объекта, представляющего запрос. OpenSearch поддерживает следующие настройки предохранителя текущих запросов:

• network.breaker.inflight_requests.limit (Динамическая, процент): Указывает лимит памяти для предохранителя текущих запросов. По умолчанию составляет 100% кучи JVM (таким образом, лимит использования памяти для текущего запроса определяется лимитом памяти родительского предохранителя).

• network.breaker.inflight_requests.overhead (Динамическая, дробное число): Константа, на которую умножаются оценки текущих запросов для определения окончательной оценки. По умолчанию составляет 2.

Настройки предохранителя компиляции скриптов

Предохранитель компиляции скриптов ограничивает количество компиляций встроенных скриптов в течение временного интервала. OpenSearch поддерживает следующую настройку предохранителя компиляции скриптов:

• script.max_compilations_rate (Динамическая, ставка): Максимальное количество уникальных динамических скриптов, скомпилированных в течение временного интервала для данного контекста. По умолчанию составляет 150 каждые 5 минут (150/5m).

Настройки предохранителя регулярных выражений

Предохранитель регулярных выражений включает или отключает регулярные выражения и ограничивает их сложность. OpenSearch поддерживает следующие настройки предохранителя регулярных выражений:

• script.painless.regex.enabled (Статическая, строка): Включает регулярные выражения в скриптах Painless. Допустимые значения:

  • limited: Включает регулярные выражения и ограничивает их сложность с помощью настройки script.painless.regex.limit-factor.
  • true: Включает регулярные выражения. Отключает предохранитель регулярных выражений и не ограничивает сложность регулярных выражений.
  • false: Отключает регулярные выражения. Если скрипт Painless содержит регулярное выражение, возвращает ошибку.

  По умолчанию установлено в limited.

• script.painless.regex.limit-factor (Статическая, целое число): Применяется только если script.painless.regex.enabled установлено в limited. Ограничивает количество символов, которые может содержать регулярное выражение в скрипте Painless. Лимит символов рассчитывается путем умножения количества символов во входных данных скрипта на script.painless.regex.limit-factor. По умолчанию составляет 6 (таким образом, если входные данные содержат 5 символов, максимальное количество символов в регулярном выражении составляет 5 · 6 = 30).

3.7 - Настройка кластера

Чтобы узнать больше о статических и динамических настройках, смотрите раздел Настройка OpenSearch.

Настройки маршрутизации и распределения на уровне кластера

OpenSearch поддерживает следующие настройки маршрутизации на уровне кластера и распределения шардов:

cluster.routing.allocation.enable (Динамическая, строка)

Включает или отключает распределение для определенных типов шардов.

Допустимые значения:

• all – Разрешает распределение шардов для всех типов шардов.
• primaries – Разрешает распределение шардов только для первичных шардов.
• new_primaries – Разрешает распределение шардов только для первичных шардов новых индексов.
• none – Распределение шардов не разрешено для любых индексов.

По умолчанию установлено значение all.

cluster.routing.allocation.node_concurrent_incoming_recoveries (Динамическая, целое число)

Настраивает, сколько параллельных входящих восстановлений шардов разрешено на узле. По умолчанию установлено значение 2.

cluster.routing.allocation.node_concurrent_outgoing_recoveries (Динамическая, целое число)

Настраивает, сколько параллельных исходящих восстановлений шардов разрешено на узле. По умолчанию установлено значение 2.

cluster.routing.allocation.node_concurrent_recoveries (Динамическая, строка)

Используется для установки значений cluster.routing.allocation.node_concurrent_incoming_recoveries и cluster.routing.allocation.node_concurrent_outgoing_recoveries на одно и то же значение.

cluster.routing.allocation.node_initial_primaries_recoveries (Динамическая, целое число)

Устанавливает количество восстановлений для нераспределенных первичных шардов после перезапуска узла. По умолчанию установлено значение 4.

cluster.routing.allocation.same_shard.host (Динамическая, логическое)

При установке в true предотвращает распределение нескольких копий шарда на разные узлы на одном хосте. По умолчанию установлено значение false.

cluster.routing.rebalance.enable (Динамическая, строка)

Включает или отключает перераспределение для определенных типов шардов.

Допустимые значения:

• all – Разрешает балансировку шардов для всех типов шардов.
• primaries – Разрешает балансировку шардов только для первичных шардов.
• replicas – Разрешает балансировку шардов только для реплик.
• none – Балансировка шардов не разрешена для любых индексов.

По умолчанию установлено значение all.

cluster.routing.allocation.allow_rebalance (Динамическая, строка)

Указывает, когда разрешено перераспределение шардов.

Допустимые значения:

• always – Всегда разрешать перераспределение.
• indices_primaries_active – Разрешать перераспределение только когда все первичные шары в кластере распределены.
• indices_all_active – Разрешать перераспределение только когда все шары в кластере распределены.

По умолчанию установлено значение indices_all_active.

cluster.routing.allocation.cluster_concurrent_rebalance (Динамическая, целое число)

Позволяет контролировать, сколько параллельных перераспределений шардов разрешено в кластере. По умолчанию установлено значение 2.

cluster.routing.allocation.balance.shard (Динамическая, число с плавающей точкой)

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

cluster.routing.allocation.balance.index (Динамическая, число с плавающей точкой)

Определяет весовой коэффициент для количества шардов на индекс, распределенных на узел. По умолчанию установлено значение 0.55.

cluster.routing.allocation.balance.threshold (Динамическая, число с плавающей точкой)

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

cluster.routing.allocation.balance.prefer_primary (Динамическая, логическое)

При установке в true OpenSearch пытается равномерно распределить первичные шары между узлами кластера. Включение этой настройки не всегда гарантирует равное количество первичных шардов на каждом узле, особенно в случае сбоя. Изменение этой настройки на false после установки в true не вызывает перераспределение первичных шардов. По умолчанию установлено значение false.

cluster.routing.allocation.rebalance.primary.enable (Динамическая, логическое)

При установке в true OpenSearch пытается перераспределить первичные шары между узлами кластера. При включении кластер пытается поддерживать количество первичных шардов на каждом узле, с максимальным буфером, определенным настройкой cluster.routing.allocation.rebalance.primary.buffer. Изменение этой настройки на false после установки в true не вызывает перераспределение первичных шардов. По умолчанию установлено значение false.

cluster.routing.allocation.rebalance.primary.buffer (Динамическая, число с плавающей точкой)

Определяет максимальный допустимый буфер первичных шардов между узлами, когда включена настройка cluster.routing.allocation.rebalance.primary.enable. По умолчанию установлено значение 0.1.

cluster.routing.allocation.disk.threshold_enabled (Динамическая, логическое)

При установке в false отключает решение о распределении по диску. Это также удалит любые существующие блокировки индекса index.blocks.read_only_allow_delete, когда отключено. По умолчанию установлено значение true.

Настройки водяных знаков дискового пространства

cluster.routing.allocation.disk.watermark.low (Динамическая, строка)

Контролирует низкий водяной знак для использования дискового пространства. При установке в процентном соотношении OpenSearch не будет распределять шары на узлы с указанным процентом использования диска. Это также можно указать в виде дробного значения, например, 0.85. Наконец, это можно установить в байтовом значении, например, 400mb. Эта настройка не влияет на первичные шары новых индексов, но предотвратит распределение их реплик. По умолчанию установлено значение 85%.

cluster.routing.allocation.disk.watermark.high (Динамическая, строка)

Контролирует высокий водяной знак. OpenSearch попытается переместить шары с узла, использование диска на котором превышает установленный процент. Это также можно указать в виде дробного значения, например, 0.85. Наконец, это можно установить в байтовом значении, например, 400mb. Эта настройка влияет на распределение всех шардов. По умолчанию установлено значение 90%.

cluster.routing.allocation.disk.watermark.flood_stage (Динамическая, строка)

Контролирует водяной знак на уровне затопления. Это последний шаг для предотвращения исчерпания дискового пространства на узлах. OpenSearch применяет блокировку индекса только для чтения (index.blocks.read_only_allow_delete) ко всем индексам, на которых есть один или несколько шардов, распределенных на узле, и хотя бы один диск превышает уровень затопления. Блокировка индекса снимается, как только использование диска падает ниже высокого водяного знака. Это также можно указать в виде дробного значения, например, 0.85. Наконец, это можно установить в байтовом значении, например, 400mb. По умолчанию установлено значение 95%.

cluster.info.update.interval (Динамическая, единица времени)

Устанавливает, как часто OpenSearch должен проверять использование диска для каждого узла в кластере. По умолчанию установлено значение 30s.

Настройки распределения шардов по атрибутам

cluster.routing.allocation.include. (Динамическая, перечисление)

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

cluster.routing.allocation.require. (Динамическая, перечисление)

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

cluster.routing.allocation.exclude. (Динамическая, перечисление)

Не распределяет шары на узел, атрибут которого содержит любое из включенных значений, разделенных запятыми. Настройки распределения кластера поддерживают следующие встроенные атрибуты.

Допустимые значения:

• _name – Совпадение узлов по имени узла.
• _host_ip – Совпадение узлов по IP-адресу хоста.
• _publish_ip – Совпадение узлов по публикуемому IP-адресу.
• _ip – Совпадение по _host_ip или _publish_ip.
• _host – Совпадение узлов по имени хоста.
• _id – Совпадение узлов по идентификатору узла.
• _tier – Совпадение узлов по роли уровня данных.

Настройки перемещения шардов

cluster.routing.allocation.shard_movement_strategy (Динамическая, перечисление)

Определяет порядок, в котором шары перемещаются с исходящих узлов на входящие.

Эта настройка поддерживает следующие стратегии:

• PRIMARY_FIRST – Первичные шары перемещаются первыми, перед репликами. Эта приоритизация может помочь предотвратить переход состояния здоровья кластера в красный, если узлы, на которые перемещаются шары, выйдут из строя в процессе.
• REPLICA_FIRST – Репликационные шары перемещаются первыми, перед первичными. Эта приоритизация может помочь предотвратить переход состояния здоровья кластера в красный при выполнении перемещения шардов в кластере OpenSearch с смешанными версиями и включенной репликацией сегментов. В этой ситуации первичные шары, перемещенные на узлы OpenSearch более новой версии, могут попытаться скопировать файлы сегментов на репликационные шары более старой версии OpenSearch, что приведет к сбою шардов. Перемещение репликационных шардов первыми может помочь избежать этого в кластерах с несколькими версиями.
• NO_PREFERENCE – Поведение по умолчанию, при котором порядок перемещения шардов не имеет значения.

cluster.routing.search_replica.strict (Динамическая, логическое)

Контролирует, как маршрутизируются поисковые запросы, когда для индекса существуют репликационные шары, например, когда index.number_of_search_replicas больше 0. Эта настройка применяется только в случае, если для индекса настроены поисковые реплики. При установке в true все поисковые запросы для таких индексов маршрутизируются только на репликационные шары. Если репликационные шары не назначены, запросы завершаются неудачей. При установке в false, если репликационные шары не назначены, запросы возвращаются к любому доступному шару. По умолчанию установлено значение true.

cluster.allocator.gateway.batch_size (Динамическая, целое число)

Ограничивает количество шардов, отправляемых на узлы данных в одной партии для получения метаданных любых нераспределенных шардов. По умолчанию установлено значение 2000.

cluster.allocator.existing_shards_allocator.batch_enabled (Статическая, логическая)

Включает пакетное распределение нераспределенных шардов, которые уже существуют на диске, вместо распределения одного шара за раз. Это снижает нагрузку на память и транспорт, получая метаданные любых нераспределенных шардов в пакетном вызове. По умолчанию установлено значение false.

cluster.routing.allocation.total_shards_per_node (Динамическая, целое число)

Максимальное общее количество первичных и репликационных шардов, которые могут быть распределены на один узел. По умолчанию установлено значение -1 (без ограничений). Помогает равномерно распределять шары по узлам, ограничивая общее количество шардов на узел. Используйте с осторожностью, так как шары могут оставаться нераспределенными, если узлы достигнут своих настроенных лимитов.

cluster.routing.allocation.total_primary_shards_per_node (Динамическая, целое число)

Максимальное количество первичных шардов, которые могут быть распределены на один узел. Эта настройка применима только для кластеров с удаленной поддержкой. По умолчанию установлено значение -1 (без ограничений). Помогает равномерно распределять первичные шары по узлам, ограничивая количество первичных шардов на узел. Используйте с осторожностью, так как первичные шары могут оставаться нераспределенными, если узлы достигнут своих настроенных лимитов.

Настройки шардов, блокировок и задач на уровне кластера

OpenSearch поддерживает следующие настройки шардов, блокировок и задач на уровне кластера:

action.search.shard_count.limit (Целое число)

Ограничивает максимальное количество шардов, которые могут быть задействованы во время поиска. Запросы, превышающие этот лимит, будут отклонены.

cluster.blocks.read_only (Логическое)

Устанавливает весь кластер в режим только для чтения. По умолчанию установлено значение false.

cluster.blocks.read_only_allow_delete (Логическое)

Похоже на cluster.blocks.read_only, но позволяет удалять индексы.

cluster.max_shards_per_node (Целое число)

Ограничивает общее количество первичных и репликационных шардов для кластера. Лимит рассчитывается следующим образом: cluster.max_shards_per_node умножается на количество не замороженных узлов данных. Шары для закрытых индексов не учитываются в этом лимите. По умолчанию установлено значение 1000.

cluster.persistent_tasks.allocation.enable (Строка)

Включает или отключает распределение для постоянных задач.

Допустимые значения:

• all – Разрешает назначение постоянных задач на узлы.
• none – Распределение для постоянных задач не разрешено. Это не влияет на уже работающие постоянные задачи.

По умолчанию установлено значение all.

cluster.persistent_tasks.allocation.recheck_interval (Единица времени)

Менеджер кластера автоматически проверяет, нужно ли назначать постоянные задачи, когда состояние кластера изменяется значительным образом. Существуют и другие факторы, такие как использование памяти, которые повлияют на то, будут ли постоянные задачи назначены на узлы, но не вызывают изменения состояния кластера. Эта настройка определяет, как часто выполняются проверки назначения в ответ на эти факторы. По умолчанию установлено значение 30 секунд, при этом минимальное значение составляет 10 секунд.

Настройки медленных логов на уровне кластера

Для получения дополнительной информации смотрите раздел Медленные логи запросов поиска.

cluster.search.request.slowlog.threshold.warn (Единица времени)

Устанавливает порог WARN для медленных логов на уровне запросов. По умолчанию установлено значение -1.

cluster.search.request.slowlog.threshold.info (Единица времени)

Устанавливает порог INFO для медленных логов на уровне запросов. По умолчанию установлено значение -1.

cluster.search.request.slowlog.threshold.debug (Единица времени)

Устанавливает порог DEBUG для медленных логов на уровне запросов. По умолчанию установлено значение -1.

cluster.search.request.slowlog.threshold.trace (Единица времени)

Устанавливает порог TRACE для медленных логов на уровне запросов. По умолчанию установлено значение -1.

cluster.search.request.slowlog.level (Строка)

Устанавливает минимальный уровень медленного лога для записи: WARN, INFO, DEBUG и TRACE. По умолчанию установлено значение TRACE.

Настройки индекса на уровне кластера

Для получения информации о настройках индекса на уровне индекса смотрите раздел Настройки индекса на уровне кластера.

Настройки координации на уровне кластера

OpenSearch поддерживает следующие настройки координации на уровне кластера. Все настройки в этом списке являются динамическими:

cluster.fault_detection.leader_check.timeout (Единица времени)

Количество времени, в течение которого узел ждет ответа от избранного менеджера кластера во время проверки лидера, прежде чем считать проверку неудачной. Допустимые значения от 1ms до 60s, включая. По умолчанию установлено значение 10s. Изменение этой настройки на значение, отличное от значения по умолчанию, может привести к нестабильности кластера.

cluster.fault_detection.follower_check.timeout (Единица времени)

Количество времени, в течение которого избранный менеджер кластера ждет ответа во время проверки последователя, прежде чем считать проверку неудачной. Допустимые значения от 1ms до 60s, включая. По умолчанию установлено значение 10s. Изменение этой настройки на значение, отличное от значения по умолчанию, может привести к нестабильности кластера.

cluster.fault_detection.follower_check.interval (Единица времени)

Количество времени, в течение которого избранный менеджер кластера ждет между отправкой проверок последователей другим узлам в кластере. Допустимые значения 100ms и выше. По умолчанию установлено значение 1000ms. Изменение этой настройки на значение, отличное от значения по умолчанию, может привести к нестабильности кластера.

cluster.follower_lag.timeout (Единица времени)

Количество времени, в течение которого избранный менеджер кластера ждет получения подтверждений обновлений состояния кластера от отстающих узлов. По умолчанию установлено значение 90s. Если узел не успешно применяет обновление состояния кластера в течение этого времени, он считается неудавшимся и удаляется из кластера.

cluster.publish.timeout (Единица времени)

Количество времени, в течение которого менеджер кластера ждет, пока каждое обновление состояния кластера будет полностью опубликовано на всех узлах, если только discovery.type не установлен на single-node. По умолчанию установлено значение 30s.

Настройки пределов ответов CAT на уровне кластера

OpenSearch поддерживает следующие настройки пределов ответов CAT API на уровне кластера, все из которых являются динамическими:

cat.indices.response.limit.number_of_indices (Целое число)

Устанавливает предел на количество индексов, возвращаемых API CAT Indices. Значение по умолчанию -1 (без ограничений). Если количество индексов в ответе превышает этот предел, API возвращает ошибку 429. Чтобы избежать этого, вы можете указать фильтр по шаблону индекса в вашем запросе (например, _cat/indices/<index-pattern>).

cat.shards.response.limit.number_of_shards (Целое число)

Устанавливает предел на количество шардов, возвращаемых API CAT Shards. Значение по умолчанию -1 (без ограничений). Если количество шардов в ответе превышает этот предел, API возвращает ошибку 429. Чтобы избежать этого, вы можете указать фильтр по шаблону индекса в вашем запросе (например, _cat/shards/<index-pattern>).

cat.segments.response.limit.number_of_indices (Целое число)

Устанавливает предел на количество индексов, возвращаемых API CAT Segments. Значение по умолчанию -1 (без ограничений). Если количество индексов в ответе превышает этот предел, API возвращает ошибку 429. Чтобы избежать этого, вы можете указать фильтр по шаблону индекса в вашем запросе (например, _cat/segments/<index-pattern>).

3.8 - Настройка индекса

Чтобы узнать больше о статических и динамических настройках, смотрите Конфигурирование OpenSearch.

Настройки индекса уровня кластера

Существует два типа настроек кластера:

• Статические настройки индекса уровня кластера — это настройки, которые нельзя обновить, пока кластер работает. Чтобы обновить статическую настройку, необходимо остановить кластер, обновить настройку, а затем перезапустить кластер.
• Динамические настройки индекса уровня кластера — это настройки, которые можно обновлять в любое время.

Статические настройки индекса уровня кластера

OpenSearch поддерживает следующие статические настройки индекса уровня кластера:

• indices.cache.cleanup_interval (Единица времени): Запланирует периодическую фоновую задачу, которая очищает истекшие записи из кэша с указанным интервалом. По умолчанию 1m (1 минута). Для получения дополнительной информации смотрите Кэш запросов индекса.

• indices.requests.cache.size (Строка): Размер кэша в процентах от размера кучи (например, чтобы использовать 1% кучи, укажите 1%). По умолчанию 1%. Для получения дополнительной информации смотрите Кэш запросов индекса.

Динамические настройки индекса уровня кластера

OpenSearch поддерживает следующие динамические настройки индекса уровня кластера:

• action.auto_create_index (Булевый): Автоматически создает индекс, если индекс еще не существует. Также применяет любые конфигурации шаблонов индексов. По умолчанию true.

• indices.recovery.max_concurrent_file_chunks (Целое число): Количество частей файлов, отправляемых параллельно для каждой операции восстановления. По умолчанию 2.

• indices.recovery.max_concurrent_operations (Целое число): Количество операций, отправляемых параллельно для каждого восстановления. По умолчанию 1.

• indices.recovery.max_concurrent_remote_store_streams (Целое число): Количество потоков к удаленному репозиторию, которые могут быть открыты параллельно при восстановлении индекса из удаленного хранилища. По умолчанию 20.

• indices.replication.max_bytes_per_sec (Строка): Ограничивает общий входящий и исходящий трафик репликации для каждого узла. Если значение не указано в конфигурации, используется настройка indices.recovery.max_bytes_per_sec, по умолчанию равная 40 МБ. Если вы установите значение трафика репликации меньше или равным 0 МБ, ограничение скорости будет отключено, что приведет к передаче данных репликации с максимальной возможной скоростью.

• indices.fielddata.cache.size (Строка): Максимальный размер кэша данных полей. Может быть указан как абсолютное значение (например, 8 ГБ) или процент от кучи узла (например, 50%). Это значение статическое, поэтому его необходимо указать в файле opensearch.yml. Если вы не укажете эту настройку, максимальный размер будет неограниченным. Это значение должно быть меньше, чем indices.breaker.fielddata.limit. Для получения дополнительной информации смотрите Систему защиты от переполнения кэша данных полей.

• indices.query.bool.max_clause_count (Целое число): Определяет максимальное произведение полей и терминов, которые могут быть запрошены одновременно. До версии OpenSearch 2.16 для применения этой статической настройки требовалась перезагрузка кластера. Теперь она динамическая, существующие пулы потоков поиска могут использовать старое статическое значение, что может привести к исключениям TooManyClauses. Новые пулы потоков используют обновленное значение. По умолчанию 1024.

• cluster.remote_store.index.path.type (Строка): Стратегия пути для данных, хранящихся в удаленном хранилище. Эта настройка эффективна только для кластеров с включенным удаленным хранилищем. Эта настройка поддерживает следующие значения:

  • fixed: Хранит данные в структуре пути <repository_base_path>/<index_uuid>/<shard_id>/.
  • hashed_prefix: Хранит данные в структуре пути hash(<shard-data-identifier>)/<repository_base_path>/<index_uuid>/<shard_id>/.
  • hashed_infix: Хранит данные в структуре пути <repository_base_path>/hash(<shard-data-identifier>)/<index_uuid>/<shard_id>/. shard-data-identifier характеризуется index_uuid, shard_id, типом данных (translog, segments) и типом данных (data, metadata, lock_files). По умолчанию fixed.

• cluster.remote_store.index.path.hash_algorithm (Строка): Хеш-функция, используемая для получения хеш-значения, когда cluster.remote_store.index.path.type установлено на hashed_prefix или hashed_infix. Эта настройка эффективна только для кластеров с включенным удаленным хранилищем. Эта настройка поддерживает следующие значения:

  • fnv_1a_base64: Использует хеш-функцию FNV1a и генерирует безопасное для URL 20-битное хеш-значение в формате base64.
  • fnv_1a_composite_1: Использует хеш-функцию FNV1a и генерирует пользовательское закодированное хеш-значение, которое хорошо масштабируется с большинством опций удаленного хранилища. Функция FNV1a генерирует 64-битное значение. Пользовательское кодирование использует 6 старших бит для создания безопасного для URL символа base64 и следующие 14 бит для создания двоичной строки. По умолчанию fnv_1a_composite_1.

• cluster.remote_store.translog.transfer_timeout (Единица времени): Управляет значением таймаута при загрузке файлов translog и контрольных точек во время синхронизации с удаленным хранилищем. Эта настройка применяется только для кластеров с включенным удаленным хранилищем. По умолчанию 30 секунд.

• cluster.remote_store.index.segment_metadata.retention.max_count (Целое число): Управляет минимальным количеством файлов метаданных, которые необходимо сохранить в репозитории сегментов на удаленном хранилище. Значение ниже 1 отключает удаление устаревших файлов метаданных сегментов. По умолчанию 10.

• cluster.remote_store.segment.transfer_timeout (Единица времени): Управляет максимальным временем ожидания обновления всех новых сегментов после обновления в удаленное хранилище. Если загрузка не завершится в течение указанного времени, будет выброшено исключение SegmentUploadFailedException. По умолчанию 30 минут. Минимальное ограничение составляет 10 минут.

• cluster.remote_store.translog.path.prefix (Строка): Управляет фиксированным префиксом пути для данных translog на кластере с включенным удаленным хранилищем. Эта настройка применяется только в том случае, если настройка cluster.remote_store.index.path.type установлена на HASHED_PREFIX или HASHED_INFIX. По умолчанию пустая строка, “”.

• cluster.remote_store.segments.path.prefix (Строка): Управляет фиксированным префиксом пути для данных сегментов на кластере с включенным удаленным хранилищем. Эта настройка применяется только в том случае, если настройка cluster.remote_store.index.path.type установлена на HASHED_PREFIX или HASHED_INFIX. По умолчанию пустая строка, “”.

• cluster.snapshot.shard.path.prefix (Строка): Управляет фиксированным префиксом пути для блобов уровня сегмента снимка. Эта настройка применяется только в том случае, если настройка repository.shard_path_type установлена на HASHED_PREFIX или HASHED_INFIX. По умолчанию пустая строка, “”.

• cluster.default_number_of_replicas (Целое число): Управляет значением по умолчанию для количества реплик индексов в кластере. Настройка уровня индекса index.number_of_replicas по умолчанию принимает это значение, если не настроена. По умолчанию 1.

• cluster.thread_pool.<fixed-threadpool>.size (Целое число): Управляет размерами как фиксированных, так и изменяемых очередей пулов потоков. Переопределяет значения по умолчанию, указанные в opensearch.yml.

• cluster.thread_pool.<scaling-threadpool>.max (Целое число): Устанавливает максимальный размер пула потоков с изменяемым размером. Переопределяет значение по умолчанию, указанное в opensearch.yml.

• cluster.thread_pool.<scaling-threadpool>.core (Целое число): Указывает базовый размер пула потоков с изменяемым размером. Переопределяет значение по умолчанию, указанное в opensearch.yml.

Настройки индекса уровня индекса

Вы можете указать настройки индекса при создании индекса. Существует два типа настроек индекса:

• Статические настройки индекса уровня индекса — это настройки, которые нельзя обновить, пока индекс открыт. Чтобы обновить статическую настройку, необходимо закрыть индекс, обновить настройку, а затем снова открыть индекс.

• Динамические настройки индекса уровня индекса — это настройки, которые можно обновлять в любое время.

Указание настройки при создании индекса

При создании индекса вы можете указать его статические или динамические настройки следующим образом:

PUT /testindex
{
  "settings": {
    "index.number_of_shards": 1,
    "index.number_of_replicas": 2
  }
}

Статические настройки индекса уровня индекса

OpenSearch поддерживает следующие статические настройки индекса уровня индекса:

• index.number_of_shards (Целое число): Количество первичных шардов в индексе. По умолчанию 1.

• index.number_of_routing_shards (Целое число): Количество шардов маршрутизации, используемых для разделения индекса.

• index.shard.check_on_startup (Булевый): Указывает, следует ли проверять шардов индекса на наличие повреждений. Доступные опции:

  • false (не проверять на повреждения),
  • checksum (проверять на физические повреждения),
  • true (проверять как на физические, так и на логические повреждения). По умолчанию false.

• index.codec (Строка): Определяет, как сжимаются и хранятся на диске сохраненные поля индекса. Эта настройка влияет на размер шардов индекса и производительность операций индексации.

  Допустимые значения:

  • default
  • best_compression
  • zstd (OpenSearch 2.9 и позже)
  • zstd_no_dict (OpenSearch 2.9 и позже)
  • qat_lz4 (OpenSearch 2.14 и позже, на поддерживаемых системах)
  • qat_deflate (OpenSearch 2.14 и позже, на поддерживаемых системах)

  Для zstd, zstd_no_dict, qat_lz4 и qat_deflate вы можете указать уровень сжатия в настройке index.codec.compression_level. Для получения дополнительной информации смотрите Настройки кодека индекса. Опционально. По умолчанию default.

• index.codec.compression_level (Целое число): Настройка уровня сжатия обеспечивает компромисс между коэффициентом сжатия и скоростью. Более высокий уровень сжатия приводит к более высокому коэффициенту сжатия (меньший размер хранения), но замедляет скорость сжатия и распаковки, что приводит к увеличению задержек при индексации и поиске. Эта настройка может быть указана только если index.codec установлен на zstd и zstd_no_dict в OpenSearch 2.9 и позже или qat_lz4 и qat_deflate в OpenSearch 2.14 и позже. Допустимые значения — целые числа в диапазоне [1, 6]. Для получения дополнительной информации смотрите Настройки кодека индекса. Опционально. По умолчанию 3.

• index.codec.qatmode (Строка): Режим аппаратного ускорения, используемый для кодеков сжатия qat_lz4 и qat_deflate. Допустимые значения: auto и hardware. Для получения дополнительной информации смотрите Настройки кодека индекса. Опционально. По умолчанию auto.

• index.routing_partition_size (Целое число): Количество шардов, к которым может быть направлено значение пользовательской маршрутизации. Маршрутизация помогает несбалансированному кластеру, перемещая значения к подмножеству шардов, а не к одному шару. Чтобы включить маршрутизацию, установите это значение больше 1, но меньше index.number_of_shards. По умолчанию 1.

• index.soft_deletes.retention_lease.period (Единица времени): Максимальное время хранения истории операций шара. По умолчанию 12 часов.

• index.load_fixed_bitset_filters_eagerly (Булевый): Указывает, должен ли OpenSearch предварительно загружать кэшированные фильтры. Доступные опции: true и false. По умолчанию true.

• index.hidden (Булевый): Указывает, должен ли индекс быть скрытым. Скрытые индексы не возвращаются в результате запросов, содержащих подстановочные знаки. Доступные опции: true и false. По умолчанию false.

• index.merge.policy (Строка): Эта настройка управляет политикой слияния для сегментов Lucene. Доступные опции: tiered и log_byte_size. По умолчанию tiered, но для временных данных, таких как журналы событий, рекомендуется использовать политику слияния log_byte_size, которая может улучшить производительность запросов при выполнении диапазонных запросов по полю @timestamp. Рекомендуется не изменять политику слияния существующего индекса. Вместо этого настройте эту опцию при создании нового индекса.

• index.merge_on_flush.enabled (Булевый): Эта настройка управляет функцией слияния при обновлении Apache Lucene, которая направлена на уменьшение количества сегментов путем выполнения слияний при обновлении (или, в терминах OpenSearch, при сбросе). По умолчанию true.

• index.merge_on_flush.max_full_flush_merge_wait_time (Единица времени): Эта настройка устанавливает время ожидания для слияний, когда index.merge_on_flush.enabled включен. По умолчанию 10 секунд.

• index.merge_on_flush.policy (Строка): Эта настройка управляет тем, какая политика слияния должна использоваться, когда index.merge_on_flush.enabled включен. По умолчанию default.

• index.check_pending_flush.enabled (Булевый): Эта настройка управляет параметром checkPendingFlushOnUpdate индексации Apache Lucene, который указывает, должен ли поток индексации проверять наличие ожидающих сбросов при обновлении, чтобы сбросить буферы индексации на диск. По умолчанию true.

• index.use_compound_file (Булевый): Эта настройка управляет параметрами useCompoundFile индексации Apache Lucene, которые указывают, будут ли новые файлы сегментов упакованы в составной файл. По умолчанию true.

• index.append_only.enabled (Булевый): Установите значение true, чтобы предотвратить любые обновления документов в индексе. По умолчанию false.

Обновление статической настройки индекса

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

Сначала закройте индекс:

POST /testindex/_close

Затем обновите настройки, отправив запрос к конечной точке _settings:

PUT /testindex/_settings
{
  "index": {
    "codec": "zstd_no_dict",
    "codec.compression_level": 3
  }
}

Наконец, снова откройте индекс, чтобы включить операции чтения и записи:

POST /testindex/_open

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

Динамические настройки индекса уровня индекса

OpenSearch поддерживает следующие динамические настройки индекса уровня индекса:

• index.number_of_replicas (Целое число): Количество реплик, которые должен иметь каждый первичный шард. Например, если у вас 4 первичных шарда и вы установите index.number_of_replicas на 3, индекс будет иметь 12 реплик. Если не установлено, по умолчанию используется значение cluster.default_number_of_replicas (по умолчанию 1).

• index.number_of_search_replicas (Целое число): Количество поисковых реплик, которые должен иметь каждый первичный шард. Например, если у вас 4 первичных шарда и вы установите index.number_of_search_replicas на 3, индекс будет иметь 12 поисковых реплик. По умолчанию 0.

• index.auto_expand_replicas (Строка): Указывает, должен ли кластер автоматически добавлять реплики на основе количества узлов данных. Укажите нижнюю и верхнюю границы (например, 0–9) или all для верхней границы. Например, если у вас 5 узлов данных и вы установите index.auto_expand_replicas на 0–3, кластер не добавит еще одну реплику. Однако, если вы установите это значение на 0-all и добавите 2 узла, всего 7, кластер расширится до 6 реплик. По умолчанию отключено.

• index.auto_expand_search_replicas (Строка): Управляет тем, автоматически ли кластер регулирует количество поисковых реплик на основе количества доступных узлов поиска. Укажите значение в виде диапазона с нижней и верхней границей, например, 0-3 или 0-all. Если вы не укажете значение, эта функция отключена.

  Например, если у вас 5 узлов данных и вы установите index.auto_expand_search_replicas на 0-3, индекс может иметь до 3 поисковых реплик, и кластер не добавит еще одну поисковую реплику. Однако, если вы установите index.auto_expand_search_replicas на 0-all и добавите 2 узла, всего 7, кластер расширится до 7 поисковых реплик. Эта настройка по умолчанию отключена.

• index.search.idle.after (Единица времени): Время, в течение которого шард должен ждать запроса поиска или получения, прежде чем перейти в состояние ожидания. По умолчанию 30 секунд.

• index.search.default_pipeline (Строка): Имя поискового конвейера, который используется, если при поиске индекса не установлен явный конвейер. Если установлен конвейер по умолчанию и он не существует, запросы к индексу завершатся неудачей. Используйте имя конвейера _none, чтобы указать отсутствие конвейера поиска по умолчанию. Для получения дополнительной информации смотрите Конвейер поиска по умолчанию.

• index.refresh_interval (Единица времени): Как часто индекс должен обновляться, что публикует его последние изменения и делает их доступными для поиска. Может быть установлено на -1 для отключения обновления. По умолчанию 1 секунда.

• index.max_result_window (Целое число): Максимальное значение from + size для запросов к индексу. from — это начальный индекс для поиска, а size — количество результатов для возврата. По умолчанию 10000.

• index.max_inner_result_window (Целое число): Максимальное значение from + size, которое указывает количество возвращаемых вложенных результатов поиска и наиболее релевантных документов, агрегированных во время запроса. from — это начальный индекс для поиска, а size — количество верхних результатов для возврата. По умолчанию 100.

• index.max_rescore_window (Целое число): Максимальное значение window_size для запросов пересчета к индексу. Запросы пересчета изменяют порядок документов индекса и возвращают новый балл, который может быть более точным. По умолчанию такое же, как index.max_inner_result_window, или 10000 по умолчанию.

• index.max_docvalue_fields_search (Целое число): Максимальное количество docvalue_fields, разрешенных в запросе. По умолчанию 100.

• index.max_script_fields (Целое число): Максимальное количество script_fields, разрешенных в запросе. По умолчанию 32.

• index.max_ngram_diff (Целое число): Максимальная разница между значениями min_gram и max_gram для NGramTokenizer и NGramTokenFilter. По умолчанию 1.

• index.max_shingle_diff (Целое число): Максимальная разница между max_shingle_size и min_shingle_size, которая подается в фильтр токенов shingle. По умолчанию 3.

• index.max_refresh_listeners (Целое число): Максимальное количество слушателей обновления, которые может иметь каждый шард.

• index.analyze.max_token_count (Целое число): Максимальное количество токенов, которые могут быть возвращены из операции API _analyze. По умолчанию 10000.

• index.highlight.max_analyzed_offset (Целое число): Количество символов, которые может анализировать запрос на выделение. По умолчанию 1000000.

• index.max_terms_count (Целое число): Максимальное количество терминов, которые может принять запрос терминов. По умолчанию 65536.

• index.max_regex_length (Целое число): Максимальная длина символов регулярного выражения, которое может быть в запросе regexp. По умолчанию 1000.

• index.query.default_field (Список): Поле или список полей, которые OpenSearch использует в запросах, если поле не указано в параметрах.

• index.query.max_nested_depth (Целое число): Максимальное количество уровней вложенности для вложенных запросов. По умолчанию 20. Минимум 1 (один вложенный запрос).

• index.requests.cache.enable (Булевый): Включает или отключает кэш запросов индекса. По умолчанию true. Для получения дополнительной информации смотрите Кэш запросов индекса.

• index.routing.allocation.enable (Строка): Указывает параметры для распределения шардов индекса. Доступные опции:

  • all (разрешить распределение для всех шардов),
  • primaries (разрешить распределение только для первичных шардов),
  • new_primaries (разрешить распределение только для новых первичных шардов),
  • none (не разрешать распределение). По умолчанию all.

• index.routing.rebalance.enable (Строка): Включает перераспределение шардов для индекса. Доступные опции:

  • all (разрешить перераспределение для всех шардов),
  • primaries (разрешить перераспределение только для первичных шардов),
  • replicas (разрешить перераспределение только для реплик),
  • none (не разрешать перераспределение). По умолчанию all.

• index.gc_deletes (Единица времени): Время хранения номера версии удаленного документа. По умолчанию 60 секунд.

• index.default_pipeline (Строка): Конвейер узла обработки по умолчанию для индекса. Если установлен конвейер по умолчанию и он не существует, запросы к индексу завершатся неудачей. Имя конвейера _none указывает на то, что у индекса нет конвейера обработки.

• index.final_pipeline (Строка): Конечный конвейер узла обработки для индекса. Если установлен конечный конвейер и он не существует, запросы к индексу завершатся неудачей. Имя конвейера _none указывает на то, что у индекса нет конвейера обработки.

• index.optimize_doc_id_lookup.fuzzy_set.enabled (Булевый): Эта настройка управляет тем, следует ли включать fuzzy_set для оптимизации поиска идентификаторов документов в индексах или запросах, используя дополнительную структуру данных, в данном случае структуру данных Bloom filter. Включение этой настройки улучшает производительность операций upsert и поиска, которые зависят от идентификаторов документов, создавая новую структуру данных (Bloom filter). Bloom filter позволяет обрабатывать отрицательные случаи (то есть идентификаторы, отсутствующие в существующем индексе) с помощью более быстрых обращений вне кучи. Обратите внимание, что создание Bloom filter требует дополнительного использования кучи во время индексации. По умолчанию false.

• index.optimize_doc_id_lookup.fuzzy_set.false_positive_probability (Число с плавающей точкой)

Устанавливает вероятность ложного срабатывания для базового fuzzy_set (то есть, фильтра Блума). Более низкая вероятность ложного срабатывания обеспечивает более высокую пропускную способность для операций upsert и get, но приводит к увеличению использования памяти и хранилища. Допустимые значения находятся в диапазоне от 0.01 до 0.50. По умолчанию установлено значение 0.20.

• index.routing.allocation.total_shards_per_node (Целое число)

Максимальное общее количество первичных и репликационных шардов из одного индекса, которые могут быть распределены на один узел. По умолчанию установлено значение -1 (без ограничений). Помогает контролировать распределение шардов по узлам для каждого индекса, ограничивая количество шардов на узел. Используйте с осторожностью, так как шары из этого индекса могут оставаться нераспределенными, если узлы достигнут своих настроенных лимитов.

• index.routing.allocation.total_primary_shards_per_node (Целое число)

Максимальное количество первичных шардов из одного индекса, которые могут быть распределены на один узел. Эта настройка применима только для кластеров с удаленной поддержкой. По умолчанию установлено значение -1 (без ограничений). Помогает контролировать распределение первичных шардов по узлам для каждого индекса, ограничивая количество первичных шардов на узел. Используйте с осторожностью, так как первичные шары из этого индекса могут оставаться нераспределенными, если узлы достигнут своих настроенных лимитов.

Обновление динамической настройки индекса

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

PUT /testindex/_settings
{
  "index": {
    "refresh_interval": "2s"
  }
}

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

3.9 - Настройки поиска

• search.max_buckets (Динамическое, целое число): Максимальное количество агрегатных бакетов, разрешенных в одном ответе. По умолчанию 65535.

• search.phase_took_enabled (Динамическое, логическое): Включает возврат значений времени на уровне фаз в ответах на поиск. По умолчанию false.

• search.allow_expensive_queries (Динамическое, логическое): Разрешает или запрещает дорогостоящие запросы. Для получения дополнительной информации см. Дорогостоящие запросы.

• search.default_allow_partial_results (Динамическое, логическое): Настройка на уровне кластера, которая позволяет возвращать частичные результаты поиска, если запрос превышает время ожидания или если шард не отвечает. Если запрос на поиск содержит параметр allow_partial_search_results, этот параметр имеет приоритет над данной настройкой. По умолчанию true.

• search.cancel_after_time_interval (Динамическое, единица времени): Настройка на уровне кластера, которая устанавливает значение по умолчанию для таймаута всех запросов на поиск на уровне координирующего узла. После достижения указанного времени запрос останавливается, и все связанные задачи отменяются. По умолчанию -1 (без таймаута).

• search.default_search_timeout (Динамическое, единица времени): Настройка на уровне кластера, которая указывает максимальное время, в течение которого запрос на поиск может выполняться, прежде чем он будет отменен на уровне шарда. Если интервал таймаута указан в запросе на поиск, этот интервал имеет приоритет над настроенной настройкой. По умолчанию -1.

• search.default_keep_alive (Динамическое, единица времени): Указывает значение по умолчанию для поддержания активности для запросов с прокруткой и точкой во времени (PIT). Поскольку запрос может попадать на шард несколько раз (например, во время фаз запроса и извлечения), OpenSearch открывает контекст запроса, который существует на протяжении всего времени запроса, чтобы обеспечить согласованность состояния шарда для каждого отдельного запроса к шард. В стандартном поиске, как только фаза извлечения завершается, контекст запроса закрывается. Для запроса с прокруткой или PIT OpenSearch сохраняет контекст запроса открытым до явного закрытия (или до достижения времени поддержания активности). Фоновый поток периодически проверяет все открытые контексты прокрутки и PIT и удаляет те, которые превысили свой таймаут поддержания активности. Настройка search.keep_alive_interval указывает, как часто контексты проверяются на истечение срока. Настройка search.default_keep_alive является значением по умолчанию для истечения срока. Запрос с прокруткой или PIT может явно указать время поддержания активности, которое имеет приоритет над этой настройкой. По умолчанию 5m.

• search.keep_alive_interval (Статическое, единица времени): Определяет интервал, с которым OpenSearch проверяет контексты запросов, которые превысили свой лимит поддержания активности. По умолчанию 1m.

• search.max_keep_alive (Динамическое, единица времени): Указывает максимальное значение поддержания активности. Настройка max_keep_alive используется в качестве меры безопасности по отношению к другим настройкам поддержания активности (например, default_keep_alive) и настройкам поддержания активности на уровне запроса (для контекстов прокрутки и PIT). Если запрос превышает значение max_keep_alive в любом из случаев, операция завершится неудачей. По умолчанию 24h.

• search.low_level_cancellation (Динамическое, логическое): Включает механизм низкоуровневой отмены запросов. Классический механизм таймаута Lucene проверяет время только во время сбора результатов поиска. Однако дорогостоящий запрос, такой как запрос с подстановочными знаками или префиксами, может занять много времени для расширения перед началом сбора результатов. В этом случае запрос может выполняться в течение времени, превышающего значение таймаута. Механизм низкоуровневой отмены решает эту проблему, устанавливая таймаут не только во время сбора результатов поиска, но и во время фазы расширения запроса или перед выполнением любой операции Lucene. По умолчанию true.

• search.max_open_scroll_context (Динамическое, целое число): Настройка на уровне узла, которая указывает максимальное количество открытых контекстов прокрутки для узла. По умолчанию 500.

• search.request_stats_enabled (Динамическое, логическое): Включает сбор статистики времени фаз на уровне узла с точки зрения координирующего узла. Статистика на уровне запроса отслеживает, сколько времени (всего) запросы на поиск проводят в каждой из различных фаз поиска. Вы можете получить эти счетчики, используя API статистики узлов. По умолчанию false.

• search.highlight.term_vector_multi_value (Статическое, логическое): Указывает на необходимость выделять фрагменты по значениям многозначного поля. По умолчанию true.

• search.max_aggregation_rewrite_filters (Динамическое, целое число): Определяет максимальное количество фильтров переписывания, разрешенных во время агрегации. Установите это значение в 0, чтобы отключить оптимизацию переписывания фильтров для агрегаций. Это экспериментальная функция и может измениться или быть удалена в будущих версиях.

• search.dynamic_pruning.cardinality_aggregation.max_allowed_cardinality (Динамическое, целое число): Определяет порог для применения динамической обрезки в агрегации по кардинальности. Если кардинальность поля превышает этот порог, агрегация возвращается к методу по умолчанию. Это экспериментальная функция и может измениться или быть удалена в будущих версиях.

• search.keyword_index_or_doc_values_enabled (Динамическое, логическое): Определяет, использовать ли индекс или значения документа при выполнении запросов multi_term на полях ключевых слов. Значение по умолчанию - false.

Настройки точки во времени (PIT)

Для получения информации о настройках PIT см. Настройки PIT.

Чтобы узнать больше о статических и динамических настройках, см. Настройка OpenSearch.

3.10 - Настройки плагинов

Настройки плагина оповещений

Для получения информации о настройках оповещений см. Настройки оповещений.

Настройки плагина обнаружения аномалий

Для получения информации о настройках обнаружения аномалий см. Настройки обнаружения аномалий.

Настройки плагина асинхронного поиска

Для получения информации о настройках асинхронного поиска см. Настройки асинхронного поиска.

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

Для получения информации о настройках репликации между кластерами см. Настройки репликации.

Настройки плагина Flow Framework

Для получения информации о настройках автоматического рабочего процесса см. Настройки рабочего процесса.

Настройки плагина геопространственных данных

Для получения информации о настройках процессора IP2Geo плагина геопространственных данных см. Настройки кластера.

Настройки плагина управления индексами

Для получения информации о настройках управления состоянием индекса (ISM) см. Настройки ISM.

Настройки сворачивания индексов

Для получения информации о настройках сворачивания индексов см. Настройки сворачивания индексов.

Настройки плагина планировщика задач

Для получения информации о настройках плагина планировщика задач см. Настройки кластера планировщика задач.

Настройки плагина k-NN

Для получения информации о настройках k-NN см. Настройки k-NN.

Настройки плагина ML Commons

Для получения информации о настройках машинного обучения см. Настройки кластера ML Commons.

Настройки плагина нейронного поиска

Плагин Security Analytics поддерживает следующие настройки:

• plugins.neural_search.hybrid_search_disabled (Динамическое, логическое): Отключает гибридный поиск. По умолчанию false.

Настройки плагина уведомлений

Плагин уведомлений поддерживает следующие настройки. Все настройки в этом списке являются динамическими:

• opensearch.notifications.core.allowed_config_types (Список): Разрешенные типы конфигурации плагина уведомлений. Используйте API GET /_plugins/_notifications/features, чтобы получить значение этой настройки. Типы конфигурации включают slack, chime, microsoft_teams, webhook, email, sns, ses_account, smtp_account и email_group.

• opensearch.notifications.core.email.minimum_header_length (Целое число): Минимальная длина заголовка электронной почты. Используется для проверки общей длины сообщения электронной почты. По умолчанию 160.

• opensearch.notifications.core.email.size_limit (Целое число): Лимит размера электронной почты. Используется для проверки общей длины сообщения электронной почты. По умолчанию 10000000.

• opensearch.notifications.core.http.connection_timeout (Целое число): Таймаут подключения внутреннего HTTP-клиента. Клиент используется для каналов уведомлений на основе вебхуков. По умолчанию 5000.

• opensearch.notifications.core.http.host_deny_list (Список): Список запрещенных хостов. HTTP-клиент не отправляет уведомления на URL вебхуков из этого списка.

• opensearch.notifications.core.http.max_connection_per_route (Целое число): Максимальное количество HTTP-соединений на маршрут внутреннего HTTP-клиента. Клиент используется для каналов уведомлений на основе вебхуков. По умолчанию 20.

• opensearch.notifications.core.http.max_connections (Целое число): Максимальное количество HTTP-соединений внутреннего HTTP-клиента. Клиент используется для каналов уведомлений на основе вебхуков. По умолчанию 60.

• opensearch.notifications.core.http.socket_timeout (Целое число): Конфигурация таймаута сокета внутреннего HTTP-клиента. Клиент используется для каналов уведомлений на основе вебхуков. По умолчанию 50000.

• opensearch.notifications.core.tooltip_support (Логическое): Включает поддержку подсказок для плагина уведомлений. Используйте API GET /_plugins/_notifications/features, чтобы получить значение этой настройки. По умолчанию true.

• opensearch.notifications.general.filter_by_backend_roles (Логическое): Включает фильтрацию по ролям бэкенда (контроль доступа на основе ролей для каналов уведомлений). По умолчанию false.

Настройки плагина Query Insights

Для получения информации о настройках плагина Query Insights см. Функции и настройки Query Insights.

Настройки плагина безопасности

Для получения информации о настройках плагина безопасности см. Настройки безопасности.

Настройки плагина Security Analytics

Для получения информации о настройках аналитики безопасности см. Настройки Security Analytics.

Настройки плагина SQL

Для получения информации о настройках, связанных с SQL и PPL, см. Настройки SQL.

3.11 - Экспериментальные флаги функций

Включение в opensearch.yml

Если вы запускаете кластер OpenSearch и хотите включить флаги функций в конфигурационном файле, добавьте следующую строку в opensearch.yml:

opensearch.experimental.feature.<feature_name>.enabled: true

Включение в контейнерах Docker

Если вы используете Docker, добавьте следующую строку в docker-compose.yml в разделе opensearch-node > environment:

OPENSEARCH_JAVA_OPTS="-Dopensearch.experimental.feature.<feature_name>.enabled=true"

Включение в установке tarball

Чтобы включить флаги функций в установке tarball, укажите новый параметр JVM либо в config/jvm.options, либо в OPENSEARCH_JAVA_OPTS.

Вариант 1: Изменение jvm.options

Добавьте следующие строки в config/jvm.options перед запуском процесса OpenSearch, чтобы включить функцию и ее зависимости:

-Dopensearch.experimental.feature.<feature_name>.enabled=true

Затем запустите OpenSearch:

./bin/opensearch

Вариант 2: Включение с помощью переменной окружения

В качестве альтернативы прямому изменению config/jvm.options, вы можете определить свойства, используя переменную окружения. Это можно сделать с помощью одной команды при запуске OpenSearch или определив переменную с помощью export.

Чтобы добавить флаги функций в строке при запуске OpenSearch, выполните следующую команду:

OPENSEARCH_JAVA_OPTS="-Dopensearch.experimental.feature.<feature_name>.enabled=true" ./opensearch-3.1.0/bin/opensearch

Если вы хотите определить переменную окружения отдельно перед запуском OpenSearch, выполните следующие команды:

export OPENSEARCH_JAVA_OPTS="-Dopensearch.experimental.feature.<feature_name>.enabled=true"
./bin/opensearch

Включение для разработки OpenSearch

Чтобы включить флаги функций для разработки, вы должны добавить правильные свойства в run.gradle перед сборкой OpenSearch. См. Руководство для разработчиков для получения информации о том, как использовать Gradle для сборки OpenSearch.

Добавьте следующие свойства в run.gradle, чтобы включить функцию:

testClusters {
    runTask {
      testDistribution = 'archive'
      if (numZones > 1) numberOfZones = numZones
      if (numNodes > 1) numberOfNodes = numNodes
      systemProperty 'opensearch.experimental.feature.<feature_name>.enabled', 'true'
    }
  }

3.12 - Logs

• В Docker OpenSearch записывает большинство логов в консоль и сохраняет оставшиеся в opensearch/logs/. Установка tarball также использует opensearch/logs/.
• В большинстве установок на Linux OpenSearch записывает логи в /var/log/opensearch/.

Логи доступны в формате .log (обычный текст) и .json. Права доступа к логам OpenSearch по умолчанию составляют -rw-r--r--, что означает, что любой пользователь на узле может их читать. Вы можете изменить это поведение для каждого типа логов в log4j2.properties, используя опцию filePermissions. Например, вы можете добавить appender.rolling.filePermissions = rw-r-----, чтобы изменить права доступа для JSON-сервера логов. Для получения подробной информации см. документацию Log4j 2.

Логи приложений

Для своих логов приложений OpenSearch использует Apache Log4j 2 и его встроенные уровни логирования (от наименее до наиболее серьезных). В следующей таблице описаны настройки логирования.

Вместо изменения уровня логирования по умолчанию (logger.level), вы можете изменить уровень логирования для отдельных модулей OpenSearch:

PUT /_cluster/settings
{
  "persistent" : {
    "logger.org.opensearch.index.reindex" : "DEBUG"
  }
}

Самый простой способ идентифицировать модули — не по логам, которые сокращают путь (например, o.o.i.r), а по исходному коду OpenSearch.

После этого изменения OpenSearch будет генерировать гораздо более подробные логи во время операций повторной индексации:

[2019-10-18T16:52:51,184][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: starting
[2019-10-18T16:52:51,186][DEBUG][o.o.i.r.TransportReindexAction] [node1] executing initial scroll against [some-index]
[2019-10-18T16:52:51,291][DEBUG][o.o.i.r.TransportReindexAction] [node1] scroll returned [3] documents with a scroll id of [DXF1Z==]
[2019-10-18T16:52:51,292][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: got scroll response with [3] hits
[2019-10-18T16:52:51,294][DEBUG][o.o.i.r.WorkerBulkByScrollTaskState] [node1] [1626]: preparing bulk request for [0s]
[2019-10-18T16:52:51,297][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: preparing bulk request
[2019-10-18T16:52:51,299][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: sending [3] entry, [222b] bulk request
[2019-10-18T16:52:51,310][INFO ][o.e.c.m.MetaDataMappingService] [node1] [some-new-index/R-j3adc6QTmEAEb-eAie9g] create_mapping [_doc]
[2019-10-18T16:52:51,383][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: got scroll response with [0] hits
[2019-10-18T16:52:51,384][DEBUG][o.o.i.r.WorkerBulkByScrollTaskState] [node1] [1626]: preparing bulk request for [0s]
[2019-10-18T16:52:51,385][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: preparing bulk request
[2019-10-18T16:52:51,386][DEBUG][o.o.i.r.TransportReindexAction] [node1] [1626]: finishing without any catastrophic failures
[2019-10-18T16:52:51,395][DEBUG][o.o.i.r.TransportReindexAction] [node1] Freed [1] contexts

Уровни DEBUG и TRACE являются чрезвычайно подробными. Если вы включаете один из них для устранения проблемы, отключите его после завершения.

Существуют и другие способы изменения уровней логирования:

1. Добавление строк в opensearch.yml

logger.org.opensearch.index.reindex: debug

Изменение opensearch.yml имеет смысл, если вы хотите повторно использовать свою конфигурацию логирования для нескольких кластеров или отлаживать проблемы запуска с одним узлом.

2. Изменение log4j2.properties

# Определите новый логгер с уникальным ID для повторной индексации
logger.reindex.name = org.opensearch.index.reindex
# Установите уровень логирования для этого ID
logger.reindex.level = debug

Этот подход является чрезвычайно гибким, но требует знакомства с синтаксисом файла свойств Log4j 2. В общем, другие варианты предлагают более простую конфигурацию.

Если вы изучите файл log4j2.properties по умолчанию в каталоге конфигурации, вы увидите несколько специфичных для OpenSearch переменных:

appender.console.layout.pattern = [%d{ISO8601}][%-5p][%-25c{1.}] [%node_name]%marker %m%n
appender.rolling_old.fileName = ${sys:opensearch.logs.base_path}${sys:file.separator}${sys:opensearch.logs.cluster_name}.log

• ${sys:opensearch.logs.base_path} — это каталог для логов (например, /var/log/opensearch/).
• ${sys:opensearch.logs.cluster_name} — это имя кластера.
• ${sys:opensearch.logs.node_name} — это имя узла.
• [%node_name] — это имя узла.

Медленные логи запросов поиска

Новая функция в версии 2.12, OpenSearch предлагает медленные логи на уровне запросов для поиска. Эти логи основываются на пороговых значениях, чтобы определить, что квалифицируется как “медленно”. Все запросы, которые превышают порог, записываются в логи.

Медленные логи запросов поиска включаются динамически через API настроек кластера. В отличие от медленных логов шардов, пороги медленных логов запросов поиска настраиваются для общего времени выполнения запроса. По умолчанию логи отключены (все пороги установлены на -1).

PUT /_cluster/settings
{
  "persistent" : {
      "cluster.search.request.slowlog.level" : "TRACE",
      "cluster.search.request.slowlog.threshold.warn": "10s",
      "cluster.search.request.slowlog.threshold.info": "5s",
      "cluster.search.request.slowlog.threshold.debug": "2s",
      "cluster.search.request.slowlog.threshold.trace": "10ms"
  }
}

Строка из opensearch_index_search_slowlog.log может выглядеть следующим образом:

[2023-10-30T15:47:42,630][TRACE][c.s.r.slowlog] [runTask-0] took[80.8ms], took_millis[80], phase_took_millis[{expand=0, query=39, fetch=22}], total_hits[4 hits], search_type[QUERY_THEN_FETCH], shards[{total: 10, successful: 10, skipped: 0, failed: 0}], source[{"query":{"match_all":{"boost":1.0}}}], id[]

Медленные логи запросов поиска могут занимать значительное место на диске и влиять на производительность, если вы установите низкие пороговые значения. Рассмотрите возможность временного включения их для устранения неполадок или настройки производительности. Чтобы отключить медленные логи запросов поиска, верните все пороги к -1.

Медленные логи шардов

OpenSearch имеет два типа медленных логов шардов, которые помогают выявлять проблемы с производительностью: медленный лог поиска и медленный лог индексации.

Эти логи основываются на пороговых значениях, чтобы определить, что квалифицируется как “медленный” поиск или “медленная” операция индексации. Например, вы можете решить, что запрос считается медленным, если его выполнение занимает более 15 секунд. В отличие от логов приложений, которые настраиваются для модулей, медленные логи настраиваются для индексов. По умолчанию оба лога отключены (все пороги установлены на -1).

В отличие от медленных логов запросов поиска, пороги медленных логов шардов настраиваются для времени выполнения отдельных шардов.

GET <some-index>/_settings?include_defaults=true
{
  "indexing": {
    "slowlog": {
      "reformat": "true",
      "threshold": {
        "index": {
          "warn": "-1",
          "trace": "-1",
          "debug": "-1",
          "info": "-1"
        }
      },
      "source": "1000",
      "level": "TRACE"
    }
  },
  "search": {
    "slowlog": {
      "level": "TRACE",
      "threshold": {
        "fetch": {
          "warn": "-1",
          "trace": "-1",
          "debug": "-1",
          "info": "-1"
        },
        "query": {
          "warn": "-1",
          "trace": "-1",
          "debug": "-1",
          "info": "-1"
        }
      }
    }
  }
}

Чтобы включить эти логи, увеличьте один или несколько порогов:

PUT <some-index>/_settings
{
  "indexing": {
    "slowlog": {
      "threshold": {
        "index": {
          "warn": "15s",
          "trace": "750ms",
          "debug": "3s",
          "info": "10s"
        }
      },
      "source": "500",
      "level": "INFO"
    }
  }
}

Пример настройки медленных логов индексации

В этом примере OpenSearch записывает операции индексации, которые занимают 15 секунд или дольше, на уровне WARN, а операции, которые занимают от 10 до 14.x секунд, на уровне INFO. Если вы установите порог в 0 секунд, OpenSearch будет записывать все операции, что может быть полезно для проверки, действительно ли медленные логи включены.

• reformat указывает, следует ли записывать поле _source документа в одной строке (true) или позволить ему занимать несколько строк (false).
• source — это количество символов поля _source документа, которые нужно записать.
• level — это минимальный уровень логирования, который следует включить.

Строка из opensearch_index_indexing_slowlog.log может выглядеть следующим образом:

node1 | [2019-10-24T19:48:51,012][WARN][i.i.s.index] [node1] [some-index/i86iF5kyTyy-PS8zrdDeAA] took[3.4ms], took_millis[3], type[_doc], id[1], routing[], source[{"title":"Your Name", "Director":"Makoto Shinkai"}]

Медленные логи шардов могут занимать значительное место на диске и влиять на производительность, если вы установите низкие пороговые значения. Рассмотрите возможность временного включения их для устранения неполадок или настройки производительности. Чтобы отключить медленные логи шардов, верните все пороги к -1.

Журналы задач

OpenSearch может записывать время ЦП и использование памяти для N самых затратных по памяти поисковых задач, когда включены потребители ресурсов задач. По умолчанию потребители ресурсов задач будут записывать 10 самых затратных поисковых задач с интервалом в 60 секунд. Эти значения можно настроить в файле opensearch.yml.

Запись задач включается динамически через API настроек кластера:

PUT _cluster/settings
{
  "persistent" : {
    "task_resource_consumers.enabled" : "true"
  }
}

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

После включения журналы будут записываться в файлы logs/opensearch_task_detailslog.json и logs/opensearch_task_detailslog.log.

Чтобы настроить интервал записи и количество записываемых поисковых задач, добавьте следующие строки в opensearch.yml:

# Количество затратных поисковых задач для записи
cluster.task.consumers.top_n.size: 100

# Интервал записи
cluster.task.consumers.top_n.frequency: 30s

Журналы устаревания

Журналы устаревания фиксируют, когда клиенты делают устаревшие вызовы API к вашему кластеру. Эти журналы могут помочь вам выявить и исправить проблемы до обновления до новой основной версии. По умолчанию OpenSearch записывает устаревшие вызовы API на уровне WARN, что хорошо подходит для почти всех случаев использования. При необходимости настройте logger.deprecation.level, используя _cluster/settings, opensearch.yml или log4j2.properties.

4 - Сравнение ОС

Совместимость OpenSearch и OpenSearch Dashboards

OpenSearch и OpenSearch Dashboards совместимы с Red Hat Enterprise Linux (RHEL) и дистрибутивами Linux на базе Debian, которые используют systemd, такими как Amazon Linux и Ubuntu Long-Term Support (LTS). Хотя OpenSearch и OpenSearch Dashboards должны работать на большинстве дистрибутивов Linux, мы тестируем только подмножество из них.

Поддерживаемые операционные системы

Следующая таблица перечисляет версии операционных систем, которые мы в настоящее время тестируем:

Журнал изменений

Следующая таблица перечисляет изменения, внесенные в совместимость операционных систем.

5 - Настройка OpenSearch Dashboards

OpenSearch Dashboards использует файл конфигурации opensearch_dashboards.yml для чтения настроек при запуске кластера. Вы можете найти opensearch_dashboards.yml по следующему пути: /usr/share/opensearch-dashboards/config/opensearch_dashboards.yml (Docker) или /etc/opensearch-dashboards/opensearch_dashboards.yml (большинство дистрибутивов Linux) на каждом узле.

Для получения информации о настройках OpenSearch Dashboards ознакомьтесь с образцом файла opensearch_dashboards.yml.

6 - Upgrading OpenSearch

Проект OpenSearch регулярно выпускает обновления, которые включают новые функции, улучшения и исправления ошибок. OpenSearch использует семантическое версионирование, что означает, что разрушающие изменения вводятся только между основными версиями. Чтобы узнать о предстоящих функциях и исправлениях, ознакомьтесь с дорожной картой проекта OpenSearch на GitHub. Чтобы просмотреть список предыдущих релизов или узнать больше о том, как OpenSearch использует версионирование, смотрите раздел “График релизов и политика обслуживания”.

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

Если вы хотите, чтобы был добавлен конкретный процесс или хотите внести свой вклад, создайте задачу на GitHub. Ознакомьтесь с Руководством для участников, чтобы узнать, как вы можете помочь.

Учет рабочих процессов

Потратьте время на планирование процесса перед внесением каких-либо изменений в ваш кластер. Например, рассмотрите следующие вопросы:

• Сколько времени займет процесс обновления?
• Если ваш кластер используется в производственной среде, насколько критично время простоя?
• У вас есть инфраструктура для развертывания нового кластера в тестовой или разработческой среде перед его переводом в эксплуатацию, или вам нужно обновить производственные узлы напрямую?

Ответы на такие вопросы помогут вам определить, какой путь обновления будет наиболее подходящим для вашей среды.

Минимально вы должны:

• Ознакомиться с разрушающими изменениями.
• Ознакомиться с матрицами совместимости инструментов OpenSearch.
• Ознакомиться с совместимостью плагинов.
• Создать резервные копии файлов конфигурации.
• Создать снимок.

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