OpenSearch

答案：

OpenSearch 是 AWS 于 2021 年 1 月在 Elasticsearch 7.10.2 基础上 fork 出的开源搜索与分析引擎，2021 年 4 月以 Apache 2.0 许可证正式发布，由 OpenSearch Software Foundation（Linux 基金会）治理。

[分层展开]

• Fork 起点：OpenSearch 1.0 基于 Elasticsearch 7.10.2，该版本是 Elastic 最后一个以 Apache 2.0（SSPL 切换前）发布的版本。Elastic 自 7.11 起改用 SSPL/Elastic License，AWS 为保持云服务（OpenSearch Service）自由度而 fork。
• 治理结构：项目交付 OpenSearch Software Foundation，AWS、SaaS、Canonical、Red Hat 等多元治理，社区通过 GitHub 维护，截至 2025 年已演进至 OpenSearch 3.x，主版本以 Lucene 10 为底座并整合向量（k-NN）、稀疏检索、学习排序（LTR）等特性。
• 核心产品矩阵：
  • OpenSearch（核心引擎）：Search + Analytics 引擎，融合原 Elasticsearch 的分布式索引与聚合能力。
  • OpenSearch Dashboards：Kibana 7.10 的开源替代，承担可视化与仪表板职能。
  • OpenSearch Plugins：Security、Alerting、Anomaly Detection、ISM、k-NN、ML、SQL、PPL、Performance Analyzer 等。
• 与 Elastic Stack 的本质差异：OpenSearch 是社区驱动的 Apache 2.0 项目，版本规划、安全模型、特性路线由社区讨论决定，AWS、阿里云、SAP、Tencent 等厂商基于其构建托管服务。

答案：

OpenSearch 与 Elasticsearch 自 1.0/7.11 起在许可证、安全插件、查询语法、默认分片策略等方面出现显著差异，从 ES 7.10 迁移到 OpenSearch 1.x 成本极低，但从 ES 7.16+ 或 8.x 迁移则需逐项评估。

[分层展开]

• 许可证差异：OpenSearch 全栈采用 Apache 2.0，允许自由使用、修改与商业分发；Elasticsearch 自 7.11 改用 SSPL + Elastic License v2 双许可，禁止托管服务商未经授权提供托管服务，是 AWS fork 的直接动因。
• 安全插件差异：OpenSearch Security 插件将 X-Pack Security 的核心能力（TLS、RBAC、Audit、Document/Centralized/Field-level Security）以 Apache 2.0 提供，并引入新的 opensearch_security 配置文件结构；Elasticsearch 在 Basic License 下仅保留 TLS，RBAC/Audit 需付费订阅。
• 查询能力差异：
  • OpenSearch 引入 PPL（Pipe Processing Language），与 SQL 并列作为一等查询语言，语法类似 Logstash/Lucene 查询管道。
  • OpenSearch 原生集成 k-NN 插件，支持 HNSW、IVF 等向量索引，适配 RAG/语义检索。
  • Elasticsearch 8.x 引入 ES|QL（Elasticsearch Query Language），OpenSearch 3.x 推出 Query DSL 增强与 PPL 引擎。
• 默认行为差异：
  • 索引分片：从 ES 7.0 起 number_of_shards 默认 1，OpenSearch 沿用该默认值，但 ISM（Index State Management）的状态机实现与 ILM 不同。
  • 集群健康：API 端点兼容（/_cluster/health），但 /_cat 输出字段在 2.x 后逐步分化。
• 迁移成本矩阵：
  • ES 7.10.x → OpenSearch 1.x：极低成本，可直接 Reindex 或使用 Remote Reindex 协议互通。
  • ES 7.16 ~ 8.x → OpenSearch 2.x/3.x：需评估 ILM→ISM 规则转换、X-Pack 高级特性（ML、Watcher、Graph）替代方案（OpenSearch Anomaly Detection + Alerting）、Index Template 字段差异。
  • 安全策略：从 elasticsearch.yml 中 xpack.security.* 迁移到 opensearch.yml 中 plugins.security.* 配置需脚本化重写。

# ES 7.10 → OpenSearch 1.x 典型迁移流程
# 1. 升级到 ES 7.10.2（最后 Apache 2.0 版本）
# 2. 关闭集群滚动升级至 OpenSearch 1.0
# 3. 导入安全配置：plugins.security.* 替代 xpack.security.*
# 4. ILM 策略转换为 ISM Policy
# 5. 验证：GET _cat/indices?v 与 GET _cluster/health

答案：

OpenSearch 集群由 Cluster Manager（Master-eligible）、Data、Coordinating、Ingest、ML、Search 等多角色节点构成，索引按 Shard 水平切分，每个 Shard 含一个 Primary 与零到多个 Replica 副本，集群通过 Zen Discovery 选举 Cluster Manager 协调元数据。

[分层展开]

• Cluster Manager 节点：原 Master 节点（OpenSearch 2.0 重命名以避免歧义），负责集群状态、Shard 分配、索引创建与删除。生产环境部署奇数个（3 或 5）专用节点，配合 cluster.routing.allocation.same_shard.host 等分配策略。
• Data 节点：存储分片、处理索引与查询请求，是磁盘与内存的主要消耗者。按数据温度可分为 Hot（SSD）、Warm（HDD）、Cold（高密度存储）三层。
• Coordinating 节点：仅路由请求、合并分片结果，不承载数据（node.data=false）。可作为 Kibana/Dashboards 与集群之间的负载均衡层。
• Ingest 节点：执行 Ingest Pipeline（类似 Logstash Filter），用于写入前字段提取、转换、丰富。
• Cluster Manager 选举：基于 Elasticsearch 的 Zen Discovery 改造，使用 Ping + Unicast 模式，通过 discovery.zen.minimum_master_nodes（OpenSearch 调整为 cluster.initial_cluster_manager_nodes 引导）。
• Shard 模型：
  • Primary Shard：写入入口，承担索引与查询。数量在索引创建时确定，使用 index.number_of_shards。
  • Replica Shard：Primary 的完整副本，提供读负载分担与故障切换。副本数可动态调整（index.number_of_replicas）。
  • 分片分配：Cluster Manager 按 cluster.routing.allocation.* 策略将分片分配到 Data 节点，支持 Awareness、Filtering、Throttling。
• 集群健康状态：
  • Green：所有 Primary 与 Replica 均已分配。
  • Yellow：所有 Primary 已分配，但部分 Replica 缺失。
  • Red：存在未分配的 Primary。

# OpenSearch 集群配置示例（opensearch.yml）
cluster.name: production-cluster
node.name: os-node-1

# 节点角色
node.roles: ["cluster_manager", "data", "ingest"]

# 发现配置
discovery.seed_hosts: ["os-node-1", "os-node-2", "os-node-3"]
cluster.initial_cluster_manager_nodes: ["os-node-1", "os-node-2", "os-node-3"]

# 网络与安全
network.host: 0.0.0.0
http.port: 9200
plugins.security.ssl.http.enabled: true
plugins.security.ssl.transport.enabled: true

答案：

OpenSearch 索引设计围绕 Mapping（字段类型与分词）、Settings（分片、副本、刷新间隔）、Index Template（自动匹配模式）、Component Template（可复用片段）与 ISM（Index State Management，索引状态机）五大支柱展开，目标是匹配查询模式并控制生命周期成本。

[分层展开]

• Mapping 类型：
  • 核心字段类型：keyword（精确匹配、聚合）、text（全文检索，经分词器处理）、numeric（long/integer/double 等）、date、boolean、object、nested、geo_point、binary。
  • 多字段（fields）：同一字段同时支持全文检索与精确聚合，如 name（text）+ name.keyword（keyword）。
  • Nested 类型：用于数组中的对象字段独立索引，避免对象数组扁平化。
  • Dynamic Mapping：自动推断字段类型，生产环境建议关闭（dynamic: strict）以避免 Mapping 爆炸。
• Settings 关键参数：
  • index.number_of_shards：主分片数，索引创建后不可变更。
  • index.number_of_replicas：副本数，可动态调整。
  • index.refresh_interval：刷新间隔（默认 1s），日志/批量场景可调大到 30s 以降低 Segment 合并压力。
  • index.translog.durability：默认 request，批量导入时可临时改为 async 提升吞吐。
  • index.codec：默认 LZ4，高压缩场景使用 zstd 或 best_compression。
• Index Template 与 Component Template：
  • Component Template：定义可复用的 settings、mappings、aliases 片段。
  • Index Template：通过 index_patterns 匹配索引名，组合多个 Component Template，优先级（priority）高的模板优先匹配。
  • 模板嵌套结构支持解耦（如公共 settings.ctmpl、业务字段 mappings.ctmpl）。
• ISM（Index State Management）：
  • 替代 ES ILM（OpenSearch 1.0 引入），基于状态机模式管理索引生命周期。
  • 状态包括 hot、warm、cold、delete，支持 Rollover、Forcemerge、Snapshot、Read-only、Delete 等 Action。
  • 通过 ISM Policy 文件（JSON）定义，结合 managed_index API 绑定到索引模板。
• 数据流（Data Streams）：用于时序与追加写入场景，底层由多个后备索引（Backing Indices）组成，配合 ISM 自动 Rollover。

// 索引模板：Component Template + Index Template 组合
PUT _component_template/logs-settings
{
  "template": {
    "settings": {
      "index.number_of_shards": 3,
      "index.number_of_replicas": 2,
      "index.refresh_interval": "30s"
    },
    "mappings": {
      "properties": {
        "timestamp": { "type": "date" },
        "level":     { "type": "keyword" },
        "message":   { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 512 } } },
        "host":      { "type": "keyword" },
        "trace_id":  { "type": "keyword" }
      }
    }
  }
}

PUT _index_template/logs-template
{
  "index_patterns": ["logs-*"],
  "priority": 100,
  "composed_of": ["logs-settings"],
  "data_stream": {}
}

答案：

OpenSearch Query DSL 是基于 JSON 的结构化查询语言，分为叶查询（Leaf Queries）、复合查询（Compound Queries）和聚合（Aggregations）三大类；PPL（Pipe Processing Language）是 OpenSearch 独有的管道式查询语法，简化日志检索表达。

[分层展开]

• 叶查询（Leaf Queries）：
  • match：对 text 字段做分词后匹配，支持 operator（and/or）、minimum_should_match、fuzziness。
  • match_phrase：短语匹配，要求词项顺序相邻，可配 slop。
  • term：对 keyword、数值等精确字段做精确匹配，不分词。
  • terms：多值精确匹配（IN 查询）。
  • range：范围查询，支持 gt/gte/lt/lte，适用于 date、numeric。
  • exists / ids / prefix / wildcard / regexp：辅助查询。
• 复合查询（Compound Queries）：
  • bool：组合 must（AND）、should（OR）、must_not（NOT）、filter（不计分过滤）四个子句，是最核心的查询容器。
  • boosting：调整子句权重实现结果重排。
  • dis_max：取多子句中最大相关度，常用于多字段同义查询。
  • function_score：自定义评分函数，结合衰减函数、随机权重等。
• 聚合（Aggregations）：
  • Metric Aggregations：avg、sum、min、max、stats、percentiles、cardinality。
  • Bucket Aggregations：terms、date_histogram、histogram、range、nested、geohash_grid。
  • Pipeline Aggregations：derivative、moving_avg、bucket_script，对聚合结果做二次计算。
• PPL（Pipe Processing Language）：
  • 类 Unix 管道语法：source = logs-* | where level="ERROR" | stats count() by host | sort - count | head 10。
  • 与 SQL 并列，可在 Dashboards Discover、SQL Plugin、REST API（_plugins/_ppl）中使用。
  • 底层通过 OpenSearch PPL Engine 编译为 Query DSL，对运维与 SRE 友好。
• SQL 兼容：通过 _sql 端点使用 ANSI SQL 查询 OpenSearch，支持 SHOW、DESCRIBE、SELECT、GROUP BY、JOIN（部分场景）。

// 典型 bool 查询 + aggregation 组合
GET logs-2026.05/_search
{
  "size": 0,
  "query": {
    "bool": {
      "must": [
        { "match": { "message": "timeout" } }
      ],
      "filter": [
        { "term":  { "level": "ERROR" } },
        { "range": { "timestamp": { "gte": "now-1h" } } }
      ]
    }
  },
  "aggs": {
    "by_host": {
      "terms": { "field": "host.keyword", "size": 20 },
      "aggs": {
        "avg_latency": { "avg": { "field": "latency_ms" } }
      }
    }
  }
}

-- SQL 等价查询
POST _plugins/_sql
{
  "query": "SELECT host, COUNT(*) AS cnt FROM logs-2026.05 WHERE level = 'ERROR' AND timestamp > NOW() - INTERVAL 1 HOUR GROUP BY host ORDER BY cnt DESC LIMIT 20"
}

答案：

OpenSearch 性能调优围绕查询路径、写入路径、集群拓扑与硬件选型四个层面，目标是在成本可控前提下最大化吞吐量与降低 P99 延迟。

[分层展开]

• 查询性能调优：
  • Query Cache：缓存 Filter 子句结果（indices.queries.cache.size: 10%），适合 bool.filter 频繁命中的查询。
  • Request Cache：缓存 size=0 的聚合结果（indices.requests.cache.size: 1%），适用于聚合仪表板。
  • Shard Request Cache：分片级缓存，默认开启。
  • 字段映射优化：将不需要分词的字段设为 keyword；对 text 字段禁用 _source 中的冗余字段；高基数聚合用 eager_global_ordinals。
  • 查询重写：避免 wildcard 前缀模糊匹配；高基数 terms 聚合配 execution_hint: map；使用 search_after 替代 from + size 做深翻页。
  • Profile API：GET _search?profile=true 暴露分片级 Lucene 评分与匹配耗时，定位瓶颈。
• 写入性能调优：
  • Bulk API：单次 Bulk 5 ~ 15 MB 或 1000 ~ 5000 文档为佳，异步流水线提交。
  • Refresh Interval：日志/批量导入场景调大到 30s 或 60s，减少 Segment 生成。
  • Translog 策略：导入阶段使用 async + 较大 flush_threshold_size，导入完成后切回 request。
  • Indexing Buffer：indices.memory.index_buffer_size: 15%（默认 10%），提升 doc 写入吞吐。
  • 分片数规划：单分片 10 ~ 50 GB；高写入场景提前评估分片数，避免后续 Reindex。
• 集群与硬件调优：
  • JVM Heap：Data 节点 50% 内存且 ≤ 31 GB（避免 Compressed OOP 失效），使用 G1GC。
  • Swap 禁用：bootstrap.memory_lock: true，配合 LimitMEMLOCK=infinity。
  • 磁盘 I/O：Hot 节点用 NVMe SSD；CFS 调度器配 io_uring 提升小 I/O 性能。
  • 网络：10 GbE+ 互联，避免跨 AZ 部署，必要时使用 Cross-Cluster Search。
  • Cluster Manager 节点：专用 3 节点 + 4C8G 起步，避免与 Data 节点混合部署。
  • Slow Log：index.search.slowlog.threshold.query.warn: 10s；index.indexing.slowlog.threshold.index.warn: 10s。
• Performance Analyzer 插件：采集 JVM、I/O、Cache、GC 指标，导出至 Prometheus。

# 性能调优配置（opensearch.yml）
# 集群层
cluster.routing.allocation.disk.threshold_enabled: true
cluster.routing.allocation.disk.watermark.low: 85%
cluster.routing.allocation.disk.watermark.high: 90%

# 索引层默认
index.refresh_interval: 30s
index.translog.durability: async
index.translog.sync_interval: 30s

# 缓存
indices.queries.cache.size: 10%
indices.requests.cache.size: 1%

# JVM
-Xms16g -Xmx16g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200

答案：

OpenSearch Security 插件（原 ReadonlyREST 社区版）提供 TLS 加密、Authentication（认证）、Authorization（授权）、Audit 审计与多租户（Document/Field-level Security）能力，配置文件独立于 OpenSearch 核心配置（config/opensearch-security/），通过 securityadmin.sh 工具初始化与更新。

[分层展开]

• 认证方式：
  • Internal User Database：内置用户名/密码（bcrypt 哈希），适合中小规模。
  • LDAP / Active Directory：通过 config.yml 配置 ldap 认证域，支持用户搜索、组映射。
  • JWT / OpenID Connect：通过 Dashboards 与 Security 插件集成 Keycloak、Auth0、Cognito、Okta。
  • Proxy / Header：在反向代理层（NGINX、ALB）注入 proxy 头，由 Security 插件识别远程用户。
  • SAML 2.0：企业 SSO 场景，Dashboards 端配置 IdP（Okta、ADFS）。
  • Client Certificate：基于 mTLS 的客户端认证。
• 授权（RBAC）：
  • Role：权限集合，定义 cluster permissions、index permissions、tenant permissions、document level security（DLS）、field level security（FLS）。
  • Role Mapping：将用户、组或后端角色映射到 Role，支持多映射叠加（backend_roles 合并）。
  • Backend Roles：从 LDAP 组、JWT claim、Proxy header 中提取的语义化角色标识。
  • Action Groups：预定义权限组合（如 cluster_composite_ops_ro、read），简化 Role 编写。
• TLS 配置：
  • Transport TLS：节点间通信加密，必启用。
  • HTTP TLS：REST API 加密，可选但生产强制。
  • Client Certificate：双向认证，配合 RBAC 实现零密码场景。
• Audit 日志：通过 Audit Log 输出到 OpenSearch 索引（自动轮转）或外部系统（audit.log、log4j），记录认证、授权、缺失权限、SSL 失败等事件。
• 多租户（Multi-tenancy）：
  • Tenant：在 OpenSearch Dashboards 中隔离工作空间（Index Pattern、Visualization、Query）。
  • Field-/Document-level Security：通过 FLS 隐藏敏感字段（如 password、ssn），通过 DLS 限定查询范围（如 {"term": {"tenant_id": "acme"}}）。
• 配置管理工具：
  • securityadmin.sh：将 internal_users.yml、roles.yml、roles_mapping.yml、action_groups.yml、tenants.yml 推送到集群。
  • Security Configuration API（2.x+）：通过 REST API 动态管理配置，无需重启。

# opensearch.yml — 启用 Security
plugins.security.disabled: false
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: esnode.pem
plugins.security.ssl.http.pemkey_filepath: esnode.key
plugins.security.ssl.http.pemtrustedcas_filepath: root-ca.pem

plugins.security.ssl.transport.enabled: true
plugins.security.ssl.transport.pemcert_filepath: esnode.pem
plugins.security.ssl.transport.pemkey_filepath: esnode.key
plugins.security.ssl.transport.pemtrustedcas_filepath: root-ca.pem

plugins.security.authcz.admin_dn:
  - "CN=admin,OU=SSL,O=OpenSearch,L=Earth,C=US"

plugins.security.audit.type: internal_opensearch
plugins.security.audit.config.enable_rest: true

# roles.yml — 角色定义
finance_readonly:
  cluster_permissions:
    - "cluster_composite_ops_ro"
  index_permissions:
    - index_patterns: ["finance-*"]
      dls: '{"term": {"region": "cn-north-1"}}'
      fls:
        - "~ssn"
        - "~credit_card"
      allowed_actions:
        - "read"
        - "search"

答案：

OpenSearch Alerting 插件基于 Monitors（监控定义）、Triggers（触发条件）、Actions（响应动作）、Destinations（通知通道）四层模型实现告警，支持多种数据源（OpenSearch 索引、Prometheus 远端写入、API）与丰富的响应动作（Email、Webhook、Slack、Index、Custom 等）。

[分层展开]

• Monitors：
  • Schedule：基于 Cron 表达式（* * * * *）定义查询频率，最小粒度 1 分钟。
  • Data Source：
    • OpenSearch Index：对索引执行 Query DSL 或 Aggregation。
    • Prometheus：通过 _plugins/_alerting/monitors 配置 PromQL 远端写入查询。
    • Custom：通过 _plugins/_alerting/monitors 的 query 字段自定义 JSON。
  • Detection Method：
    • Query：执行查询，Trigger 基于结果触发。
    • Bucket-Level：在 Terms/Date Histogram 聚合桶上独立判断，定位异常桶。
    • Cluster Metrics：集群级指标（JVM、CPU、Shard 未分配数）。
• Triggers：
  • Trigger Name：人类可读名称。
  • Severity：info / warning / error。
  • Condition：JavaScript 表达式，对 Monitor 返回结果做条件判断（如 ctx.results[0].hits.total.value > 100）。
  • Bucket-Level Trigger：自动对每个 Bucket 独立判断，支持 parent_bucket_path。
• Actions：
  • Action Name、Destination（关联 Destinations）。
  • Template：Mustache 模板定义告警内容（Subject、Message、Body）。
  • Throttle：抑制重复告警（for_duration）。
  • Actionable Alerts：通过 OpenSearch Dashboards 手动 ACK 告警、查看历史。
• Destinations：
  • 类型：Email（SMTP）、Slack、Webhook（Generic）、Amazon Chime、Microsoft Teams、Custom Webhook、Telegram、Index（写入专用告警索引）。
  • 通过 Destinations API 统一管理，支持命名空间与共享。
• 告警生命周期：Monitor 触发 → Trigger Condition 命中 → Action 发送 → 写入 .opendistro_alerts_index → 可视化与 ACK。

// 创建 Monitor：监控错误日志突增
POST _plugins/_alerting/monitors
{
  "type": "monitor",
  "name": "error-log-burst",
  "schedule": { "period": { "interval": 1, "unit": "MINUTES" } },
  "inputs": [
    {
      "search": {
        "indices": ["logs-*"],
        "query": {
          "size": 0,
          "query": {
            "bool": {
              "filter": [
                { "term":  { "level": "ERROR" } },
                { "range": { "timestamp": { "gte": "now-5m" } } }
              ]
            }
          }
        }
      }
    }
  ],
  "triggers": [
    {
      "name": "error-threshold",
      "severity": "high",
      "condition": { "script": { "source": "ctx.results[0].hits.total.value > 500" } },
      "actions": [{ "name": "notify-oncall", "destination_id": "slack-oncall" }]
    }
  ]
}

答案：

OpenSearch 可观测性由 Performance Analyzer（PA）代理、OpenSearch Dashboards 的 Observability 插件、Top-N Queries 慢查询分析、Anomaly Detection 异常检测四大组件构成，端到端覆盖集群指标、查询画像、数据异常与运维仪表板。

[分层展开]

• Performance Analyzer (PA)：
  • 架构：运行在每个 OpenSearch 节点的独立 JVM 进程，监听端口 9600，采集 JVM、I/O、Cache、GC、Shard、Thread Pool 指标。
  • 导出：
    • OpenSearch 索引：通过 _plugins/_performanceanalyzer 写入指标索引（opensearch_perf_*）。
    • Prometheus Exporter：通过 Root Cause Analysis (RCA) 端点暴露 Prom 指标。
    • JSON / WebSocket：通过 /metrics 与 /metrics/_stats 暴露原始与聚合指标。
  • 核心指标维度：
    • JVM：Heap usage、GC count、GC time、Thread count。
    • Cache：Field data cache、Request cache、Query cache、Shard request cache。
    • I/O：Disk read/write throughput、IOPS、Latency。
    • Shard：Shard state、Indexing pressure、Search latency。
    • Thread Pool：Write、Search、Snapshot、Management 队列与拒绝数。
• Top-N Queries（慢查询分析）：
  • 通过 /_insights/top_queries 端点返回最近 7 天最耗时 / 最高 CPU / 最高内存查询。
  • 输出字段：timestamp、index、query、latency、cpu_time、memory_usage、aggregation_type、shard_count。
  • 用于识别热查询、定位索引设计缺陷、指导查询重写。
• OpenSearch Dashboards Observability：
  • Logs：日志全链路检索、PPL/SQL 可视化。
  • Metrics：时序数据可视化、Prometheus 数据源。
  • Traces：通过 OpenTelemetry Collector 接入 APM 数据（替代 Elastic APM）。
  • Dashboards：集成 Grafana-like 仪表板，支持 Visualization、Canvas。
• Anomaly Detection（异常检测）：
  • 基于 Random Cut Forest（RCF）算法对单/多变量时序做异常打分。
  • 与 Alerting 联动，异常时触发 Action。
  • 适用于 QPS 突降、错误率激增、Latency 漂移等场景。
• Indexing Pressure 指标：实时输出 indexing_pressure 状态（normal、low、high、critical），指导 Bulk 写入速率调整。

# 启用 Performance Analyzer
# 1. 配置 performance-analyzer.properties
PA_HOME=/usr/share/opensearch/plugins/opensearch-performance-analyzer
metrics.location=$PA_HOME/rca_metrics
metrics.deletion.interval=12h

# 2. 启动并验证
curl -XGET "localhost:9600/_plugins/_performanceanalyzer/metrics?metrics=*&dim=*"
curl -XGET "localhost:9600/_plugins/_performanceanalyzer/cluster/api/metrics"

# 3. 慢查询分析
GET _insights/top_queries
{
  "query": {
    "match_all": {}
  },
  "sort": {
    "cpu_time": "desc"
  },
  "size": 10
}

答案：

OpenSearch 在 REST API、Query DSL、Mapping 语法上与 Elasticsearch 7.10.x 保持高兼容，但 2.x/3.x 后逐步引入 ISM、PPL、向量等新特性；跨集群复制（CCR）与跨集群搜索（CCS）支持多数据中心与异地容灾；生产部署需在版本兼容、客户端协议、安全联邦、监控告警上系统化设计。

[分层展开]

• API 与协议兼容：
  • REST API：核心读写、聚合、集群管理 API 与 ES 7.10 兼容；_cat、_cluster、_nodes 行为基本一致。
  • Java High Level / RestClient：OpenSearch 提供独立的 opensearch-java 客户端，原 ES 7.10 客户端可与 OpenSearch 1.x 通信但不保证新特性。
  • Beats / Logstash：通过 OpenSearch Output Plugin（logstash-output-opensearch、opensearch-java）替代 logstash-output-elasticsearch。
  • Elastic Agent / Fleet：需替换为 OpenSearch Dashboards 的 Integration 或 Data Prepper（AWS 推出的 OpenSearch 数据通道）。
• 跨集群复制（Cross-Cluster Replication, CCR）：
  • 架构：Leader Cluster → Follower Cluster，单向异步复制，基于 Shard 级别增量同步。
  • API：PUT _plugins/_replication/followerships/follower-1 创建 Follow。
  • 使用场景：异地容灾、读写分离、跨地域数据汇聚。
• 跨集群搜索（Cross-Cluster Search, CCS）：
  • 架构：通过 cluster.remote 配置远端集群，前缀式查询 cluster_one:logs-*,cluster_two:metrics-*。
  • 使用场景：联邦检索、统一视图、聚合多数据中心。
• Snapshot 与恢复：
  • 通过 S3、GCS、Azure Blob、共享 NFS 存储 Snapshot。
  • SM_POLICY（Snapshot Management Policy）自动化快照生命周期。
• 生产实践要点：
  • 版本一致：集群内所有节点版本严格一致；滚动升级遵循 OpenSearch 官方升级路径（跨大版本需 Full Restart）。
  • 安全联邦：通过 Security 插件的 roles.yml 集中管理多集群权限。
  • 监控告警：Performance Analyzer + Prometheus + Alertmanager；结合 Anomaly Detection 检测隐性故障。
  • 容量规划：单分片 10 ~ 50 GB；副本数 1 ~ 2；预留 20% 磁盘与 30% Heap 余量。
  • 客户端协议：使用 HTTPS + Basic Auth 或 mTLS，禁用 HTTP 明文。
  • 数据生命周期：ISM 状态机自动化 Rollover、Forcemerge、Snapshot、Delete。

# 跨集群搜索（CCS）配置（opensearch.yml）
cluster.remote:
  cluster_one:
    seeds: 10.0.1.10:9300
  cluster_two:
    seeds: 10.0.2.10:9300

# 查询时使用 cluster 前缀
GET cluster_one:logs-*,cluster_two:metrics-*/_search
{
  "query": { "match_all": {} }
}

# 跨集群复制（CCR）
PUT _plugins/_replication/followerships/follower-1
{
  "leader_alias": "leader-cluster",
  "leader_index": "logs-2026.05",
  "use_ssl": true,
  "auth_type": "basic",
  "username": "replication_user",
  "password": "${REPLICATION_PASSWORD}"
}

参考资料：OpenSearch 官方文档（opensearch.org/docs/latest/）、OpenSearch GitHub 仓库（github.com/opensearch-project）、AWS OpenSearch Service 文档（docs.aws.amazon.com/opensearch-service）