OpenTelemetry 已成为可观测性体验的重要组成部分，随着其持续发展，它日益满足开发人员和运维人员的DevOps需求。然而，作为当前的主要开源项目之一，它仍需完善。它的功能——虽然可以说对于可观测性来说已经必不可少——仍处于进行中，其成功取决于社区持续的支持和辛勤工作。它的实用性还取决于与OpenTelemetry结合使用的可观测性工具和平台。 译自OpenTelemetry Is No

项目介绍 我们参考官方文档构建几个 spring boot 、Golang 项目再配合 Agent 其实也可以很方便的集成 OpenTelemetry。 但是要完整的体验 OpenTelemetry 的所有功能，包含 trace、logs、metrics，还有社区这么多语言的支持其实还是比较麻烦的。 我们还需要单独部署 collector、存储的 backend service 等组件、包括 tr

历史发展 早在 OpenTelemetry 诞生之前可观测性这个概念就一直存在了，我记得我最早接触到这个概念是在 16 年当时的公司所使用的一个产品：pinpoint 现如今这个项目依然比较活跃。 图片 依然还记得当时通过它可以直接看到项目调用的拓扑图，在时间坐标上框出高延迟的点就能列出这些请求，同时还能查看此时的运行日志。 这样强大的功能对于一个刚工作一年的小白来说冲击力实属太大了一点。 后来才

背景 前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。 但这个不生效的前置条件有点多： JDK 的版本得在 18+ SpringBoot3.x 还在额外再配合使用 -javaagent:opentelemetry-javaa

背景 最近在给 opentelemetry-operator提交一个标签选择器的功能时，因为当时修改的函数是私有的，无法添加单测函数，所以社区建议我补充一个 e2e test. 因为在当前的版本下，只要给 deployment 打上了 instrumentation.opentelemetry.io/inject-java: "true" 这类注解就会给该 deployment 注入 agent。

前言 前段时间我们从 SkyWalking 切换到了 OpenTelemetry ，与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。 好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发，我们可以不用去修改社区发行版：opentelemetry-javaagent.jar 的源码也可以扩展其中的能力。 比如可以： 修改一