概念

OpenTelemetry API

负责创建遥测数据的类型, 用于生成指标/跟踪/日志的遥测数据

OpenTelemetry SDK

Collector 收集器

负责收集/处理/导出遥测数据

1. 建议将收集器与服务一起使用，它允许服务快速卸载数据，收集器可以负责其他处理
2. 每种语言的默认 OTLP 导出器都假定本地收集器端点，因此，如果您启动收集器，它将自动开始接收遥测数据

• 收集: 收集OpenTelemetry API生成的遥测数据
• 处理: 重试、批处理、加密甚至敏感数据筛选等处理
• 导出: 可以将OpenTelemetry生成的遥测数据转换成对应的后端(例如Prometheus/Jaeger)的数据格式并导出

部署

Helm Kubernetes部署Collector

使用helm chart在k8s部署Collector有4种模式:

• Daemonset
• Deployment
• Statefulset
• Sidecar

Deployment 模式

如果您想更好地控制 OpenTelemetry Collector 并创建独立应用程序，则可以选择部署。通过部署，您可以相对轻松地纵向扩展收集器以监控更多目标，在发生任何意外情况时回滚到早期版本，暂停收集器等。通常，您可以将 Collector 实例作为应用程序进行管理。

以下示例配置将收集器部署为部署资源。接收器是 Jaeger 接收器，导出器是调试导出器. 。

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: my-collector
spec:
  mode: deployment # This configuration is omittable.
  config: |
    receivers:
      jaeger:
        protocols:
          grpc:
    processors:

    exporters:
      debug:

    service:
      pipelines:
        traces:
          receivers: [jaeger]
          processors: []
          exporters: [debug]
EOF

DaemonSet 模式

如果您希望 Collector 在 Kubernetes 节点上作为代理运行，DaemonSet 应该满足您的需求。在这种情况下，每个 Kubernetes 节点都有自己的 Collector 副本，用于监控其中的 Pod。

以下示例配置将收集器部署为 DaemonSet 资源。接收器是 Jaeger 接收器，导出器是调试导出器。

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: my-collector
spec:
  mode: daemonset
  hostNetwork: true
  config: |
    receivers:
      jaeger:
        protocols:
          grpc:
    processors:

    exporters:
      debug:
        verbosity: detailed

    service:
      pipelines:
        traces:
          receivers: [jaeger]
          processors: []
          exporters: [debug]
EOF

StatefulSet 模式

将收集器部署为有状态副本集上的优点：

• 收集器实例的可预测名称将是预期的
  如果您使用上述两种方法部署 Collector，则 Collector 实例的 Pod 名称将是唯一的（其名称加上随机序列）。但是，StatefulSet 中的每个 Pod 的主机名都来源于 StatefulSet 的名称和 Pod 的序号（my-col-0、my-col-1、my-col-2 等）。
• 当收集器副本失败时，将安排重新计划
  如果 Collector Pod 在 StatefulSet 中失败，Kubernetes 将尝试将同名的新 Pod 重新调度到同一节点。Kubernetes 还将尝试将相同的粘性身份（例如卷）附加到新 Pod。

以下示例配置将收集器部署为具有三个副本的 StatefulSet 资源。接收器是 Jaeger 接收器，导出器是调试导出器。

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: my-collector
spec:
  mode: statefulset
  replicas: 3
  config: |
    receivers:
      jaeger:
        protocols:
          grpc:
    processors:

    exporters:
      debug:

    service:
      pipelines:
        traces:
          receivers: [jaeger]
          processors: []
          exporters: [debug]
EOF

Sidecar模式

The biggest advantage of the sidecar mode is that it allows people to offload their telemetry data as fast and reliable as possible from their applications. This Collector instance will work on the container level and no new pod will be created, which is perfect to keep your Kubernetes cluster clean and easily to be managed. Moreover, you can also use the sidecar mode when you want to use a different collect/export strategy, which just suits this application.
sidecar 模式的最大优点是，它允许人们尽可能快速、可靠地从应用程序中卸载遥测数据。此 Collector 实例将在容器级别运行，并且不会创建新的 Pod，这非常适合保持 Kubernetes 集群的清洁和易于管理。此外，当您想使用不同的收集/导出策略时，您还可以使用 sidecar 模式，这正好适合此应用程序。

Once a Sidecar instance exists in a given namespace, you can have your deployments from that namespace to get a sidecar by either adding the annotation sidecar.opentelemetry.io/inject: true to the pod spec of your application, or to the namespace.
一旦给定命名空间中存在 Sidecar 实例，您就可以从该命名空间进行部署，通过将注释 sidecar.opentelemetry.io/inject: true 添加到应用程序的 pod 规范或命名空间中来获取 sidecar。

See the OpenTelemetry Operator github repository for more detailed information.
有关详细信息，请参阅 OpenTelemetry Operator github 存储库。

$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: sidecar-for-my-app
spec:
  mode: sidecar
  config: |
    receivers:
      jaeger:
        protocols:
          thrift_compact:
    processors:

    exporters:
      debug:

    service:
      pipelines:
        traces:
          receivers: [jaeger]
          processors: []
          exporters: [debug]
EOF

$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: myapp
  annotations:
    sidecar.opentelemetry.io/inject: "true"
spec:
  containers:
  - name: myapp
    image: jaegertracing/vertx-create-span:operator-e2e-tests
    ports:
      - containerPort: 8080
        protocol: TCP
EOF

快速测试收集器:

适用与本机安装了Docker和Golang 1.20或更高的环境

1. 启动示例镜像:

docker pull otel/opentelemetry-collector:0.89.0
docker run -p 127.0.0.1:4317:4317 -p 127.0.0.1:55679:55679 otel/opentelemetry-collector:0.89.0

2. 从 opentelemetry-collector-contrib 存储库下载并安装该 telemetrygen 实用程序

go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest

3. telemetrygen 命令生成用于测试的虚拟遥测数据。在新的终端窗口中，向收集器发送一些跟踪

telemetrygen traces --otlp-insecure --duration 5s

4. 在浏览器中打开 http://localhost:55679/debug/tracez ，然后选择表中的一个示例，以查看刚刚生成的跟踪

Collector 组件

收集器由访问遥测数据的四个组件组成:

• Receivers  接收器: 从收集器外部收集遥测数据
• Processors 处理器: 处理或转换数据
• Exporters  导出器: 将处理后的数据发送到另一个端点
• Connectors 连接器: 连接器既是输出器，又是接收器。顾名思义，连接器连接两个管道：它在一个管道的末尾作为导出器使用数据，在另一个管道的开头作为接收器发出数据。它可能使用和发出相同数据类型或不同数据类型的数据。连接器可以生成和发出数据来汇总使用的数据，也可以只是复制或路由数据

Receivers 接收器

从收集器外部收集遥测数据

Processors 处理器

处理或转换数据

Exporters导出器

将处理后的数据发送到另一个端点

Connector

连接器既是输出器，又是接收器。顾名思义，连接器连接两个管道：它在一个管道的末尾作为导出器使用数据，在另一个管道的开头作为接收器发出数据。它可能使用和发出相同数据类型或不同数据类型的数据。连接器可以生成和发出数据来汇总使用的数据，也可以只是复制或路由数据

模式

收集器在服务端分为三种模式:

1. 无收集器 No Collector: 直接将应用生成的数据导出到后端(Prometheus/Jaeger等)
2. 代理 Agent Collector: 将信号(遥测数据)发送到收集器，然后从那里发送到后端(Prometheus/Jaeger等)
3. 网关 Gateway: 将信号(遥测数据)发送到单个 OTLP 端点，然后从那里发送到后端(Prometheus/Jaeger等)

无收集器 No Collector

直接将应用生成的数据导出到后端(Prometheus/Jaeger等)

该模式的架构图: ![[images/Pasted image 20231120120915.png]] 图片来自opentelemetry.io

优缺点

优点：

• 简单易用（尤其是在开发/测试环境中）
• 无需额外的活动部件（在生产环境中）

缺点：

• 如果收集、处理或引入发生更改，则需要更改代码
• 应用程序代码和后端之间的强耦合
• 每种语言实现的导出器数量有限

代理 Agent

代理收集器由应用(使用OpenTelemetry协议(OTLP)的OpenTelemetry SDK进行检测)或其他收集器(OTLP)组成, 这些收集器将遥测数据发送到与同一主机的收集器实例上. 也就是应用程序和收集器同时在同一台服务器上, 该模式的应用程序和收集器是一对一关系, 即一个应用对应一个代理收集器

架构图: ![[images/Pasted image 20231120122442.png]]

收集器实例包含:

1. Sidecar

优缺点

优点：

• 简单上手
• 应用程序和收集器之间清晰的 1对1 映射

缺点：

• 可扩展性（使用更多的精力去编写配置文件部署）
• 死板, 一个应用对应一个代理收集器

网关 Gateway