前言与理论请参考 微博增值团队可观测性探索与实践-初探 。强烈建议优先阅读。
让开发人员更关注开发本身
最上层是我们需要观测的各种服务。这里的服务不仅限于业务，还应该包括运行环境、存储、中间件等基础设施。换句话说所有会影响到服务质量的因素都应该被观测。可观测数据越全，代表后续可供根因分析的线索越多。在数据收集时，需要提前做好规划，保证数据之间的关联性，而非无脑堆砌数据。
将需要观测的服务大致分为三大类。第一类基础设施，如：物理机、云服务器、k8s、Serverless、DNS，交换机等等。第二类是各种资源依赖与中间件，如：MySQL、Redis、Kafka、Istio，etcd等等。最后一类是我们的业务应用，也是各位业务同学最关心的一个环节。一切可观测都是为了保障业务的可用性。
由于服务是多种多样的，我们需要收集的数据非常多。如此繁多的数据我们该如何处理呢？这个倒不用我们担心，社区早已经帮我们想好做好了。对于常见的基础设施、资源依赖与中间件，社区提供了相关工具 Registry 供我们开箱即用。如果在这里没有搜到也没有关系，各大云厂商、开源社区也在积极的配合生态建设。如果等不及或者存在内部自研的基础服务需要数据收集我们只需要按照规约按照提供的 sdk上报数据即可。这样相关自研的基础设施便可以快速融入生态当中，同时仅需开发所要关注的部分，节约成本。
业务应用遥测数据收集根据开发语言主要分为两种，一种是类似Java、PHP这种有运行时的语言来说，他们可以通过在runtime机制里无侵入的进行数据收集。对于Python等语言则可以通过sdk主动埋点的方式实现。
微博增值团队技术栈主要以PHP、Go为主。 接下来就以PHP与Go为例、讲一讲如果低成本地接入OTel（OpenTelemetry 缩写）生态。这两种语言也分别代表了无侵入与代码埋点两种数据收集方式。其他语言同理。
在说我们的解决方案钱，先说一下PHP OTel社区现状。社区目前提供的 https://github.com/open-telemetry/opentelemetry-php 项目通过主动埋点的方式进行数据收集。目前仅支持PHP version of 7.4.x, 8.0.x or 8.1.x （版本过高），截止2022-11-27为止，该方案还处于Alpha状态。
增值团队内部项目众多，业务悠久。很多老业务都已经处于归档状态。即使是活跃中的项目，也因不同时期选择了不同的内部框架，代码入侵的方式是无法接受的。团队成员接入成本过高。
那有没有什么更好的替代方案且可以做到代码无侵入呢？
答案是肯定的，还记得微博增值团队可观测性探索与实践-初探中介绍的 SkyWalking吗？SkyWalking PHP 数据收集的方式是基于PHP扩展，原理是通过拦截 PHP runtime exec 函数进行数据收集。由于当时SkyWalking PHP官方扩展的一些问题，我重写了一个性能优化且私有协议的内部版本扩展。那么接下来我需要做的工作就只要把私有协议改为OTel协议就好。另外OTLP（OpenTelemetry Collector）是以gRpc进行数据上报的，由于PHP进程模型与扩展能力的限制，在一些高并发、极端网络场景下，会阻塞进程，造成性能问题，最终影响业务，这是业务不能接受的。在权衡过后，我们认为可观测性数据收集上报应属于旁路服务，可以接受一定程度的数据丢失，于是也支持了基于udp协议无状态数据上报。该扩展已在微博增值团队及公司其他业务线稳定运行，得到广泛验证‣。同时该扩展也提供高级功能，对外暴露了可以主动埋点的api供开发人员定制化使用。
补充：2022-11-27：最近重新完善该文章的时候发现社区又新增了一个https://github.com/open-telemetry/opentelemetry-php-instrumentationPHP扩展项目，该项目以扩展的形式与opentelemetry-php项目相互配合。弥补opentelemetry-php项目需要主动埋点的缺点。opentelemetry-php-instrumentation 项目是通过代码主动注册被观测的方法，然后在PHP运行时自动生成链路结构，结合opentelemetry-php项目进行数据管理与上报，兼顾了成本与灵活性。不过目前opentelemetry-php-instrumentation项目仅支持PHP version 8+,且该项目状态仍未 *experimental 状态。*只能暂时观望了。