Opentelemetry——Components

Components

组件

The main components that make up OpenTelemetry
构成 OpenTelemetry 的主要组件

OpenTelemetry is currently made up of several main components:
OpenTelemetry 目前由几个主要组件组成：

• Specification
  规范
• Collector
  收集器
• Language-specific API & SDK implementations
  特定语言的API和SDK
  • Instrumentation Libraries
    测量装置库
  • Exporters
    导出器
  • Zero-Code Instrumentation
    零代码测量装置
  • Resource Detectors
    资源探测器
  • Cross Service Propagators
    跨服务的传播器
  • Sampler
    采样器
• K8s operator
  K8s operator
• Function as a Service assets
  函数即服务（FaaS）

OpenTelemetry lets you replace the need for vendor-specific SDKs and tools for generating and exporting telemetry data.
OpenTelemetry可让您摆脱特定供应商的 SDK 和工具，生成和导出遥测数据。

Specification

规范

Describes the cross-language requirements and expectations for all implementations. Beyond a definition of terms, the specification defines the following:
为所有的实现描述跨语言要求和展望。除了术语定义之外，该规范还定义了以下内容：

• API: Defines data types and operations for generating and correlating tracing, metrics, and logging data.
  API：为生成和关联Trace、Metrics和Logs数据定义的数据类型和操作。
• SDK: Defines requirements for a language-specific implementation of the API. Configuration, data processing, and exporting concepts are also defined here.
  SDK：为 API 的特定语言实现定义了要求。此处还定义了配置、数据处理和导出的概念。
• Data: Defines the OpenTelemetry Protocol (OTLP) and vendor-agnostic semantic conventions that a telemetry backend can provide support for.
  数据：定义了 OpenTelemetry 协议（OTLP）和供应商无关的语义约定，遥测后端可以提供对其的支持。

For more information, see the specifications.

Collector

收集器
The OpenTelemetry Collector is a vendor-agnostic proxy that can receive, process, and export telemetry data. It supports receiving telemetry data in multiple formats (for example, OTLP, Jaeger, Prometheus, as well as many commercial/proprietary tools) and sending data to one or more backends. It also supports processing and filtering telemetry data before it gets exported.
OpenTelemetry Collector 是一个与供应商无关的代理，可以接收、处理和导出遥测数据。它支持接收多种格式的遥测数据（例如，OTLP、Jaeger、Prometheus 以及许多商业/专有工具）并将数据发送到一个或多个后端。它还支持在导出遥测数据之前对其进行处理和过滤。

For more information, see Collector.
有关详细信息，请参阅收集器。

Language-specific API & SDK implementations

特定语言的 API 和 SDK 实现

OpenTelemetry also has language SDKs that let you use the OpenTelemetry API to generate telemetry data with your language of choice and export that data to a preferred backend. These SDKs also let you incorporate instrumentation libraries for common libraries and frameworks that you can use to connect to manual instrumentation in your application.
OpenTelemetry 还提供了针对特定语言的 SDK，让您可以使用 OpenTelemetry API 使用您选择的语言生成遥测数据，并将该数据导出到首选的后端。这些 SDK 还允许您将测量装置库与常见库和框架一起使用，这些库和框架可以用于连接到应用程序中的手动化测量装置。

For more information, see Instrumenting.
有关详细信息，请参阅测量装置。

Instrumentation Libraries

测量装置库

OpenTelemetry supports a broad number of components that generate relevant telemetry data from popular libraries and frameworks for supported languages. For example, inbound and outbound HTTP requests from an HTTP library will generate data about those requests.
OpenTelemetry 支持大量组件，这些组件可以从受支持语言的流行库和框架生成相关遥测数据。例如，来自一个HTTP库的入站和出站 HTTP请求，将生成和这些请求相关的数据。

It is a long-term goal that popular libraries are authored to be observable out of the box, such that pulling in a separate component is not required.
一个长期目标是，流行的库被编写为可观测的开箱即用，无需额外组件。

For more information, see Instrumenting Libraries.
有关更多信息，请参阅测量装置库。

Exporters

导出器

Send telemetry to the OpenTelemetry Collector to make sure it’s exported correctly. Using the Collector in production environments is a best practice. To visualize your telemetry, export it to a backend such as Jaeger , Zipkin , Prometheus , or a vendor-specific backend.
将遥测数据发送到OpenTelemetry Collector以确保其正确导出。在生产环境中使用收集器是最佳实践。要可视化您的遥测数据，请将其导出到后端，例如 Jaeger、Zipkin、 Prometheus或其他供应商的后端。

The registry contains the list of language specific exporters.
注册表包含特定语言的导出器列表。

Among exporters, OpenTelemetry Protocol (OTLP) exporters are designed with the OpenTelemetry data model in mind, emitting OTel data without any loss of information. Furthermore, many tools that operate on telemetry data support OTLP (such as Prometheus , Jaeger, and most vendors), providing you with a high degree of flexibility when you need it. To learn more about OTLP, see OTLP Specification.
在导出器中，OpenTelemetry Protocol (OTLP)导出器在设计时考虑了 OpenTelemetry 数据模型，可在不丢失任何信息的情况下发出 OTel 数据。此外，许多对遥测数据进行操作的工具都支持 OTLP（例如Prometheus、Jaeger和大多数供应商），在您需要时为您提供高度的灵活性。要了解有关 OTLP 的更多信息，请参阅OTLP 规范。

Zero-Code Instrumentation

零代码测量装置
If applicable a language specific implementation of OpenTelemetry will provide a way to instrument your application without touching your source code. While the underlying mechanism depends on the language, at a minimum this will add the OpenTelemetry API and SDK capabilities to your application. Additionally they may add a set of Instrumentation Libraries and exporter dependencies.
如果适用，OpenTelemetry 的特定于语言的实现将提供一种无需接触源代码即可测量应用程序的方法。虽然底层机制取决于语言，但这至少会为您的应用程序添加 OpenTelemetry API 和 SDK 功能。此外，它们可能会添加一组测量装置库和导出器依赖项。

For more information, see Zero-Code Instrumentation.
有关更多信息，请参阅 零代码测量装置。

Resource Detectors

资源探测器
A resource represents the entity producing telemetry as resource attributes. For example, a process producing telemetry that is running in a container on Kubernetes has a Pod name, a namespace, and possibly a deployment name. All three of these attributes can be included in the resource.
资源是将遥测数据生成为资源属性的实体。例如，在 Kubernetes 上的容器中运行的生成遥测数据的进程具有 Pod 名称、命名空间，还可能有部署名称。所有这三个属性都可以包含在资源中。

The language specific implementations of OpenTelemetry provide resource detection from the environment variable OTEL_RESOURCE_ATTRIBUTES and for many common entities, like process runtime, service, host or operating system.
OpenTelemetry 的特定语言实现通过环境变量 OTEL_RESOURCE_ATTRIBUTES 从环境中检测资源，并提供了许多常见实体的资源探测，例如进程运行时、服务、主机或操作系统。

For more information, see Resources.
有关详细信息，请参阅资源。

Cross Service Propagators

跨服务传播器
Propagation is the mechanism that moves data between services and processes. Although not limited to tracing, it is what allows traces to build causal information about a system across services that are arbitrarily distributed across process and network boundaries.
传播是在服务和进程之间移动数据的机制。尽管不限于Trace，但它允许Traces在跨进程和网络边界的任意分布的服务之间构建因果信息。

For the vast majority of the use cases, context propagation is done for you through Instrumentation Libraries. But, if needed you can use Propagators yourself to serialize and deserialize cross-cutting concerns such as the context of a span and baggage.
对于绝大多数用例，Context Propagation是通过测量装置库自动完成的。但是，如果需要，您可以自定义传播器自行序列化和反序列化跨领域需要关注的数据，比如Span和Baggage的上下文。

Sampler

采样器
Sampling is a process that restricts the amount of traces that are generated by a system. The language-specific implementations offer several head samplers
采样是一个约束系统生成的Traces量的过程。特定于语言的实现提供了多个头部采样器。

For more information, see Sampling.
有关详细信息，请参阅采样。

K8s operator

The OpenTelemetry Operator is an implementation of a Kubernetes Operator. The operator manages the OpenTelemetry Collector and auto-instrumentation of the workloads using OpenTelemetry.
OpenTelemetry Operator是 Kubernetes Operator的一种实现。该Operator管理 OpenTelemetry 收集器，并使用 OpenTelemetry 对工作负载进行自动仪表化。

For more information, see K8s Operator.
有关更多信息，请参阅K8s Operator。

Function as a Service assets

OpenTelemetry supports various methods of monitoring Function-as-a-Service provided by different cloud vendors The OpenTelemetry community currently provides pre-built Lambda layers able to auto-instrument your application as well as a the option of standalone Collector Lambda layer that can be used when instrumenting applications manually or automatically.
OpenTelemetry支持不同云供应商提供的各种监控功能即服务的方法。OpenTelemetry社区当前提供预构建的Lambda层，自动测量您的应用程序，以及可以使用的独立Collector Lambda层的选项用于手动或自动测量应用程序。

For more information, see Functions as a Service.
有关更多信息，请参阅函数即服务。

原文地址：https://blog.csdn.net/breaksoftware/article/details/137646996

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！