使用 OpenTelemetry 进行检测的最佳实践

OpenTelemetry (OTel) 正在稳步获得业界的广泛采用。作为云原生计算基金会 (CNCF) 的主要项目之一，其提交次数与 Kubernetes 一样多，它正在获得主要独立软件供应商和云提供商的支持，为该框架提供支持。来自金融、保险、科技和其他行业的许多全球公司开始将 OpenTelemetry 作为标准。借助 OpenTelemetry，DevOps 团队可以使用一致的方法来收集和摄取遥测数据，为可观测性提供事实上的标准。这样，团队可以依赖于与供应商无关、面向未来的应用程序检测，这使他们可以在不增加调整检测开销的情况下切换可观测性后端。

选择 OpenTelemetry 进行检测的团队面临着不同的检测技术和数据收集方法的选择。确定如何检测以及使用哪种机制可能具有挑战性。在本博客中，我们将介绍 Elastic 针对 OpenTelemetry 检测的一些最佳实践的建议

自动还是手动？我们将介绍两者之间的需求，并根据您的情况提供建议。
从收集器还是直接从应用程序？虽然传统的选项是使用收集器，但诸如 Elastic 可观测性之类的可观测性工具可以直接从 OpenTelemetry 应用程序获取遥测数据。
从 OTel SDK 检测什么。跟踪和指标得到了很好的贡献（根据 OTel 文档中的表），但日志仍在进行中。Elastic^® 正在通过其将 ECS 贡献给 OTel 来改进进度。无论 OTel 的状态如何，您都需要测试并确保这些检测对您有效。
OpenTelemetry 的优缺点

OTel 自动或手动检测：我应该使用哪一个？

虽然有两种使用 OpenTelemetry 检测应用程序的方法 — 自动和手动 — 但没有完美的答案，因为它取决于您的需求。使用一种方法而不是另一种方法有优缺点，例如

自动魔术体验与控制检测
自定义与开箱即用的数据
检测开销
简单性与灵活性

此外，您甚至可能根据可用性和需求选择组合。

让我们回顾一下自动和手动检测，并探讨具体的建议。

自动检测

对于大多数编程语言和运行时，OpenTelemetry 提供了一种用于收集遥测数据的自动检测方法。自动检测为众所周知的框架和库提供了一组预定义的、开箱即用的检测模块。这样，用户只需进行极少甚至无需代码更改，即可从其应用程序使用的众所周知的框架和库中收集遥测数据（例如跟踪、指标和日志）。

以下是使用自动检测的一些明显好处

更快的开发和生产路径。自动检测通过加速将遥测集成到应用程序中的过程来节省时间，从而可以将更多精力放在其他关键任务上。
通过仅更新一行（通常是配置自动检测的容器启动命令），而不是更新多个类、方法和服务中的多行代码，从而简化维护。
更容易跟上 OpenTelemetry 项目中的最新功能和改进，而无需手动更新使用的库和/或代码的检测。

自动检测方法也有一些缺点和限制

自动检测仅收集明确存在自动检测模块的正在使用的框架和库的遥测数据。特别是，自动检测不太可能收集“异类”或自定义库的遥测数据。
自动检测不会捕获纯自定义代码的遥测数据（该代码不使用下面的众所周知的库）。
自动检测模块带有预定义的、固定的检测逻辑，该逻辑在绝大多数情况下提供足够且有意义的信息。但是，在某些自定义边缘情况下，自动检测模块提供的数据的信息值、结构或详细程度可能不足。
根据运行时、技术和目标应用程序的大小，与手动检测相比，自动检测可能会带来（稍微）更高的启动或运行时开销。在大多数情况下，这种开销可以忽略不计，但在某些边缘情况下可能会成为问题。

此处是一个使用 OpenTelemetry 自动检测的 Python 应用程序的示例。如果您在本地有一个 Python 应用程序，则可以添加以下代码以进行自动检测

opentelemetry-instrument \
    --traces_exporter OTEL_TRACES_EXPORTER \
    --metrics_exporter OTLP_METRICS_EXPORTER \
    --service_name OTLP_SERVICE_NAME \
    --exporter_otlp_endpoint OTEL_EXPORTER_TRACES_ENDPOINT \
    python main.py

了解有关使用 OpenTelemetry 对 Python 应用程序进行自动检测的更多信息.

最后，熟悉 OpenTelemetry API 的开发人员可以通过使用自动检测来利用他们现有的知识，从而避免手动检测可能引起的复杂性。但是，对于特定用例或当自定义需求无法通过自动检测完全解决时，可能仍然首选手动检测。

组合：自动和手动

在我们继续进行手动检测之前，您还可以使用自动和手动检测的组合。正如我们在上面指出的，如果您开始了解应用程序的行为，那么您可以确定是否需要对自动检测未跟踪的代码进行一些额外的检测。

此外，由于并非所有自动检测在整个 OTel 语言集中都是相同的，因此在某些情况下您可能需要手动检测 — 例如，如果基于 Flask 的 Python 应用程序的自动检测不会自动显示中间件调用，例如对请求库的调用。在这种情况下，如果您还想查看中间件跟踪，则必须对 Python 应用程序进行手动检测。但是，随着这些库的成熟，将会有更多的支持选项可用。

当应用程序接近生产质量时，大多数开发人员最终都会选择组合方式。

手动检测

如果自动检测不能满足您的需求，您想要更好地控制检测，或者您希望将检测视为代码，那么使用手动检测可能是您的正确选择。如上所述，您可以将其用作对自动检测的增强，或者完全切换到手动检测。如果您最终走上手动检测的道路，它肯定会提供更大的灵活性，但也意味着您不仅必须在跟踪和指标中编写代码，还必须定期维护它。

随着新功能的添加和库的更改，代码的维护可能很麻烦，也可能不麻烦。这是一个需要一些预先考虑的决定。

以下是一些您可能会使用手动检测的原因

您可能已经有一些使用自动检测进行 OTel 检测的应用程序，并且需要为特定函数或库（例如数据库或中间件）添加更多遥测数据，因此您必须添加手动检测。
在应用程序语言和您想要检测的内容方面，您需要更高的灵活性和控制权。
如果您的编程语言和所使用的技术没有可用的自动检测，那么对于使用这些语言构建的应用程序，手动检测将是您的选择。
您可能需要使用替代方法进行日志记录检测，因为日志记录对于所有编程语言来说还不是稳定的。
您需要为特定用例自定义和丰富您的遥测数据 — 例如，您有一个多租户应用程序，并且您需要获取每个租户的信息，然后通过 OpenTelemetry SDK 进行手动检测。

手动检测的建议
手动检测需要特定的配置，以确保您在使用 OTel 时获得最佳体验。以下是 Elastic 的建议（如 CNCF 所概述），以便在使用手动方法进行检测时获得最大收益

确保您的提供程序配置和跟踪器初始化已正确完成。
确保在所有要跟踪的函数中都设置了 span。
正确设置资源属性。
使用批量处理而不是简单处理。

让我们逐一回顾这些内容

1. 确保您的提供程序配置和跟踪器初始化已正确完成。
一般的经验法则是确保在应用程序的前端配置所有变量和跟踪器初始化。以 Elastiflix 应用程序的 Python favorite 服务为例，我们可以看到

跟踪器被全局设置

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.resources import Resource

...


resource = Resource.create(resource_attributes)

provider = TracerProvider(resource=resource)
processor = BatchSpanProcessor(exporter)
provider.add_span_processor(processor)

# Sets the global default tracer provider
trace.set_tracer_provider(provider)

# Creates a tracer from the global tracer provider
tracer = trace.get_tracer(otel_service_name)

在上面，我们添加了 OpenTelemetry 跟踪模块并导入了 TraceProvider，它是 API 的入口点。它提供了对 Tracer 的访问，Tracer 是负责创建 span 的类。

此外，我们指定使用 BatchSpanProcessor。span 处理器是一个接口，它为 span 的开始和结束方法调用提供钩子。

在 OpenTelemetry 中，提供了不同的 span 处理器。BatchSpanProcessor 批量处理 span 并批量发送它们。可以使用 MultiSpanProcessor 配置多个 span 处理器同时处于活动状态。请参阅 OpenTelemetry 文档。

变量 otel_service_name 使用环境变量设置（即，OTLP ENDPOINT 和其他变量）也全局设置。请参见下文

otel_service_name = os.environ.get('OTEL_SERVICE_NAME') or 'favorite_otel_manual'
environment = os.environ.get('ENVIRONMENT') or 'dev'
otel_service_version = os.environ.get('OTEL_SERVICE_VERSION') or '1.0.0'

otel_exporter_otlp_headers = os.environ.get('OTEL_EXPORTER_OTLP_HEADERS')
otel_exporter_otlp_endpoint = os.environ.get('OTEL_EXPORTER_OTLP_ENDPOINT')

在上面的代码中，我们初始化了几个变量。因为我们还导入了 Resource，所以我们初始化了几个变量

资源变量（我们将在本文后面介绍）

otel_service_name – 这有助于在 otel 资源属性中设置服务的名称 (service.name)。
otel_service_version – 这有助于在 OTel 资源属性中设置服务的版本 (service.version)。
environment – 这有助于在 OTel 资源属性中设置 deployment.environment 变量。

导出器变量

otel_exporter_otlp_endpoint – 这有助于设置 OTLP 端点，用于发送跟踪、日志和指标。Elastic 将是一个 OTLP 端点。如果您只想将跟踪和/或指标发送到特定端点，您还可以使用 OTEL_TRACES_EXPORTER 或 OTEL_METRICS_EXPORTER。
Otel_exporter_otlp_headers – 这是端点所需的授权。

提供程序和跟踪器配置的分离使您可以使用您选择的任何 OpenTelemetry 提供程序和跟踪框架。

2. 在应用程序函数本身内部设置您的 span。
确保您的 span 结束并且处于正确的上下文中，以便您可以跟踪 span 之间的关系。在我们的 Python favorite 应用程序中，检索用户最喜欢的电影的函数显示了

@app.route('/favorites', methods=['GET'])
def get_favorite_movies():
    # add artificial delay if enabled
    if delay_time > 0:
        time.sleep(max(0, random.gauss(delay_time/1000, delay_time/1000/10)))

    with tracer.start_as_current_span("get_favorite_movies") as span:
        user_id = str(request.args.get('user_id'))

        logger.info('Getting favorites for user ' + user_id, extra={
            "event.dataset": "favorite.log",
            "user.id": request.args.get('user_id')
        })

        favorites = r.smembers(user_id)

        # convert to list
        favorites = list(favorites)
        logger.info('User ' + user_id + ' has favorites: ' + str(favorites), extra={
            "event.dataset": "favorite.log",
            "user.id": user_id
        })
        return { "favorites": favorites}

虽然您可以检测每个函数，但强烈建议您检测需要的内容，以避免数据泛滥。这种需求不仅取决于开发过程的需要，还取决于 SRE 以及潜在的业务需要观察应用程序的内容。为您的目标用例进行检测。

此外，请避免检测微不足道/实用方法/函数或旨在广泛调用的函数（例如，getter/setter 函数）。否则，这将产生大量的遥测数据，而附加值非常低。

3. 设置资源属性并使用语义约定

_ 资源属性 _
诸如 service.name、tracer、development.environment 和 cloud 等属性对于管理特定服务的版本、环境、云提供商等非常重要。资源属性描述了主机、系统、进程和服务等资源，并且在资源的生命周期内不会更改。资源属性对于关联数据、为遥测数据提供额外上下文，从而帮助缩小故障排除期间的问题根本原因非常有帮助。虽然在自动检测中设置很简单，但您需要确保也在您的应用程序中发送这些属性。

查看 OpenTelemetry 的属性列表，这些属性可以在 OTel 文档中设置。

在我们上面自动检测的 Python 应用程序中，以下是我们如何设置资源属性

opentelemetry-instrument \
    --traces_exporter console,otlp \
    --metrics_exporter console \
    --service_name your-service-name \
    --exporter_otlp_endpoint 0.0.0.0:4317 \
    python myapp.py

但是，在手动检测时，您需要添加资源属性，并确保在应用程序代码中具有一致的值。资源属性已由 OpenTelemetry 的资源语义约定定义，可以在这里找到。事实上，您的组织应该有一个资源属性约定，该约定适用于所有应用程序。

这些属性将添加到您的指标、跟踪和日志中，帮助您过滤数据、关联数据并使其更有意义。

以下是在我们的 Python 服务中设置资源属性的示例

resource_attributes = {
    "service.name": otel_service_name,
    "telemetry.version": otel_service_version,
    "Deployment.environment": environment

}

resource = Resource.create(resource_attributes)

provider = TracerProvider(resource=resource)

我们设置了 service.name、service.version 和 deployment.environment。您可以根据需要设置任意数量的资源属性，但您需要确保使用 provider = TracerProvider(resource=resource) 将资源属性传递到跟踪器中。

_ 语义约定 _
除了向代码添加适当的资源属性外，OpenTelemetry 语义约定也很重要。另一个是关于使用特定基础架构构建应用程序中使用的特定技术的语义约定。例如，如果您需要检测数据库，则没有自动检测。您必须手动检测对数据库的跟踪。在执行此操作时，您应该利用 OpenTelemetry 中数据库调用的语义约定。

同样，如果您尝试跟踪 Kafka 或 RabbitMQ，您可以遵循消息传递系统的 OpenTelemetry 语义约定。

OpenTelemetry 可以在多个领域和信号类型中遵循多种语义约定 — 查看详细信息。

4. 使用批量处理还是简单处理？
使用简单处理还是批量处理取决于您的特定可观测性要求。批量处理的优点包括提高效率和减少网络开销。批量处理允许您批量处理遥测数据，从而更有效地处理数据和利用资源。另一方面，批量处理会增加遥测数据在后端显示的时间延迟，因为 span 处理器需要等待足够的数据量才能发送到后端。

通过简单处理，您会在生成数据后立即发送遥测数据，从而实现实时可观测性。但是，您需要为更高的网络开销和处理所有单独数据传输所需的更多资源做好准备。

以下是我们用于在 Python 中进行此设置的代码

from opentelemetry.sdk.trace.export import BatchSpanProcessor

provider = TracerProvider(resource=resource)
processor = BatchSpanProcessor(exporter)
provider.add_span_processor(processor)

# Sets the global default tracer provider
trace.set_tracer_provider(provider)

当选择批量处理还是简单处理时，您的可观测性目标和预算限制是决定因素。也可以实施混合方法。例如，如果实时洞察对于电子商务应用程序至关重要，那么简单处理将是更好的方法。对于其他实时洞察并不重要的应用程序，请考虑批量处理。通常，尝试这两种方法并查看您的可观测性后端如何处理数据是一种富有成效的练习，可以找出最适合业务的方法。

使用 OpenTelemetry 收集器还是直接发送？

当开始使用 OpenTelemetry 时，将遥测数据直接摄取和传输到后端（如 Elastic）是一个很好的入门方式。通常，您会在开发阶段和本地环境中使用 OTel 直接方法。

但是，当您将应用程序部署到生产环境时，应用程序将完全负责摄取和发送遥测数据。与生产环境相比，在本地环境或开发期间发送的数据量将微不足道。随着数百万甚至数十亿用户与您的应用程序交互，除了核心应用程序功能之外，摄取和发送遥测数据的工作可能会消耗大量资源。因此，使用供应商无关的 OTel 收集器将遥测数据的收集、处理和导出卸载到后端（如 Elastic），将使您的应用程序能够更有效地运行，从而带来更好的客户体验。

使用 OpenTelemetry 收集器的优势

对于云原生和基于微服务的应用程序，OpenTelemetry 收集器提供了处理多种数据格式的灵活性，更重要的是，它将管理遥测数据所需的资源从应用程序中卸载。结果是：降低了应用程序开销，并且简化了管理，因为现在可以在一个地方管理遥测配置。

OTel 收集器是最常见的配置，因为使用了 OTel 收集器

使用额外的上下文信息来丰富遥测数据 — 例如，在 Kubernetes 上，OTel 收集器将负责使用相应的 K8s pod 和节点信息（标签、pod 名称等）来丰富所有遥测数据
在中心位置（即 OTel 收集器）提供统一和一致的处理或转换遥测数据，而不是承担在数百个服务之间同步配置以确保一致处理的负担
聚合服务的多个实例的指标，这只能在 OTel 收集器上完成（而不是在单个 SDK/代理中）

OpenTelemetry 收集器的主要功能包括

设置简单：设置文档清晰全面。我们还有一个使用 Elastic 和 OTel 收集器的示例设置，该设置记录在此博客中。
灵活性： OTel Collector 提供了许多配置选项，使您可以轻松集成到现有的可观测性解决方案中。但是，OpenTelemetry 的预构建发行版使您可以快速上手并构建所需的功能。这里以及下面是我们在 Kubernetes 上运行的应用程序构建 Collector 时使用的代码示例。

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: otelcollector
spec:
  selector:
    matchLabels:
      app: otelcollector
  template:
    metadata:
      labels:
        app: otelcollector
    spec:
      serviceAccountName: default
      terminationGracePeriodSeconds: 5
      containers:
        - command:
            - "/otelcol"
            - "--config=/conf/otel-collector-config.yaml"
          image: otel/opentelemetry-collector:0.61.0
          name: otelcollector
          resources:
            limits:
              cpu: 1
              memory: 2Gi
            requests:
              cpu: 200m
              memory: 400Mi

收集主机指标： 使用 OTel Collector 可以捕获基础设施指标，包括 CPU、RAM、存储容量等。这意味着您无需安装单独的基础设施代理来收集主机指标。下面是用于摄取主机指标的 OTel 配置示例。

receivers:
  hostmetrics:
    scrapers:
      cpu:
      disk:

安全性： OTel Collector 默认以安全方式运行。它可以根据您的配置过滤掉敏感信息。OpenTelemetry 提供了这些安全指南，以确保满足您的安全需求。
分布式追踪的尾部采样： 通过 OpenTelemetry，您可以指定用于捕获追踪的采样策略。尾部采样默认在 OTel Collector 中可用。使用尾部采样，您可以控制并减少收集的追踪数据量。更重要的是，您可以捕获最相关的追踪，从而更快地发现微服务应用程序中的问题。

日志呢？

OpenTelemetry 摄取指标和追踪的方法是“全新设计”。 OTel 为指标和追踪开发了新的 API，并为多种语言提供了实现。另一方面，对于日志，由于遗留日志解决方案和库的广泛采用和存在，OTel 的支持是最不成熟的。

目前，OpenTelemetry 的日志解决方案是提供与现有解决方案的集成钩子。不过，从长远来看，OpenTelemetry 的目标是将上下文聚合与日志结合起来，从而简化日志与指标和追踪的相关性。了解更多关于 OpenTelemetry 愿景的信息。

Elastic 在以下文章中撰写了其建议：使用 OpenTelemetry 和 Elastic 进行日志记录的 3 种模型。以下是 Elastic 建议的简要概述：

使用嵌入式 OpenTelemetry Instrumentation 库，通过 OTLP 协议从您的服务（以及追踪和指标）输出日志到 Elastic。
将服务的日志写入由 OpenTelemetry Collector 抓取的文件，然后通过 OTLP 协议转发到 Elastic。
将服务的日志写入由 Elastic Agent（或 Filebeat）抓取的文件，然后通过 Elastic 定义的协议转发到 Elastic。

第三种方法，即开发人员使用 Elastic Agent 抓取日志，是推荐的方法，因为 Elastic 提供了一种广泛采用且经过验证的方法，可以使用 OTel 从应用程序和服务中捕获日志。前两种方法虽然都使用 OTel instrumentation，但尚未成熟，不适用于生产级应用程序。

在这篇Elastic 博客中获取有关这三种方法的更多详细信息，其中包括有关动手实施、架构、优点和缺点的深入讨论。

并非一切都一帆风顺

OpenTelemetry 对于为现代云原生分布式应用程序获取可观测性绝对有益。拥有用于摄取遥测数据的标准化框架可降低运营费用，并使组织能够更加专注于应用程序创新。即使使用 OTel 有诸多优点，您也应该意识到一些限制。

但首先，以下是使用 OpenTelemetry 的优点：

标准化检测： 在堆栈上下使用一致的方法来检测系统，可以提高组织的运营效率和具有成本效益的可观测性。
自动检测： OTel 为组织提供了自动检测常用库和框架的能力，使他们能够快速启动并运行，并且只需对代码库进行最少的更改。
供应商中立： 组织不必将其可观测性需求绑定到一个供应商。事实上，他们可以使用多个供应商，使用 OTel 来尝试一种供应商，或者如果需要，可以采用更优化的方法。
面向未来的检测： 由于 OpenTelemetry 是开源的，并且拥有庞大的支持生态系统，您的组织将使用不断创新的技术，并且可以随着业务扩展和增长。

也存在一些限制：

使用 OTel 进行检测是一次彻底的升级。组织必须意识到需要投入时间和精力将专有检测迁移到 OpenTelemetry。
语言 SDK 处于不同的成熟度级别，因此具有 alpha、beta 或实验性功能支持的应用程序可能无法在短期内为组织提供全部优势。

随着时间的推移，缺点会减少，尤其是在功能组件的成熟度提高时。查看OpenTelemetry 状态页面，了解有关语言 SDK、收集器和整体规范状态的更新。

以您自己的速度使用 Elastic 并迁移到 OpenTelemetry

对于大多数组织来说，过渡到 OpenTelemetry 是一项挑战，因为它需要几乎在所有应用程序上重新调整现有的专有 APM 代理。这可能令人生畏，但 OpenTelemetry 代理提供了一种机制来避免必须修改源代码，也称为自动检测。使用自动检测，唯一的代码更改将是删除专有的 APM 代理代码。此外，您还应确保您拥有原生支持 OTel 的可观测性工具，而无需额外的代理，例如 Elastic Observability。

Elastic 最近将其完整的 Elastic Common Schema (ECS) 捐赠给了 OTel。目标是确保 OTel 可以获得标准化的日志记录格式。ECS 是 Elastic 社区在过去几年中开发的，它提供了一种工具，使 OTel 能够提供更成熟的日志记录解决方案。

Elastic 提供原生的 OTel 支持。您可以直接将 OTel 遥测数据发送到 Elastic Observability，而无需收集器或通常在收集器中使用的任何类型的处理。

以下是 Elastic 中用于 OpenTelemetry 的配置选项：

大多数 Elastic Observability 的 APM 功能都适用于 OTel 数据。其中一些包括：

服务地图
服务详细信息（延迟、吞吐量、失败的事务）
服务之间的依赖关系、分布式追踪
事务（追踪）
机器学习 (ML) 相关性
日志相关性

除了 Elastic 的 APM 和遥测数据的统一视图之外，您还可以使用 Elastic 强大的机器学习功能来减少分析和警报，以帮助减少 MTTR。

虽然 OpenTelemetry 支持多种编程语言，但其主要功能组件（指标、追踪和日志）的状态仍处于不同阶段。因此，迁移用 Java、Python 和 JavaScript 编写的应用程序是一个不错的选择，因为它们的指标、追踪和日志（对于 Java）是稳定的。

对于其他尚未支持的语言，您可以轻松地使用 Elastic Agent 对其进行检测，从而以混合模式运行您的可观测性平台（Elastic Agent 与 OpenTelemetry 代理）。

我们运行了一个标准 Elastic Agent 应用程序的变体，其中一项服务切换到了 OTel — newsletter-otel 服务。但是，我们可以根据开发资源的允许，轻松地按需将这些服务中的每一个都转换为 OTel。

因此，您可以利用 OpenTelemetry 的优势，其中包括：

标准化： OpenTelemetry 提供了一种标准的遥测数据收集方法，从而实现流程的一致性并更容易集成不同的组件。
与供应商无关： 由于 OpenTelemetry 是开源的，因此它被设计为与供应商无关，允许 DevOps 和 SRE 团队与其他监控和可观测性后端一起工作，从而减少供应商锁定。
灵活性和可扩展性： 凭借其灵活的架构和固有的可扩展性设计，OpenTelemetry 使团队能够创建自定义检测并丰富他们自己的遥测数据。
社区和支持： OpenTelemetry 拥有不断增长的贡献者和采用者社区。事实上，Elastic 为开发指标、日志、追踪和安全事件的通用模式做出了贡献。请在此处了解更多信息。

一旦其他语言达到稳定状态，您就可以继续迁移到 OpenTelemetry 代理。

摘要

OpenTelemetry 已成为从云原生应用程序摄取指标、追踪和日志的事实标准。它提供了一个与供应商无关的框架来收集遥测数据，使您能够使用您选择的可观测性后端。

使用 OpenTelemetry 的自动检测是您摄取遥测数据的最快方法，也是开始使用 OTel 的最佳方法。但是，使用手动检测可以提供更大的灵活性，因此通常是深入了解遥测数据的下一步。

OpenTelemetry 可视化还允许您直接或使用 OTel Collector 摄取数据。对于本地开发，直接发送是将数据发送到可观测性后端的好方法；但是，对于生产工作负载，建议使用 OTel Collector。收集器负责所有数据摄取和处理，使您的应用程序能够专注于功能，而不必处理任何遥测数据任务。

使用 OpenTelemetry，日志功能仍处于起步阶段，而摄取指标和追踪则已建立。对于日志，如果您已开始使用 OTel，则可以使用 OTLP 协议将日志发送到 Elastic。由于 Elastic 具有非常成熟的日志记录解决方案，因此更好的方法是使用 Elastic Agent 来摄取日志。

虽然长期利益很明显，但组织需要意识到采用 OpenTelemetry 意味着他们将拥有自己的检测。因此，需要在开发生命周期中纳入适当的资源和精力。然而，随着时间的推移，OpenTelemetry 为遥测数据摄取带来了标准化，为组织提供了供应商选择、可扩展性、灵活性和面向未来的投资。

本文中描述的任何功能或特性的发布和时间安排均由 Elastic 自行决定。任何当前不可用的功能或特性可能不会按时交付或根本不会交付。