2024 OTel Community Day Talks 解读
OTel Community Day介绍
OTel Community Day 是 OpenTelemetry 的维护者、贡献者和用户聚集在一起交流、沟通的线下活动。
2024年度的 OTel Community Day，于6月25号（当地时间）在美国西雅图举办。以上是今年社区活动日相关参会情况，OTel社区当前的主要开发者来源是北美和欧洲，由于在北美举行，所以参会的开发者主要都来自北美。
阿里云可观测团队的工程师望陶和铖朴，作为亚太地区报名并唯一被选中前往现场分享的社区开发者，本文为其相关参会感受与会议 Talks 解读。
今年的会议地点为西雅图的 Seattle Convention Center， 该会场似乎是专门用来举办各类大会的， 非常有设计感的建筑， 层高也非常的高。大会的签到系统是一个类似 iPad 的设备，只需要输入姓名就可以自助打印出 badge。演讲厅大约能容纳 200-300 人的一个会场。
OTel Community Day talks介绍
今年的 OTel Community Day 为期一天，分上下午两场进行，中午会有短暂休息，下文为站在社区开发者和会议参会者的视角对其中的 Talk 做一些个人解读介绍，相关完整 Talks 视频，请参见会议视频。
上午场
首先是 Austin 做一些开场分享，他是社区 Governance Committee 成员，来自 HoneyComb，担任公司开源工作的 Director。去开场中提到了要提升开发者和贡献者的体验，由于 OTel 社区的贡献者非常多， 因此这方面也会非常重视，最近也是刚刚成立了贡献者体验 SIG，同时也包括提到了最终用户小组， 可以举办本地化的 OTel day。
上午的正式分享环节， 第一部分是 Governance Committee(GC) 的一个圆桌， 这里面汇聚了目前 OTel 社区 GC 的几位成员
如上图所示，从左到右依次是：
- Alolita Sharma : 在 Apple 负责 AI/ML， 她同时也是 tag-observability 的 Chair， 长期参与开源社区。
- Ted Young：来自 Lightstep，OpenTelemetry 项目的联合发起人之一。
- Austin Parker：来自 HoneyComb，担任公司开源相关工作的 Director。
- Juraci Paixao Krohling: 来自 Grafana Lab，他是 OpenTracing 和 Jaeger 项目的主要维护者，即从 OpenTracing 那个阶段就开始参与 OTel 社区了。
- Daniel Dyla：来自 Dynatrace，是 W3C Distributed Tracing Working Group 成员，是OpenTelemetry JS client 的Maintainer。
圆桌主要讨论了 GC 成员的背景，为什么来做 GC， GC 成员主要负责做什么， 有几点比较印象比较深刻的：
- 每个 TC 会负责专门的一块领域， 因此如果要在对应的领域做一些事情需要能够联系到对应的 TC 帮忙
- 有一个话题讨论的比较热烈，**就是不同语言的埋点实现不一样，在规范中并没有规定的很清楚具体的实现，这是为什么？**原因就在于不同用户的需求不一样，需要从中找一个平衡，对于有些用户来说，习惯了 A 语言， 然后对于 B 语言也要求同样的方式来实现，但是在这个语言中这样实现可能并不是最优解，而习惯 C 语言的用户可能有要求 B 语言跟 C 语言用法一样，那 B 语言到底应该实现成什么样子呢? 答案是留给 B 语言埋点的维护人员来决定，因为这些维护着是最懂这个语言的专家，因此就由他们来决定。所以在 OTel 各种规范在制定的时候非常的宽松，留有一些余地。这让我想到了 Java Servlet 规范，在 Servlet 规范中严格的规定了实现的行为， 因此一个实现必须严格遵从规范的要求。我们说 Apache Tomcat 最近几年看起来没有太多的发展，其实不是不发展，主要原因还是 Servlet 规范本身不怎么发展了，而 Tomcat 本身作为它的实现，受到了限制。
- OTLP 协议才是王道， 一个语言的实现，不管它是如何实现的， 只要遵从 OTLP 协议，那么就能跟其他语言和组建进行互操作，例如发送给 OTel collector。
- 集成 OTel 最好的形态是，埋点需要内置在项目产品里面， 比如大模型内置支持 OTel SDK 上报 LLM 的数据，这说明这个项目或者产品是对 OTel 高度的认可。
1. How OpenTelemetry Helps Generative AI - Phillip Carter， Honeycomb
分享者是来自 Honeycomb 的 PD， 在 LLM semantic convention 的 group 里面比较活跃，这个社区一直在制定 GENAI 的规范，和他简单交流了下，包括后续是否能制定亚太友好的的时间，目前也没有办法做决定，可能先以异步交流为主，后续计划针对大模型的输入输出，假如和现有规范有不一致之处，可以扩充到规范中。
来自微软的 TC 成员给我们带来的分享，这个议题给我们的启示是，我们要经常用 OTel SDK 来观测自己的研发流程，例如我们自己的研发流程，以及 CICD 等，也可以通过 OTel SDK 来上报数据，吃自己的狗粮。例如 CICD 的每一个步骤，可以通过 trace 来进行跟踪。
3. Tuning OTel Collector Performance Through Profiling - Braydon Kains， Google
分享者主要介绍了用 pprof 来对 OTel Collector 进行 Profiling，以及在这个过程中发现的问题和踩坑记录。
5. The “Zen” of Python Exemplars - Paige Cruz， Chronosphere
这是一位布道师的分享，介绍了 Python 中 Exemplar 的实现， Exemplar 相当于在 metrics 统计的时候，给他附上上一个 trace 的样本，在发生曲线突增突降的情况下，能够有个样本，来协助排查具体的原因。
这个分享嘉宾是 American Express 的移动端 Android 的负责人，主要介绍在 American Express 移动端埋点的一些实践。
下午场
下午我们是第一个分享，介绍的是与 JVM 团队一起合作实现的在 GraalVM 静态编译场景下，如何解决 Java Agent 探针无法继续使用的问题，更多技术细节我们会有单独的一篇文章进行介绍。一开场的时候做了一个小调查，是否听说过 GraalVM 这项技术，看起来挺多人举手，超过一半的人，说明对 GraalVM 的认知度还比较高。整体演讲的过程还算是比较顺利，15 分钟分享加 5 分钟的 Q & A，唯一的小插曲是，最后稍微超时了一些，15 分钟的时候还差最后一页没有讲完，但是主持人还是比较 nice，允许我们继续最后一页的分享。分享过程中，观众问了以下几个问题：
- 来自 AWS 的工程师询问该技术目前是否已经商业化使用，另外，其是否未来能用在 lambda 上，这让我们关注到 OpenTelemetry 事实上是提供了对 FaaS 场景的支持，他实现方式其实是再函数执行之前，自动注入可观测能力，针对 Java 应用也是用的 Java Agent，但是他们反馈 AWS lambda 上用了这个能力之后，启动时间会延长比较长的一段时间，这会让函数的弹性效率大打折扣，而我们的方案正好是解决这一问题的最佳良药，因此他们也非常希望这个能力能够尽快的能够用起来。
- 另一位工程师问了下变成 Native Image 之后对 RT 有没有什么影响，从目前的实验数据来看这个并没有表现出明显的差异，个别场景下的 RT 表现 Native Image 会更好。
接下来是 Technical Committee(TC) 的圆桌讨论环节:
如上图所示，从左到右依次依次是：
- Josh Suereth：来自 Google，主要参与社区在 Semantic Convention 和 Specification 方面的建设工作。
- Railey Yang: 来自美国微软， 主要工作在 Metrics 的方面的 Semantic Convention 上。
- Liudmila: 来自美国微软，主要负责 .NET SDK 和 Semantic Convention 方面的工作。
- Jack Berg: 来自 New Relic，主要工作内容是 Java SDK， Java Agent 以及相关的规范部分。
微软就占据了两席，微软在可观测领域的开源投入是非常大的。圆桌讨论主要关注的几个问题：
- TC 的主要职责是什么：
- TC 会进行投票 ，针对一些无法达成一致的事情，通过投票来决定，但一般情况下不太使用这个权利
- GC 在做一些重大决策的时候， 会听从 TC 的意见
- TC 拥有 Github 项目的 merge 权限
- TC 主要负责和各个项目的沟通，TC 不需要是最懂各个项目的，而是需要最能在不同项目之间做协调沟通，制定规范等等
- 讨论了 spec sponsor 这个角色，这个角色是用于负责 merge spec 相关的 pull request， 引入这个角色的原因是 TC 的人数不够使， 需要看的 PR 太多了，因此有补充了一些人员来
这个议题主要讨论的是在实现指标的过程中主要选择累计值还是差值的问题，最后推荐大家尽量用累计值，主要原因是传输过程中丢数据的话，还能恢复回来。
3. Fine-Tuning Auto-Instrumentation - Jamie Danielson， Honeycomb
这个议题印象比较深刻， 是一个女性演讲者， 她是社区 JavaScript 探针项目的 Approver，但是她也并没有专注在自己的那边领域，而是通过调研了多个语言的实现， 讨论了如果通过一些开关参数来对探针的行为进行控制，这里面也引申出了动态配置的问题。
这位开发者分享的话题是在实现 .NET 指标统计的过程中的一些优化手段，来提升比如 Counter 这类型统计的性能， 最终能够支持的 QPS 随着 CPU 核数能够线性的 scale。其中的优化手段有几个比较印象深刻，比如说提到了几个点，metrics 的 tag 最好不要超过 3 个，而且不要打乱标签的顺序，在 3个以内的话，通过一些手段能够做到不会申请任何新的内存的，超过 3 个之后有另外的手段。