Observability：检测 OpenTelemetry 的推荐指南

本文主要是介绍Observability：检测 OpenTelemetry 的推荐指南，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：Bahubali Shetti

OpenTelemetry (OTel) 正在稳步获得广泛的行业采用。作为主要的云原生计算基金会 (CNCF) 项目之一，其提交数量与 Kubernetes 一样多，它正在获得主要 ISV 和云提供商的支持，为该框架提供支持。许多来自金融、保险、科技和其他行业的全球公司开始对 OpenTelemetry 进行标准化。借助 OpenTelemetry，DevOps 团队可以采用一致的方法来收集和摄取遥测数据，从而提供事实上的可观测性标准。这样，团队就可以依赖与供应商无关的、面向未来的应用程序工具，使他们能够切换可观察性后端，而无需在调整工具方面产生额外的开销。

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

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

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

虽然有两种方法可以使用 OpenTelemetry 来检测你的应用程序（自动和手动），但没有完美的答案，因为这取决于你的需求。使用一种方法与另一种方法各有利弊，例如：

自动魔法体验 vs 对检测的控制
定制 vs 开箱即用的数据
仪表开销
简单性 vs 灵活性

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

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

自动检测

对于大多数编程语言和运行时，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 for Python 应用程序进行自动检测的更多信息。

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

组合：自动和手动

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

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

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

手动检测

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

随着新功能的添加和库的更改，代码的维护可能会或可能不会很麻烦。这是一个需要深思熟虑的决定。

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

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

手动检测的建议

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

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

让我们分别回顾一下：

1) 确保您的提供程序配置和跟踪器初始化正确完成。

一般的经验法则是确保在应用程序的前面配置所有变量和跟踪器初始化。以 Elastiflix 应用程序的 Python 最喜欢的服务为例，我们可以看到：

正在全局范围内设置 Tracer

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 中，提供了不同的跨度处理器。 BatchSpanProcessor 批量处理跨度并批量发送它们。使用 MultiSpanProcessor 可以将多个跨度处理器配置为同时处于活动状态。请参阅 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 资源属性中的部署环境变量。

exporter 变量：

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

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

2) 在应用程序函数本身内设置跨度。

确保你的跨度结束并处于正确的上下文中，以便你可以跟踪跨度之间的关系。在我们的 Python 最喜欢的应用程序中，检索用户最喜欢的电影的函数显示：

@app.route('/favorites', methods=['GET'])
def get_favorite_movies():# add artificial delay if enabledif 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 listfavorites = 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 等属性对于管理版本、环境、云提供商等非常重要。对于特定的服务。资源属性描述主机、系统、进程和服务等资源，并且在资源的生命周期内不会更改。资源属性对于关联数据、为遥测数据提供额外的上下文非常有帮助，从而有助于在故障排除期间缩小问题的根本原因。虽然在自动仪器中设置很简单，但你需要确保也在你的应用程序中发送这些内容。

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

在上面的自检测 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）使用 Batch 还是简单处理？

使用简单处理或批处理取决于你特定的可观测性要求。批处理的优点包括提高效率和减少网络开销。批处理允许你批量处理遥测数据，从而实现更高效的数据处理和资源利用。另一方面，批处理增加了遥测数据出现在后端的延迟时间，因为跨度处理器需要等待足够量的数据发送到后端。

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

以下是我们在 Python 中进行设置的内容：

from opentelemetry.sdk.trace.export import BatchSpanProcessorprovider = TracerProvider(resource=resource)
processor = BatchSpanProcessor(exporter)
provider.add_span_processor(processor)# Sets the global default tracer provider
trace.set_tracer_provider(provider)

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

使用 OpenTelemetry Collector 还是直接使用？

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

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

使用 OpenTelemetry Collector 的优点

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

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

为了使用额外的上下文信息来丰富遥测数据 - 例如，在 Kubernetes 上，OTel Collector 将负责使用相应的 K8s Pod 和节点信息（标签、Pod 名称等）来丰富所有遥测数据。
在中央位置（即 OTel Collector）提供统一一致的处理或转换遥测数据，而不是承担跨数百个服务同步配置的负担，以确保一致的处理
跨服务的多个实例聚合指标，这仅在 OTel Collector 上可行（不适用于单个 SDK/代理）

OpenTelemetry Collector 的主要功能包括：

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

---          
apiVersion: apps/v1
kind: Deployment
metadata:name: otelcollector
spec:selector:matchLabels:app: otelcollectortemplate:metadata:labels:app: otelcollectorspec:serviceAccountName: defaultterminationGracePeriodSeconds: 5containers:- command:- "/otelcol"- "--config=/conf/otel-collector-config.yaml"image: otel/opentelemetry-collector:0.61.0name: otelcollectorresources:limits:cpu: 1memory: 2Girequests:cpu: 200mmemory: 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 检测，但尚未成熟，尚未准备好用于生产级应用。

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

并不全是阳光和玫瑰

OpenTelemetry 绝对有利于获得现代云原生分布式应用程序的可观察性。拥有用于获取遥测数据的标准化框架可以降低运营费用，并使组织能够更加专注于应用程序创新。尽管使用 OTel 具有所有优势，但您也应该注意一些限制。

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

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

也有一些限制：

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

随着时间的推移，缺点将会减少，特别是随着功能组件成熟度的提高。检查 OpenTelemetry 状态页面，了解语言 SDK、收集器和总体规范的状态更新。

使用 Elastic 并按照你的速度迁移到 OpenTelemetry

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

Elastic 最近将 Elastic Common Chema (ECS) 全部捐赠给 OTel。目标是确保 OTel 能够采用标准化的日志记录格式。 Elastic 社区在过去几年中开发的 ECS 提供了一种工具，使 OTel 能够提供更成熟的日志记录解决方案。

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

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

Elastic Observability 的大部分 APM 功能均可通过 OTel 数据使用。其中一些包括：

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

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

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

对于尚不支持的其他语言，你可以使用 Elastic Agents 轻松检测这些语言，从而以混合模式运行可观察平台（Elastic Agents 与 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 为遥测数据摄取带来了标准化，为组织提供了供应商选择、可扩展性、灵活性和面向未来的投资。