Opensearch что это
Перейти к содержимому

Opensearch что это

  • автор:

OpenSearch

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

OpenSearch был разработан A9, дочерней компанией Amazon.com. Первая версия, OpenSearch 1.0, была представлена на конференции, посвященной Web 2.0 в марте 2005 года. Черновые версии OpenSearch 1.1 были опубликованы в сентябре и декабре 2005 года. Спецификация OpenSearch лицензирована компанией A9 по Creative Commons Attribution-ShareAlike 2.5 License. [1]

Архитектура

В OpenSearch входят:

  • XML-файлы с описанием поисковой системы.
  • Стандартизованный синтаксис запросов, описывающий, где и как получать результаты поиска.
  • RSS (в OpenSearch 1.0) или более общий OpenSearch-ответ (в OpenSearch 1.1) — форматы, предоставляющие поисковые результаты.
  • OpenSearch-агрегаторы — сайты, позволяющие отображать OpenSearch-результаты.
  • Элементы на веб-странице для автоматического обнаружения пользовательским клиентом возможности использования OpenSearch на данном сайте.

Версия 1.0 спецификации позволяла предоставлять результаты поисковых запросов только в формате RSS, в то время как версия 1.1 позволяет использовать. RSS и Atom — единственные форматы, формально поддерживаемые OpenSearch-агрегаторами, но и другие типы вполне допустимы, например, HTML.

Поисковые системы и ПО, поддерживающие OpenSearch

  • Википедия предлагает статьи, соответствующие введённой строке.
  • Mozilla Firefox версии 2 и выше позволяет интегрировать поисковые системы, поддерживающие OpenSearch, со своей панелью поиска.
  • Internet Explorer версии 7 и выше также позволяет добавлять OpenSearch-системы
  • Chrome также позволяет добавлять OpenSearch-системы для быстрого поиска по сайту через адресную строку

Примечания

  1. ↑Ogbuji, Uche. Introducing OpenSearch, xml.com (24 июля 2007).

Ссылки

  • OpenSearch.org — официальный сайт и спецификации.
  • Поисковая оптимизация

Opensearch что это

Все, конечно, пользуются окошком мгновенного поиска в браузере, но не все замечают, что на некоторых сайтах кнопка выбора провайдера поиска меняет вид. Например, в Firefox на кнопке появляется «синее свечение». Это свечение означает, что просматриваемый сайт предоставляет возможность поиска и может быть добавлен в список поисковых плагинов. Фактически, любой сайт, на котором реализован полнотекстовый поиск, может стать таким провайдером для современных браузеров. Эта возможность реализована с использованием технологии OpenSearch.

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

1) Создать XML-файл с описанием параметров поиска — OpenSearch Description. Обычно этот файл называется OpenSearch.xml и находится в корне сайта. Содержимое файла примерно следующее:

  Имя сайта 1 Описание сайта как провайдера поиска UTF-8 http://site.com/favicon.png 2  3

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

  • 1 — Заданное имя сайта отображается в качестве имени поискового плагина браузерами.
  • 2 — Задается иконка поискового плагина.
  • 3 — Центральная часть файла. Здесь задается URL, на который нужно отправить запрос для получения результатов поиска. В реальном запросе плейсхолдер заменяется на поисковой запрос пользователя.

2) Следующим пунктом нужно указать в разметке сайта, что ресурс поддерживает спецификацию OpenSearch. Для этого в раздел head нужно вставить элемент:

  • Адрес ранее созданного файла opensearch.xml
  • Заголовок (title), который используется браузером для формирования пункта меню добавления провайдера (например в Firefox: Добавить «Имя Сайта»)

Указанной информации вполне достаточно, чтобы поиск по сайту стал доступным из окошка мгновенного поиска. Однако, спецификация OpenSearch гораздо более обширна и поддерживает множество дополнительных возможностей. Можно дополнительно прочитать:

  • OpenSearch в википедии;
  • Полное описание спецификации OpenSearch (англ.).

Инструкция по применению OpenSearch: первые шаги по установке и настройке

OpenSearch является продуктом реакции на не давнее изменение условий лицензирования Elasticsearch и прекращения работы в качестве open-source платформы. AWS, Logz.io и ряд других компаний-партнеров в течение нескольких месяцев работали над созданием не просто функциональной замены Elasticsearch, а самостоятельным и перспективным проектом.

После разделения Elasticsearch и Kibana 7.10.2, версия RC1 (1.0.00 OpenSearch и OpenSearch, выпущенных 7 июня 2021 г. RC1 не считается полностью готовой к эксплуатации, но она функциональна и включает в себя все прежние Open Distro плагины (наряду с несколькими новыми), Docker-образы, команды Linux tars, оповещения и возможность визуализации диаграмм Ганта (что изначально не входило в ELK стек).

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

Установка OpenSearch

Сначала вам нужно будет загрузить OpenSearch для Docker (убедитесь, что Docker Compose уже имеется на вашем устройстве).

Запустите терминал на Mac или Linux. Скачайте Docker-образы для 1) OpenSearch и 2) дашборда OpenSearch (эквивалент Kibana).

docker pull opensearchproject/opensearch:1.0.0-rc1
docker pull opensearchproject/opensearch-dashboards:1.0.0-rc1

Чтобы перейти к следующему шагу, вы должны убедиться, что либо удалили Elasticsearch, либо деактивировали его. Это связано с тем, что OpenSearch по умолчанию работает на том же порту, что и Elasticsearch – 9200. Конфликт портов может помешать дальнейшей работе. То же самое касается дашбордов OpenSearch и Kibana; оба по умолчанию используют порт 5601.

Далее запустите образ:

docker run -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" opensearchproject/opensearch:1.0.0-rc1

Вы должны получить сообщение подобного вида:

[2021-06-28T10:19:29,483][INFO ][o.o.s.c.ConfigurationRepository] [71235t674gby] Node ‘71235t674gby’ initialized [2021-06-28T10:20:27,525][INFO ][o.o.i.i.ManagedIndexCoordinator] [71235t674gby] Performing move cluster state metadata.

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

curl -XGET https://localhost:9200 -u 'admin:admin' --insecure

Что должно привести к чему-то подобному:

Чтобы развернуть Node-приложения, создайте новый файл docker-compose.yml. Вы можете использовать шаблон OpenSearch docker-compose.yml template. Сохраните файл в удобном для вас месте. Я создал свой собственный каталог/директорию для файлов docker-compose и отдельную поддиректорию для каждого проекта отдельно взятого yml-файла, в котором он будет жить. Такой шаблон доступен в документах OpenSearch:

version: '3' 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_master_nodes=opensearch-node1,opensearch-node2 - bootstrap.memory_lock=true # along with the memlock settings below, disables swapping - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems hard: 65536 volumes: - opensearch-data1:/usr/share/opensearch/data #- ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml ports: - 9200:9200 - 9600:9600 # required for Performance Analyzer networks: - opensearch-net 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_master_nodes=opensearch-node1,opensearch-node2 - bootstrap.memory_lock=true - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - opensearch-data2:/usr/share/opensearch/data #- ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml networks: - opensearch-net opensearch-dashboards: image: opensearchproject/opensearch-dashboards:latest container_name: opensearch-dashboards ports: - 5601:5601 expose: - "5601" environment: OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' #volumes: #- ./custom-opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml networks: - opensearch-net

Этот образец демонстрирует нам возможность создания самого маленького “кластера” – всего два узла (Nodes) (конечно, технически один узел уже является кластером, но опустим лишние споры). Он также имеет один контейнер для запуска дашбордов OpenSearch (опять же, на порту 5601).

В завершение, запустите docker-compose для старта OpenSearch:

docker-compose up

Настройка OpenSearch

Для настройки OpenSearch требуется отдельный файл yaml/yml: opensearch.yml. Вы можете либо 1) создать этот файл с помощью -v command, либо 2) в файле docker-compose.yml, упомянутом выше.

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

Вариант 2 (в файле docker-compose.yml; вам нужно будет настроить это для каждого узла): Option 2 (within the docker-compose.yml file; you will have to configure this for each node):

version: '3' 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_master_nodes=opensearch-node1,opensearch-node2 - bootstrap.memory_lock=true # along with the memlock settings below, disables swapping - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 # maximum number of open files for the OpenSearch user, set to at least 65536 on modern systems hard: 65536 volumes: - opensearch-data1:/usr/share/opensearch/data #- ./custom-opensearch.yml:/usr/share/opensearch/config/opensearch.yml

Чтобы настроить дашборды OpenSearch таким же образом, следуйте следующим инструкциям:

opensearch-dashboards: image: opensearchproject/opensearch-dashboards:latest container_name: opensearch-dashboards ports: - 5601:5601 expose: - "5601" environment: OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' #volumes: #- ./custom-opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml networks: - opensearch-net

Плагины

OpenSearch имеет встроенные плагины, которые являются продолжением открытого дистрибутива Open Distro (который изначально создавал уникальные плагины для ассимиляции с сервисом Elasticsearch, а теперь адаптирован для работы с OpenSearch). Кстати говоря, вы можете – и должны – ознакомиться с постом Амитая Стерна о создании плагинов Opensearch.

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

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

FROM opensearchproject/opensearch:1.0.0-rc1
RUN /usr/share/opensearch/bin/opensearch-plugin install --batch
docker build --tag=opensearch-custom-plugin
docker run -p 9200:9200 -p 9600:9600 -v /usr/share/opensearch/data opensearch-custom-plugin

Дальнейшие шаги

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

  • Блог компании Nixys
  • Системное администрирование
  • IT-инфраструктура
  • DevOps

Проект «Кластер Opensearch для централизованного хранения логов»

В конце курса «SRE практики и инструменты » студентов ждёт выполнение проекта. Это самостоятельная работа, необходимая для закрепления полученных знаний. Предлагаем вашему вниманию проект Максима Чудинова, одного из выпускников курса.

Целью проекта было автоматизировать развертывание кластеров Opensearch на виртуальных машинах с Ubuntu 20.04 в инфраструктуре Cloud.ru. Конфигурация всех кластеров должна быть описана в одном месте, чтобы можно было разворачивать/обновлять/изменять кластеры коммитом в одном репозитории.

На момент начала проекта в августе 2023 года у меня уже было 18 кластеров Elasticsearch, о которых я рассказывал весной на Big Monitoring Meetup 9 https://monhouse.tech/big-monitoring-meetup-9/ . Все кластеры на устаревшей версии 7.9. По сумме всех обстоятельств, препятствующих переходу на более свежую версию, было принято решение заменить Elasticsearch на Opensearch.

Кратко о продукте. Opensearch — это форк Elasticsearch 7.10. Поэтому особых отличий в работе кластера нет. Для пробы можно поднять одно-нодовый кластер. Но лучше сразу разворачивать рекомендованную производителем конфигурацию от трёх нод. Кластер это только хранилище данных. Дополнительно к нему будут полезны фронтенд и коллекторы. Фронтенд нужен пользователям для удобного поиска по индексам. Коллекторы пригодятся при необходимости предобработки или в распределенной инфраструктуре.

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

Чтобы развернуть 18 однотипных кластера сейчас, N-е количество в будущем и дальше их поддерживать, я решил использовать Ansible. Для нод написал роль opensearch, для фронтенда роль opensearch_dashboards. В соседнем репозитории https://gitlab.com/max-ch-88/opensearch_cluster подготовлено описание кластеров.

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

В проде мы используем параметр ansible_host в инвентаре по причине отсутствия DNS в некоторых сегментах. С molecule в контейнерах такой возможности нет. А нужно для конфигурации каждой ноды собрать массив IP-адресов всех нод. Чтобы роли работали и в тесте, и на виртуальных машинах, я написал код с формированием списка хостов в зависимости от существования значения ansible_host. Я не смог реализовать это нативными командами ansible и сделал в синтаксисе jinja2.

Основой для применения ролей служит инвентарь. Он описан вместе с плейбуком кластера в файле inventory/hosts и содержит только имена и адреса целевых машин. Роли же применяются к группам, которые описаны в файле inventory/logsearch.yml.

Соответственно, для нод это группа logsearch_node, для фронта logsearch_frontend и группа logsearch_logstash заложена на перспективу использования инвентаря для коллектора logstash.

Общие сертификаты безопасности вынесены в групповые переменные. В будущем будут перенесены в корпоративный Vault.

В отдельном файле в словаре clusters описаны параметры каждого кластера. Поле type на перспективу развертывания и opensearch, и elasticsearch. Сертификаты берутся из общих переменных. Но могут быть определены свои для каждого кластера. И в виде plain text описаны куски для конфигурационных файлов internal_users.yml и roles_mapping.yml.

Все зависимости сведены в requirements.yml. Средствами Gitlab CI/CD настроено выполнение плейбука при коммите в основную ветку изменений репозитория.

Архитекторы определили для кластера SLA в 97%. Для себя я установил SLO в 98%. С помощью ресурса uptime.is проценты превращаются в допустимые периоды простоя

Daily: 28m 48s

Weekly: 3h 21m 36s

Monthly: 14h 29m 23s

Quarterly: 1d 19h 28m 8.8s

Yearly: 7d 5h 52m 35s

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

Но эта стабильность не отменяет обязательного мониторинга. Я определил несколько ключевых метрик (SLI):

  • Health status – доступность кластера и его способность принимать новые данные;
    • Indexing rate – скорость поступления событий;
    • Indexing latency – задержка записи событий;
    • Failed get operations – ошибки поисковых запросов;
    • Storage utilization – величина использования хранилища кластера;
    • Product Index size – размер индексов каждого продукта источника;
    • Estimated time to 15% free space – прогнозное время до достижения 15% остатка хранилища.

    Для сбора метрик используется Zabbix и немного доработанный шаблон Elasticsearch https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/app/elasticsearch_http?at=refs%2Fheads%2Frelease%2F5.0 . Визуализация средствами Grafana. Применив шаблонное наименование хостов (naming convention), получилось сделать такой динамический шаблон, отображающий SLI по каждому кластеру. Прогнозная метрика позволила организовать capacity management.

    По размерам индексов продуктов сделан фрейм с Top 10 и графиками изменения. Продукты – это системы или комплексы, например, корпоративный кластер Confluence или Gitlab, или кластер K8s для облачных сервисов. Продукт включает в себя множество источников событий. И каждый может в любой момент значительно увеличить количество генерируемых событий.

    Мы не применяем жёстких ограничений и не фильтруем события. Потому что так можно потерять действительно важные данные. Что отправляется в хранилище, решает команда каждого продукта. Но хранилище не бесконечное. И чтобы понимать, какой же продукт и сколько места занимает в хранилище кластера, был реализован такой Logging budget – события от каждого продукта складываются в отдельный индекс и выполняется подсчет занимаемого места в байтах. При резком росте значения команда-владелец разбирается в причинах.

    Дальнейшим развитием проекта будет перенесение всех секретов и сертификатов в Vault, разработка и подключение роли logstash, сбор логов всех элементов проекта в один индекс и настройка предупреждений по аварийным событиям. Также предстоит договориться с командами разработки внутренних продуктов о формате событий приложений (contract), чтобы не вызывать ошибок несовпадения типов данных при индексировании.

    Хотите знать об SRE больше? Добро пожаловать на специализированный курс в Otus !

    Похожие публикации:
    1. Flex 1 1 auto что это
    2. Warning lf will be replaced by crlf in что это
    3. Xdg desktop portal что это
    4. Как сделать картинку резиновой

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *