Централизованное логирование: Часть 3 — OpenSearch

OpenSearch — открытая система поиска и анализа данных, которую чаще всего используют для централизованного хранения логов. Это форк Elasticsearch и Kibana: в 2021 году, после того как Elastic сменила лицензию на SSPL и Elastic License, Amazon Web Services создала OpenSearch на основе последних версий под Apache 2.0 — Elasticsearch 7.10.2 и Kibana 7.10.2.

С 16 сентября 2024 года проектом управляет OpenSearch Software Foundation в составе Linux Foundation. Основатели фонда — AWS, SAP и Uber; до этого проект развивался под руководством AWS. Лицензия осталась прежней — Apache 2.0.

Компоненты

• OpenSearch — хранилище и поисковый движок: индексы, полнотекстовый поиск, агрегации, кластер из нескольких узлов.
• OpenSearch Dashboards — веб-интерфейс для поиска, визуализации, дашбордов и управления.
• Плагины, которые входят в стандартную поставку: безопасность (пользователи, роли, TLS, журнал аудита), оповещения (Alerting), обнаружение аномалий, SQL и PPL, управление жизненным циклом индексов (ISM).

Главное практическое отличие от Elastic Stack — всё перечисленное доступно бесплатно, без отдельной подписки.

Версии

В апреле 2025 года вышла OpenSearch 3.0 — первый мажорный выпуск за три года и первый под управлением фонда. С тех пор выходят выпуски ветки 3.x. Ветку 1.x уже не стоит использовать для новых установок: её прекращают поддерживать и сторонние продукты, например Graylog.

Чем отправлять логи

Здесь основное отличие от ELK, о котором легко забыть. Агенты Elastic последних версий с OpenSearch не работают: по документации OpenSearch, Beats новее 7.12.x не поддерживаются. Клиентам версий 7.x–7.12.x, которые проверяют версию сервера, нужно включить в OpenSearch режим совместимости. Поэтому для новых установок используют другие инструменты:

• Data Prepper — собственный инструмент проекта для приёма, обработки и маршрутизации данных. Документация OpenSearch называет его предпочтительным способом загрузки данных. Типичная схема: Fluent Bit на серверах отправляет логи в Data Prepper по HTTP, тот разбирает строки процессором grok и записывает результат в OpenSearch.
• Fluent Bit — лёгкий агент с встроенным выходом opensearch: отправляет записи пакетами через _bulk API, поддерживает TLS.
• Logstash с плагином вывода logstash-output-opensearch — если Logstash уже используется и переписывать конвейеры не хочется. Частая схема при переезде с ELK: Filebeat остаётся на серверах, а Logstash с плагином OpenSearch служит мостом.

Минимальный выход Fluent Bit в классическом формате конфигурации:

[OUTPUT]
    Name        opensearch
    Match       *
    Host        opensearch.internal
    Port        9200
    HTTP_User   fluentbit
    HTTP_Passwd ${OPENSEARCH_PASSWORD}
    tls         On
    Index       logs
    Suppress_Type_Name On

Параметр Suppress_Type_Name нужен для OpenSearch 2.x и новее: в них поле _type в запросах больше не используется.

Языки запросов

Помимо запросов DSL, унаследованных от Elasticsearch, в OpenSearch есть два языка, удобных для работы с логами:

• SQL — привычные запросы SELECT … FROM … WHERE;
• PPL (Piped Processing Language) — цепочка команд через вертикальную черту:

source = logs-*
| where level = 'error'
| stats count() by service

Запрос считает ошибки по сервисам. PPL — язык именно OpenSearch; у Elasticsearch свой язык с похожей идеей — ES|QL.

Сроки хранения: ISM

Индексами логов управляет Index State Management (ISM). Политика описывает состояния индекса и переходы между ними: индекс живёт в состоянии hot, по достижении возраста или размера переходит дальше и в итоге удаляется. Пример политики из документации: индекс удаляется через 30 дней.

PUT _plugins/_ism/policies/logs-30d
{
  "policy": {
    "description": "Удаление логов через 30 дней",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "30d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [ { "delete": {} } ]
      }
    ]
  }
}

По смыслу ISM соответствует ILM в Elasticsearch, но синтаксис политик другой: при переезде политики приходится переписывать.

Установка

Официальные образы — opensearchproject/opensearch и opensearchproject/opensearch-dashboards. С версии 2.12 при первом запуске обязательно задать пароль администратора в переменной OPENSEARCH_INITIAL_ADMIN_PASSWORD; без него контейнер не запустится. Для одного узла указывается discovery.type=single-node. Для рабочей среды документация описывает кластер из нескольких узлов в Docker Compose, установку из пакетов и Helm-чарты для Kubernetes.

Как и Elasticsearch, OpenSearch требует увеличить на хосте параметр ядра vm.max_map_count и выделить достаточно памяти под JVM.

Достоинства

• Открытая лицензия Apache 2.0 и управление через независимый фонд.
• Безопасность и оповещения бесплатно — без подписки.
• Совместимость API с Elasticsearch 7.10: многие инструменты и запросы переносятся без изменений.
• SQL и PPL — порог входа ниже, чем у DSL.

Недостатки

• Ресурсы. Требования к памяти, процессору и дискам — того же порядка, что у Elasticsearch.
• Расхождение с Elastic. С 2021 года проекты развиваются отдельно: новые функции Elastic в OpenSearch не появляются, интеграции и агенты Elastic с ним не работают.
• Обслуживание кластера — шарды, политики, обновления, снимки — ложится на вас.

Типичные ошибки

• Filebeat последней версии напрямую в OpenSearch. Соединение не устанавливается или ломается после обновления агента. Нужны Fluent Bit, Data Prepper или Logstash с плагином.
• Отключённый плагин безопасности. В примерах из интернета его часто выключают ради простоты, а потом так и оставляют в рабочей среде.
• Нет политики ISM. Индексы копятся, пока не кончится место.
• Один узел без снимков. Резервные копии делаются через snapshot в отдельный репозиторий, например в S3-совместимое хранилище.

Когда выбирать OpenSearch

OpenSearch подходит тем, кому нужны возможности уровня ELK — полнотекстовый поиск, дашборды, оповещения, разграничение доступа — под открытой лицензией и без платной подписки. Если вы уже работаете с Elastic Stack и используете Elastic Agent и готовые интеграции, переезд потребует замены агентов и политик хранения; это стоит учесть заранее.