Архитектура OpenSearch Dashboards (OSD) — практический обзор

Этот документ описывает логическую архитектуру OpenSearch Dashboards (OSD), его место в экосистеме OpenSearch и типовые потоки данных/аутентификации. Материал ориентирован на администраторов и инженеров эксплуатации.

OSD — это веб‑интерфейс для визуализации и анализа данных в кластере OpenSearch. Сам по себе он **без состояния** (stateless) — все артефакты (визуализации, дашборды, index patterns / data views и т. д.) хранятся в индексе в OpenSearch.

—

• Клиентский UI (React) для Discover/Visualize/Dashboards и плагинов (Observability, Security, Reports и др.).
  - Прокси‑слой к OpenSearch API: OSD не ходит напрямую в data‑узлы, а отправляет запросы на opensearch.hosts (обычно координатор/ingest‑узлы или LB перед ними).
  - Механизм сохранённых объектов (Saved Objects) — хранит метаданные UI в специальном системном индексе (в дистрибуциях встречаются названия .kibana_* или .opensearch-dashboards* — зависит от версии/миграций).
  - Интеграция с плагином безопасности OpenSearch (RBAC, многоарендность/тенанты, SSO по OIDC/SAML/LDAP).

snippet.mermaid

flowchart LR
  subgraph Users["Пользователи/браузеры"]
    U1[User A]
    U2[User B]
  end
 
  subgraph Edge["Балансировщик / Reverse Proxy"]
    LB[(LB: 5601/tcp)]
  end
 
  subgraph OSD["OSD-узлы (stateless)"]
    D1[OpenSearch Dashboards #1]
    D2[OpenSearch Dashboards #2]
  end
 
  subgraph OS["Кластер OpenSearch"]
    CM[(Cluster Manager)]
    C1[(Data/ingest)]
    C2[(Data/ingest)]
  end
 
  subgraph Ingest["Слой приёма логов"]
    FB[Fluent Bit / Filebeat]
    LS[Logstash]
  end
 
  U1 -- HTTP(S) --> LB --> D1
  U2 -- HTTP(S) --> LB --> D2
  D1 -- HTTPS (9200) --> OS
  D2 -- HTTPS (9200) --> OS
  FB -- 5044/HTTP(S) --> LS -- HTTPS (9200) --> OS

Порты по умолчанию - OSD слушает 5601/tcp (HTTP по умолчанию).
- OpenSearch API — 9200/tcp (HTTPS при включённой безопасности).
- Logstash (beats input) — 5044/tcp (если используется).

• Node.js‑сервер OSD

  1. Прокси к OpenSearch, управление сессиями, загрузка плагинов.
     - Логи по умолчанию в stdout; можно направить в файл.
     - Платформа плагинов
     - Плагины UI/серверной части расширяют функционал: Observability (логи/трейсы/метрики), Security (RBAC, Tenants), Anomaly Detection/ML, Reports, Alerting, Index Management/ISM и др.
     - Saved Objects
     - Хранятся в системном индексе в кластере.
     - Многоарендность (tenancy): артефакты разделяются по тенантам (Global, Private и настраиваемые).
     - Data Views (бывш. Index Patterns)
     - Мост между UI и индексами/шаблонами в OpenSearch.
     - Определяет поле времени, wildcards по индексам (logs-*, filebeat-*, fluentbit-*).

  ---

• Кто аутентифицирует? — плагин безопасности в OpenSearch. OSD передаёт ему учётные данные (Basic, OIDC/SAML, LDAP).
  - Сервисный пользователь OSD (kibanaserver или аналог) — для фоновых операций OSD; не путать с пользовательскими сессиями.
  - Многоарендность (Tenants) — логическое разделение артефактов UI: приватные/глобальные/командные области.
  - Роли и маппинги — разрешения на индексы (read, crud, create_index и т. п.) + доступ к функциональности плагинов.
  Типичный поток аутентификации 1. Пользователь открывает http(s)://osd:5601 → OSD редиректит на страницу логина (или в IdP при SSO).
  2. После успешного логина OSD хранит информацию о сессии (cookie/токен), а запросы к API идут от имени пользователя.
  3. OpenSearch Security проверяет права (RBAC), тенант, фильтры на уровне полей/документов (если настроены).

• Поисковые запросы: UI формирует DQL/Lucene → OSD транслирует в Query DSL и шлёт в OpenSearch.
  - Агрегации/визуализации: строятся на стороне OpenSearch (аггрегации Buckets/Metrics).
  - Кэширование: на стороне OpenSearch (query cache, request cache); OSD кэши минимальны.
  - Большие выборки: используйте filters/аггрегации вместо выгрузок; для экспорта — Reports/API с пагинацией/scroll (учитывайте лимиты heap и payload).

snippet.mermaid

sequenceDiagram
  participant Host as Linux host
  participant Shipper as Shipper (Fluent Bit/Filebeat)
  participant LS as Logstash (optional)
  participant OS as OpenSearch
  participant OSD as OSD
  Host->>Shipper: Файлы/ journald
  Shipper->>LS: Beats/HTTP (опц. TLS, 5044)
  LS-->>OS: Bulk API (HTTPS 9200)
  Shipper-->>OS: (альтернатива) напрямую по Bulk API
  OS-->>OSD: Поиск/агрегации (Query DSL)
  OSD-->>User: Discover/визуализации/дашборды

• Шаблоны/маппинги: определяют поля (text/keyword, даты/числа), анализаторы.
  - ISM (Index State Management): ротация, перемещение, удаление старых индексов.
  - Репликация: на стенде 0 реплик, в прод — ≥1 и несколько data‑узлов.
  - Именование индексов: суточные префиксы fluentbit-YYYY.MM.DD, filebeat-*, logstash-* — помогают с ротацией и TTL.

• TLS слои
  1. Браузер ⇄ OSD (5601): чаще TLS завершается на балансировщике/реверс‑прокси.
  2. OSD ⇄ OpenSearch (9200): HTTPS + проверка сертификатов (в прод).
  3. Отправители ⇄ Logstash/OS (5044/9200): включайте TLS и проверку CA.
  - Сегментация: ограничьте доступ к 9200 только доверенным источникам (OSD/Logstash/админы).
  - Заголовки безопасности: настройте HSTS/CSP на фронте, чтобы защитить UI.

• OSD горизонтально: несколько экземпляров за балансировщиком; липкие сессии желательны.
  - Статусность: OSD без состояния, но ключи/секреты сессий должны быть одинаковыми на всех инстансах.
  - OpenSearch: минимум 3 узла для кворума (cluster‑manager и data), отдельные узлы под ingest/координатор — по нагрузке.
  - Снапшоты: регулярные снапшоты на репозитории (S3/NFS). Saved Objects входят, т. к. лежат в системном индексе.

• OSD (Node.js): следите за RAM/CPU, лимитируйте размер ответа и таймауты запроса.
  - OpenSearch: heap JVM, file descriptors, vm.max_map_count, SSD, настройка refresh_interval и размеров сегментов.
  - Визуализации: предпочитайте аггрегации вместо выгрузки «сырых» данных; оптимизируйте Data Views (узкие шаблоны индексов).

• OSD: настройки логирования (stdout/файл, verbose).
  - OpenSearch: собственные логи + аудит Security плагина.
  - Метрики: собственные панели Observability (лог‑панель, трейсинг через OpenTelemetry/Jaeger, метрики Prometheus → exporters).

OSD → OpenSearch (минимум)

snippet.yaml

server.host: "0.0.0.0"
opensearch.hosts:
  - "https://os-coordinator:9200"
opensearch.ssl.verificationMode: full   # в прод
opensearch.username: "kibanaserver"     # сервисный пользователь OSD
opensearch.password: "<SECRET>"
opensearch_security.multitenancy.enabled: true

Шаблон индексов без реплик для стенда

snippet.bash

curl -k -u admin:'...' -X PUT https://os:9200/_index_template/logs \
  -H 'Content-Type: application/json' -d '{
  "index_patterns": ["logs-*","fluentbit-*","filebeat-*","logstash-*"],
  "template": { "settings": { "index.number_of_replicas": 0 } }
}'

• Разделяйте роли: сервисные пользователи OSD, шипперы, администраторы — отдельные учётки и роли.
  - Отладка YAML/UI: ошибки duplicated mapping key и кавычки в URL — самые частые при старте OSD.
  - RBAC по минимуму: давайте только нужные права (наборы действий: read, crud, create_index и т. п.).
  - Tenants: используйте для команд/проектов, чтобы изоляционно хранить Saved Objects.
  - ISM вместо ILM: в OpenSearch применяется Index State Management.
  - Документируйте Data Views: фиксируйте шаблоны индексов и поле времени — это влияет на весь UI.

• Состояние UI: Saved Objects (визуализации, дашборды, lens, data views) — в системном индексе OpenSearch.
  - Бэкап: делайте снапшоты OpenSearch (репозиторий snapshot). Для миграций между стендами — экспорт/импорт Saved Objects из UI.
  - Конфиги: хранятся на узлах OSD/OpenSearch/Logstash — версионируйте в Git.

• [ ] TLS на всех каналах + проверка CA.
  - [ ] Отдельный сервисный пользователь для OSD; отдельные пользователи для шипперов и людей.
  - [ ] HA OSD (≥2 инстанса) за LB; единые секреты сессий.
  - [ ] OpenSearch: ≥3 узла, снапшоты, мониторинг heap/IO.
  - [ ] ISM‑политики для логов, тайм‑базовые индексы.
  - [ ] Сетевые ACL: 5601 наружу (или за VPN), 9200 — только доверенным источникам.
  - [ ] Логи OSD и аудит OpenSearch подключены в вашу SIEM/мониторинг.

Итог: OSD — тонкий UI‑слой над OpenSearch, безопасно проксирующий запросы пользователей и хранящий артефакты интерфейса в системном индексе. Масштабирование достигается горизонтальным увеличением инстансов OSD и правильной архитектурой кластера OpenSearch; безопасность — через RBAC/тенанты/TLS и сегментацию сети.