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

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

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

---

## 1) Роль OSD в экосистеме 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).

---

## 2) Высокоуровневая схема

```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` (если используется).

---

## 3) Внутренние компоненты OSD

- **Node.js‑сервер OSD**  
  - Прокси к 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-*`).

---

## 4) Аутентификация и авторизация

- **Кто аутентифицирует?** — плагин безопасности в 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), тенант, фильтры на уровне полей/документов (если настроены).

---

## 5) Потоки запросов и кэширование

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

---

## 6) Инжест и жизненный цикл данных

```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.

---

## 7) Сеть и TLS

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

---

## 8) Масштабирование и HA

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

---

## 9) Производительность и лимиты

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

---

## 10) Логирование и наблюдаемость

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

---

## 11) Типовые конфигурации (фрагменты)

**OSD → OpenSearch (минимум)**
```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
```

**Шаблон индексов без реплик для стенда**
```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 } }
}'
```

---

## 12) Практические рекомендации

- **Разделяйте роли:** сервисные пользователи 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.

---

## 13) Что считать «состоянием» и как бэкапить

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

---

## 14) Мини‑чеклист для прод‑ввода

- [ ] 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 и сегментацию сети.