背景
为了尽可能的降低应用接入成本，减少 APM 工具对于整个软件研发流程的影响，腾讯云在2024年5月正式推出了 tencent-opentelemetry-operator 接入方案。该方案为部署在 Kubernetes 上的多语言应用提供了一种简单高效的 APM 接入方式。
应用接入方案对比
手动上报方案
这是最基本的接入方式，开发人员需要在代码中显式调用 APM 工具提供的 API 来采集和上报性能数据。优点是灵活性高，可以精确控制需要收集的数据和收集时机；缺点是需要修改应用程序代码，工作量非常大。
半手动上报方案
在这种方案中，开发人员仍需要在代码中调用 APM 工具提供的 API，但可以基于常用的框架或库简化一部分工作。例如，一些 APM 工具提供了与常见开发框架（如 Spring、Express 等）集成的库，开发人员只需要在配置文件中启用这些库，即可自动收集和上报性能数据。
探针方案
探针是一种自动收集性能数据的方法，它是一个运行在应用程序进程内的模块，可以在应用程序运行时动态地收集性能数据，无需修改应用程序代码。探针方案同样提供了对常见开发框架的集成，可以自动收集和上报性能数据。相比手动上报方案，部署更加简单，可以在应用编译后进行引入，甚至可以做到对整个开发过程无感知。
Sidecar 方案
Sidecar 是一种运行在应用程序进程外的模块，通常以单独的进程或容器的形式存在，可以监听应用程序的网络通信，收集性能数据。优点是无需修改应用程序代码，且对应用程序性能的影响非常小；缺点是 Sidecar 方案部署复杂，需要管理额外的进程或容器，只能基于 Service Mesh（服务网格）等特殊应用架构才能发挥价值。
eBPF 方案
eBPF（Extended Berkeley Packet Filter）是 Linux 内核中的一种技术，可以在内核中运行用户定义的程序，收集各种系统和网络性能数据。使用 eBPF 的 APM 工具可以提供非常详细和精确的性能数据，且对应用程序性能的影响极小。对于已经部署到 Kubernetes 的容器化应用，eBPF 方案的部署比较简单，但和 Sidecar 方案一样，缺少成熟的分布式链路追踪能力。
方案选型建议如下：
接入方案 | 接入难度 | 兼容性 | 功能覆盖度 | 成熟度 |
手动上报 | 极高 | 高 | 高 | 高 |
半手动上报 | 高 | 高 | 高 | 高 |
探针 | 低 | 比较高，适合大多数语言。 | 高 | 高 |
Sidecar | 低 | 低，依赖特定应用架构。 | 低 | 高 |
eBPF | 低 | 比较高，依赖高版本内核。 | 中 | 低 |
综合来看，对于 APM 方案的选型，接入难度是首要的考虑因素。如果接入 APM 工具还需要修改业务代码，会给开发团队带来沉重的负担，长远来看必将在团队内部造成推广困难的局面，这也是很多企业在引入 APM 工具的过程中放弃的主要原因。因此，我们需要尽量排除手动上报方案。虽然 eBPF 方案代表着未来 APM 的发展方向，但其成熟度较低，功能覆盖度也有较大不足。因此探针方案依然是目前最成熟、最值得考虑的选择，特别是对于 Java、Python 等基于虚拟机运行的编程语言，天然就和探针方案有极高的匹配度。
Operator 方案
tencent-opentelemetry-operator 由腾讯云在社区 opentelemetry-operator 基础上构建，是基于探针的接入方案。由于实现了 Kubernetes 环境下探针自动注入机制，免去了探针部署和配置的工作量，让应用接入变得更加简单。目前 tencent-opentelemetry-operator 支持 Java、Python、node.js、.Net 应用的快速接入，应用程序部署到腾讯云容器服务 TKE 以后，只需要在工作负载的 YAML 文件中添加2行 annotation，就能完成整个接入流程，无需在开发态涉及任何代码的修改。
安装 tencent-opentelemetry-operator
1. 登录 腾讯云可观测平台。
2. 在左侧导航中选择应用性能监控 > 应用监控，进入应用列表页面，单击接入应用。
3. 在弹出框选择需要接入的编程语言，例如 Java。
4. 进入接入 Java 应用页，选择 TKE 环境自动接入 > 一键安装 Operator。
5. 进入一键安装 Operator 的弹出窗口，通过下拉框选择上报地域、默认业务系统、TKE 集群等信息，确认后单击安装即可。
说明：
上报地域为 APM 业务系统所在的地域，每个 TKE 集群只能指定唯一的上报地域，建议将上报地域与 TKE 集群所在的地域保持一致。
6. 安装完成之后，前往 容器服务 TKE 控制台，在左侧导航中选择应用中心 > 应用，查看安装在 kube-system 命名空间的 tencent-opentelemetry-operator 应用，也可以通过 Helm 客户端执行 helm list 命令检查安装状态。
应用接入
在 TKE 集群完成 Operator 的安装后，得益于 Operator 方案动态探针注入能力，应用接入的过程极为简单，只需要编辑应用所在工作负载的 YAML 文件，在 Pod Template 中添加2个 annotation，即可完成应用接入。以 Java 应用为例，需要添加的内容如下：
cloud.tencent.com/inject-java: "true" #接入APMcloud.tencent.com/otel-service-name: my-app #指定应用名
其中，otel-service-name 字段代表应用名，多个使用相同应用名接入的进程，在 APM 中会表现为相同应用下的多个实例。完整的工作负载 YAML 文件示例如下：
apiVersion: apps/v1kind: Deploymentmetadata:labels:k8s-app: my-appname: my-appnamespace: defaultspec:selector:matchLabels:k8s-app: my-apptemplate:metadata:labels:k8s-app: my-appannotations:cloud.tencent.com/inject-java: "true" #接入APMcloud.tencent.com/otel-service-name: my-app #指定应用名spec:containers:image: my-app:0.1name: my-app
添加完 annotation 之后，将基于不同的工作负载发布策略对工作负载进行更新，触发应用 Pod 的重新创建。新启动的 Pod 会自动注入探针，并连接到 APM 服务端，将监控数据上报到 Operator 的默认业务系统。前往 腾讯云可观测平台控制台，在应用性能监控 > 应用监控 > 应用列表中，即可查询到新接入的应用。
更多应用接入指引，请参考下述帮助文档：
应用 | 参考文档 |
Java | |
Python | |
Node.js |
接入原理
Operator 方案利用了 Kubernetes 提供的 Dynamic Admission Control 机制实现探针的注入，可以参考以下流程了解 Operator 方案的接入原理：
1. 用户对工作负载添加 annotation，API Server 将基于工作负载的发布策略启动工作负载的更新。
2. 在 Operator 的相关组件中，包含一个具备 Dynamic Admission Control 能力的工作负载，通过 Mutating Webhook 的形式在容器服务集群中运行，这个组件可以从 API Server 监听工作负载的变化。
3. Operator 监听到应用工作负载添加了接入相关的 annotation 之后，会通过 API Server 对即将创建的应用 Pod 进行动态修改，修改的内容通过 Pod 的 YAML 描述表现出来。
4. Operator 会在应用 Pod 中注入一个初始化容器，在容器本地路径中包含了探针文件。
5. Operator 还会在应用容器中注入一些环境变量，这些环境变量可以对应用进程进行配置，实现挂载探针的动作。以 Java 应用为例，Operator 会对应用容器添加 JAVA_TOOL_OPTIONS 环境变量，其中包括 -javaagent 参数，指向由初始化容器引入的探针文件本地路径，使 Java 进程启动的时候执行挂载探针操作。
6. 探针通过字节码增强机制自动采集监控数据，并向 APM 服务端上报。
接入优势
简化 Operator 安装流程：安装部署流程，不但上架了 TKE 应用市场，还能在 APM 控制台实现 Operator 一键安装。
通过封装减少人力：对接入过程中需要用到的一系列配置项进行了封装，不再需要手工填写，包括 APM 接入点的地址，业务系统 token 等。
优化证书管理机制：解决了 Operator 安装过程中有可能遇到的各类兼容性问题。
降级处理：当 APM 平台的任何一个组件出现故障的时候，整个接入机制都以不影响业务正常运行为前提，在必要的时候对探针注入和监控数据上报逻辑行降级处理，确保业务的稳定运行。
自定义埋点
在探针接入方案的基础上，Operator 模式通过探针注入进一步简化了应用接入 APM 的流程。tencent-opentelemetry-operator 注入的探针来自 OpenTelemetry 生态，对主流的开发框架与类库实现了运行态自动埋点。对大多数用户而言，应用在接入成功后即可完成监控数据上报，实现分布式链路追踪，不需要修改任何代码。但在某些特殊的场景中，如果探针的自动埋点机制不能满足用户需求，用户可以引入 OpenTelemetry API，在自动埋点的基础上，通过修改应用代码增加自定义埋点。例如下述场景中，可能需要引入自定义埋点：
应用引入的开发框架与类库没有在开发者中被广泛使用，或者版本很低。
应用引入的开发框架与类库由用户自己封装，或者来自于闭源商业化定制开发。
对于某些核心的自定义方法，需要在链路中追加方法级的埋点。
对于 tencent-opentelemetry-operator 注入的探针，可以参考 OpenTelemetry 方案支持的组件和框架 了解自动埋点的范围。自定义埋点代码的具体编写方式，可以参考如下 OpenTelemetry 的官方文档：
以 Java 语言为例，如果我们需要对某个自定义方法在链路中追加方法级埋点，可以参考以下步骤实现。
1. 引入 OpenTelemetry API 依赖：
<dependencies><!-- 其他依赖 --><dependency><groupId>io.opentelemetry</groupId><artifactId>opentelemetry-api</artifactId></dependency></dependencies><dependencyManagement><dependencies><dependency><groupId>io.opentelemetry</groupId><artifactId>opentelemetry-bom</artifactId><version>1.9.0</version><type>pom</type><scope>import</scope></dependency></dependencies></dependencyManagement>
2. 通过如下代码，在链路中增加 doTask() 的方法级埋点。
import io.opentelemetry.api.trace.Span;import io.opentelemetry.api.trace.StatusCode;import io.opentelemetry.api.trace.Tracer;import io.opentelemetry.context.Scope;// Trace 对象可以在业务方法中获取，或者通过参数传入业务方法public void doTask(Tracer tracer) {// 创建一个 SpanSpan span = tracer.spanBuilder("doTask").startSpan();// 在 Span 中添加一些 Attributesspan.setAttribute("RequestId", "5fc92ff1-8ca8-45f4-8013-24b4b5257666");// 将此 Span 设置为当前的Spantry (Scope scope = span.makeCurrent()) {doSubTask1();doSubTask2();} catch (Throwable t) {// 处理异常，异常信息将记录到 Span 的对应事件中span.recordException(t);span.setStatus(StatusCode.ERROR);throw t;} finally {// 结束 Spanspan.end();}}
3. 前往 腾讯云可观测平台控制台，在应用性能监控 > 调用查询中，找到相关的调用链，单击 Span ID 后，链路详情页面中，即可查到通过自定义埋点新增的 Span。
总结
腾讯云应用性能监控（APM）为企业提供了全面、高效、易用、低成本的应用性能管理解决方案，帮助企业优化应用程序的性能。新发布的 Operator 方案，降低了接入成本，将接入 APM 工具的决策时间点从开发态后移至部署态，用户不再需要在代码中引入 APM 相关 SDK 或者将探针文件打包到容器镜像中。这实现对应用开发的零侵入，对于在团队内部全部推广 APM 工具，有着非常重要的意义。
