使用 AWS Distro for OpenTelemetry 和 OpenSearch 构建一体化可观测性平台

一. 概述

在数字化高度发展的今天，现代应用和基础设施的管理日渐复杂，应用和服务通常分布在多个云平台和物理位置，涉及无数的交互和依赖，在这种环境下，传统的传统的监控工具往往难以提供足够的可见性来确保系统的健康和效率。这就是为什么可观测性成为了现代 IT 管理不可或缺的组成部分。阅读本文，您将会了解到：

如何通过 Amazon Distro for OpenTelemetry 将不同类型的日志 Log，Metric 和 Trace 发到 AWS OpenSearch Ingestion
如何通过 OpenSearch Ingestion 处理日志并且将数据发送到 OpenSearch Cluster
如何通过 OpenSearch Cluster 2.17 实现 Log，Metric 和 Trace一体化可观测性

Amazon Distro for OpenTelemetry（ADOT）是 AWS 提供的 OpenTelemetry 优化发行版。作为 OpenTelemetry 生态系统的成员，ADOT 集成了开源项目的功能，同时针对 AWS 环境进行了深度优化。ADOT 支持全面的可观测性数据收集和处理，包括指标、日志和分布式追踪。它提供多语言 SDK 支持，并具有自动检测功能，简化了实施过程。ADOT 与 AWS 服务无缝集成，用户可轻松将数据发送至 CloudWatch、OpenSearch 等 AWS 原生解决方案。凭借 AWS 的优化，ADOT 确保在云环境中的卓越性能和安全性。此外，ADOT 的可扩展性允许用户根据需求进行定制开发。总的来说，ADOT 为 AWS 用户提供了一个全面、高效的可观测性解决方案。

Amazon OpenSearch Ingestion为处理来自 OpenTelemetry 的可观测性数据提供了强大而灵活的解决方案。它可以接收 OpenTelemetry 发送的日志、指标和追踪数据，并通过配置专门的管道来处理这些数据。对于日志，Ingestion 可以解析不同格式，提取关键字段，并进行结构化；对于指标，它能够进行聚合、单位转换和标准化；而对于追踪数据，Ingestion 可以处理分布式追踪信息，关联不同服务间的调用关系。通过这些处理，OpenSearch Ingestion 确保了数据在写入 OpenSearch 之前得到适当的转换和增强，为后续的搜索、分析和可视化奠定了基础。此外，Ingestion 的可扩展性允许用户根据特定需求添加自定义处理器，进一步优化数据处理流程。这种集成为构建全面的可观测性平台提供了关键支持，使组织能够更有效地监控和优化其分布式系统。

Amazon OpenSearch Domain 可让您轻松执行交互式日志分析、实时应用程序监控、网站搜索等工作。OpenSearch 是一款开源的分布式搜索和分析套件，衍生自 Elasticsearch，不仅可以支持 PB 级文本与非结构化数据的搜索、可视化和分析，同时还可以与 Amazon VPC 集成，并提供多项安全功能，简化了管理员的日志分析工作。借助于 Amazon Lambda，我们可以使用 Python API 将处理后的数据写入到 Amazon OpenSearch Service 服务。

二. 先决条件

您可以参考微服务化可观测 Workshop 的 CloudFormation 模版创建必要的环境，或者通过 CloudShell 进行基础环境的构建，本文假设您已经创建了以下资源。

EKS 集群，并创建安装好需要的 Node Group
为 EKS 集群安装必要的 Add-on，包括 AWS Load Balancer Controller、ADOT
使用 ADOT SDK 完成程序的 Instrumentation，完成需要监控的代码源头的 Instrumentation
一个版本为 17 的 Amazon OpenSearch 集群，样例为使用 FineGain Access 精细化权限管控

下载样例代码：

https://github.com/aws-samples/observability-with-amazon-opensearch/tree/main/sample-apps

三. 架构与实现

下面我们基于下图的总体架构，详细讲解一下整个架构的实现过程。

第一步：通过 Amazon Distro for OpenTelemetry 将日志发到 AWS OpenSearch Ingestion

参考以下 otel-collector-config.yml 文件配置 ADOT 的组件，包括 extensions，receivers，processors，exporters 以及不同的 pipeline。当前案例中 Log，Metrics 和 Trace 各建了一个单独的 pipeline。配置 exporter 的 endpoint 指向 OpenSearch Ingestion Pipeline 的 Ingestion URL，创建 OpenSearch Ingestion Pipeline 的方法参考第二步。

# otel-collector-config.yml
extensions:
  sigv4auth:
    region: "us-east-1"
    service: "osis"

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:55680
      http:
        endpoint: 0.0.0.0:55681
        
processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 30
  batch:
    send_batch_size: 10
    timeout: 5s

exporters:
  otlphttp/traces:
    traces_endpoint: "your-opensearch-ingestion-trace-endpoint/v1/traces"
    auth:
      authenticator: sigv4auth
    compression: none
  otlphttp/logs:
    logs_endpoint: "https:// your-opensearch-ingestion-log-endpoint /v1/logs"
    auth:
      authenticator: sigv4auth
    compression: none        
  otlphttp/metrics:
    metrics_endpoint: "https:// your-opensearch-ingestion-metric-endpoint /v1/metrics"
    auth:
      authenticator: sigv4auth
    compression: none
  
service:
  extensions: [sigv4auth]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlphttp/traces]
    logs:
      receivers: [otlp]
      processors: [memory_limiter， batch]
      exporters: [otlphttp/logs]
    metrics:
      receivers: [otlp]
      exporters: [otlphttp/metrics]

第二步：通过 OpenSearch Ingestion 将数据保存到 OpenSearch

2.1 首先进行权限配置

创建 IAM Role blog-osi-pipeline-role

打开 OpenSearch Dashboard Security 下面的 Roles，创建 Role blog-osi-pipeline-role 并且赋予 OpenSearch Ingestion 所需的权限

创建完 Role 之后，点开 Mapped Users 并且填入创建的 IAM Role 的 arn 为 Backend Role

2.2 接下来创建 Logs，Metrics 和 Traces 对应的 OpenSearch Ingestion Pipeline

通过 OSI Pipeline 配置文件，我们可以将数据从 ADOT 收集器接收，并将数据流向不同的 OpenSearch Ingestion Pipeline。Pipeline 会对数据进行处理和转换，并将数据存储在 OpenSearch 集群中的不同 Index 中。

配置 OpenSearch Ingestion Logs pipeline: blog-osi-pipeline-otellogs

version: "2"
otel-logs-pipeline:
  source:
    otel_logs_source:
      path: "/v1/logs"
  processor:
    - parse_json:
        source: "body"                  
    - parse_json:
        source: "kubernetes"                  
    - parse_json:
        source: "annotations"                  
    - parse_json:
        source: "labels"              
    - delete_entries:
        with_keys: ["body"， "kubernetes"， "annotations"，"labels"]
    - date:
        from_time_received: true
        destination: "@timestamp"           
  sink:
    - opensearch:                  
        index: "sample_app_logs"
        hosts: ["your-opensearch-endpoint"]
        aws:                  
          sts_role_arn: "arn:aws:iam::your-account:role/blog-osi-pipeline-role"
          region: "us-east-1"

配置 OpenSearch Ingestion Metrics pipeline: blog-osi-pipeline-otelmtcs

version: "2"
otel-metrics-pipeline:
  source:
    otel_metrics_source:
      path: "/v1/metrics"
  processor:
    - otel_metrics:
  sink:
    - opensearch:
        index: "sample_app_metrics"
        hosts: ["your-opensearch-endpoint"]
        aws:                  
          sts_role_arn: "arn:aws:iam::your-account:role/blog-osi-pipeline-role"
          region: "us-east-1"

配置 OpenSearch Ingestion Traces pipeline: blog-osi-pipeline-oteltraces
收集 ADOT Trace 数据，生成 Service Map 数据，最终将 Trace 数据和 Service Map 数据发送到 OpenSearch Index 中。

version: "2"
entry-pipeline:
  source:
    otel_trace_source:
      path: "/v1/traces"
  processor:
    - trace_peer_forwarder:
  sink:
    - pipeline:
        name: "span-pipeline"
    - pipeline:
        name: "service-map-pipeline"
span-pipeline:
  source:
    pipeline:
      name: "entry-pipeline"
  processor:
    - otel_traces:
  sink:
    - opensearch:
        index_type: "trace-analytics-raw"
        hosts: ["your-opensearch-endpoint"]
        aws:                  
          sts_role_arn: "arn:aws:iam::your-account:role/blog-osi-pipeline-role"
          region: "us-east-1"
service-map-pipeline:
  source:
    pipeline:
      name: "entry-pipeline"
  processor:
    - service_map:
  sink:
    - opensearch:
        index_type: "trace-analytics-service-map"
        hosts: ["your-opensearch-endpoint"]
        aws:                  
          sts_role_arn: "arn:aws:iam::your-account:role/blog-osi-pipeline-role"
          region: "us-east-1"

第三步：通过 OpenSearch Cluster 2.17 建立仪表盘进行可观测性

在 OpenSearch 中，您可以创建各种可视化图表来可视化我们的数据，进而全面了解应用程序的性能和运行状况。这边我们着重介绍一下 Query Assistant 和 TSVB 图表。

3.1 使用 Query Assistant 创建图表

作为 OpenSearch Assistant Toolkit 的一部分，Query Assistant 将人工智能的力量引入数据分析领域，使得复杂的查询变得简单直观。Query Assistant 的核心功能在于它能够将自然语言转换为精确的 PPL（Piped Processing Language）查询。用户只需用日常语言描述他们想要的数据视图，例如“获取过去 24 小时内各服务的 95 百分位延迟”，Query Assistant 就能自动生成相应的 PPL 查询。这一功能不仅大大降低了使用门槛，还显著提高了数据分析的效率。

除了查询转换，Query Assistant 还提供了直观的可视化配置界面。用户可以轻松选择要显示的字段、设置图表类型，并调整各种视觉元素如颜色、字体和布局。这意味着从数据提取到可视化呈现，整个过程都可以在一个统一的界面中完成。

3.2 创建 TSVB（Time Series Visual Builder）图表

通过 TSVB（Time Series Visual Builder）图表，你可以很容易地创建时间序列数据的分析和展示。它允许用户创建复杂的可视化，而无需编写复杂的查询。TSVB 特别适合于展示系统性能指标、业务 KPI、趋势分析等时间相关的数据。

3.3 组合可视化图表，创建仪表盘展示关键指标

创建好各种可视化图表后，您可以将它们组合到一个或多个仪表板中，在下面的示例仪表盘中，我们可以看到多个关键指标的展示：

顶部展示了各个服务的请求数量统计，如数据库、订单、分析服务等。右侧的仪表盘显示了不同服务的延迟百分位数，用颜色编码表示性能状况。中间的面积图展示了一段时间内各服务请求量的变化趋势。底部左侧的热力图可视化了 Service 和 TraceGroup 的调用关系和数量，而右侧的堆叠面积图则展示了一段时间内主要服务延迟的变化。

用户可以通过这个仪表盘快速识别性能瓶颈、异常模式和服务依赖关系。例如，通过仪表盘可以发现哪些服务延迟较高，哪些服务调用频繁，以及整体系统负载的变化趋势。用户还可以根据需要调整时间范围，深入分析特定时段的数据。这种可视化方式大大提高了问题诊断和性能优化的效率，是构建现代可观测性平台的重要组成部分。

第四步：通过 OpenSearch Cluster 2.17 Observability 进行一体化可观测性

OpenSearch Observability 通过整合 Metric、Log 和 Trace 这三大基础可观测性信号，为您呈现统一的可观测性体验。您无需在不同工具间切换，即可实时关注指标、审查相关日志、追踪请求流，快速隔离和诊断问题。强大的交互式探索和关联分析功能，进一步提升了故障排查效率，高效地发现和修复问题、提升应用程序健康状况。

在复杂的微服务架构中，单个用户请求往往需要跨越多个服务和基础设施层。OpenSearch Observability 通过对 ADOT 等开放标准的支持，使您能够对请求的整个生命周期进行端到端的追踪，精确定位性能瓶颈和故障根源。您还可以直观地查看服务间的依赖关系，识别潜在的架构风险。

以下是 Observability 的使用步骤：

在 OpenSearch 左方导航 Observability 下点击 Application，并且创建 Application，填写 Application 名字以及 index。

展开“服务和实体”部分，选择以下所有服务：order、analytics-service、frontend-client、database、authentication、inventory、payment 和 recommendation，将它们包含在示例应用程序中以便进行调查。

创建完毕后打开 Sample Application。

在 Service 选项卡中，有一个服务列表视图，这个视图根据 HTTP 方法和路径将追踪数据分组，因此您可以看到与特定操作相关的平均延迟、错误率和趋势。这个视图提供了非常有用的信息，可以帮助您快速了解应用程序的整体性能情况。通过查看不同操作的平均延迟，您可以轻松发现哪些操作可能存在性能瓶颈。错误率指标则可以揭示潜在的可靠性问题。此外，随着时间的推移，您还可以关注趋势的变化，提前发现性能恶化的迹象。除了整体视图，您还可以通过应用程序组成图，清楚地看到服务之间的依赖关系和调用流程。这对于理解应用程序的架构和潜在瓶颈非常有帮助。

这两个视图相辅相成，为我们提供了应用程序可观测性的多角度分析。服务列表视图让我们聚焦于单个服务的关键指标，而应用程序组成图则展示了服务间的整体拓扑结构。通过结合使用这两种视图，我们就能够全面洞察应用程序的健康状况和性能特征。例如，如果我们在服务列表中发现某个服务的延迟或错误率异常，就可以进一步查看组成图，了解这个服务与其他服务的关系，进而定位问题的根源。

进入 Traces & Spans 选项卡中，我们可以看到各个请求的端到端追踪信息。这个视图不仅展示了整个调用流程，还提供了每个服务调用的详细时间信息。

要深入分析某个特定的请求，我们只需点击其对应的“Trace ID”。这将打开一个新页面，展示该请求的完整追踪细节。

在这个追踪详情视图中，我们可以看到它提供了一个 Trace 的详细视图，让我们能够洞察整个请求过程中各个服务和操作的耗时情况。

在顶部，它显示了这个 Trace 的一些基本信息，如 TraceId、Trace group name、总耗时（Latency）以及是否存在错误（Errors）。

接下来是一个环形图，直观展示了该 Trace 中每个服务的耗时占比。我们可以清晰地看到 order 服务和 frontend-client 服务占据了大部分时间，而 database 和 analytics-service 的耗时则相对较少。

在下面的时间线视图中，我们可以详细查看每个服务中各操作的时间消耗。每个操作都用一条横条代表，条形长度对应其耗时。通过这个视图，我们一眼可以分析出耗时最长的几个关键步骤，如 frontend-client 的 client.delivery.status 操作、order 服务的 /get_order 操作等。

通过这个追踪详情视图，我们可以全面了解某个特定请求的端到端执行状况。这不仅有助于发现性能问题的根源，还能帮助我们理解应用程序的整体架构和服务依赖关系。

例如，如果我们发现某个请求在特定服务上存在严重延迟，就可以进一步查看该服务的内部实现细节，并结合其他监控数据来诊断问题所在。这种细粒度的分析能力是 OpenSearch Observability 的一大亮点。

四. 总结

随着数字化转型的不断深入，可观测性已经成为确保现代应用程序和基础设施健康运行的关键所在。通过 ADOT 和 OpenSearch 构建的一体化可观测性平台，我们不仅能更快速地发现和修复问题，还能持续优化系统性能，为终端用户提供卓越的数字体验。

这种全面的可观测性能力对于驱动业务价值至关重要。它使我们能够深入洞察系统行为，主动发现潜在风险，并依据数据做出更明智的决策。随着 IT 环境的日益复杂，仅依靠传统监控工具已远远不够，我们必须拥抱可观测性这一现代化的管理方法。

通过本文的介绍，相信您已经掌握了构建 ADOT 和 OpenSearch 可观测性平台的关键步骤。现在是时候开始您自己的探索之旅了。相信只要您充分利用这些强大的工具和功能，就一定能够提升应用程序的可靠性，优化系统性能，最终为您的组织带来持续的价值。

如果您对本文有任何意见和建议，请与我们分享！

亚马逊AWS官方博客