jsp做的网站效果,给你一个网站你怎么做的吗,苏州手工活外发加工网,cn域名做seo目录 引言一、OpenTelemetry是一套可观测性标准协议二、分布式追踪#xff08;Trace#xff09;是OpenTelemetry的核心功能之一三、OpenTelemetry的架构原理四、OpenTelemetry的分布式追踪#xff08;Trace#xff09;实践1、准备PHP环境2、下载SDK3、编写实例代码… 目录 引言一、OpenTelemetry是一套可观测性标准协议二、分布式追踪Trace是OpenTelemetry的核心功能之一三、OpenTelemetry的架构原理四、OpenTelemetry的分布式追踪Trace实践1、准备PHP环境2、下载SDK3、编写实例代码4、run起来5、otlp协议上报到存储介质平台 引言 与前篇谈到的MCP协议类似OpenTelemetry也是一套标准协议。每一套协议的诞生一定是为了解决已存在的某难题的就好比得先有四通八达的马路和满街的汽车交通规则的诞生才有意义如果只是三三两两的车流似乎交通规则就没那么大的价值。
OpenTelemetry 的前身是 OpenTracing 和 OpenCensus 两个项目。OpenTracing 主要关注分布式追踪而 OpenCensus 则侧重于指标和跨语言的统计信息收集。 2019年这两个社区决定合作并融合各自的特性形成了新的开源项目——OpenTelemetry。这一举措旨在提供一个全面的解决方案能够同时处理追踪、指标和其他形式的遥测数据并且支持多种编程语言和框架。OpenTelemetry 在之后的时间里不断完善和扩展其功能并于2020年正式发布了首个稳定版本。
OpenTelemetry 的诞生是为了应对现代软件系统架构中日益增长的监控和追踪需求特别是分布式系统和云原生环境的复杂性。它的出现是为了解决多个监控工具之间的互操作性问题以及提供一种统一的方式来收集、处理和分析遥测数据从而帮助开发和运维团队更有效地理解和优化他们的服务。
一、OpenTelemetry是一套可观测性标准协议
OpenTelemetry是一套由CNCF主导的云原生可观测性标准协议全称OpenTelemetry Protocol简称OTLP旨在提供一种统一的方式来收集、处理和分析 分布式追踪trace、日志logging和度量metrics 数据。
OpenTelemetry定义了可观测性的几个方面的标准trace、logs、metrics、resources。 追踪Tracing 提供了分布式追踪的功能可以跟踪请求在分布式系统中的完整路径帮助识别性能瓶颈和故障点。 指标Metrics 收集系统的各种性能指标如请求速率、错误率、资源使用情况等用于监控系统的健康状况和性能。 日志Logs 虽然 OpenTelemetry 主要关注追踪和指标但它也支持与日志系统的集成以便于将日志数据与其他类型的遥测数据关联起来。
二、分布式追踪Trace是OpenTelemetry的核心功能之一
OpenTelemetry与trace的关系主要体现在OpenTelemetry是用于分布式追踪的标准和工具集而trace是分布式追踪的基本单位。
分布式追踪Trace是OpenTelemetry的核心功能之一用于监控和分析微服务架构中的请求传播路径和性能问题。Trace在分布式系统中扮演着关键角色。它记录了一个请求在多个服务之间传播的完整路径帮助开发者理解请求在系统中的行为和性能表现。一个trace由多个span组成每个span代表请求中的一个操作或工作单元记录了操作的具体信息如开始和结束时间、操作类型、结果状态等。通过这些信息开发者可以重构事务的完整旅程定位和解决性能问题和故障。
可观测性一个很重要的领域 Trace 有两个业界标杆一个是OpenTracing另一个OpenCensus。 OpenTracing其实是一个规范jaeger就是基于opentracing实现的开源工具 OpenCensus则是由google开源的度量工具 简单来说这两者在可观测性领域功能高度重合因此在CNCF主导下进行了合并形成opentelemetry项目OpenTracing跟penCensus共同推进opentelemetry两者的官网也赫赫表达基本不再维护。同时OpenTelemetry也致力于trace、logging、metrics间的关联性。
三、OpenTelemetry的架构原理 我们重点先来看数据收集管道。
Data Collection Pipeline数据收集管道包含
CollectorOpenTelemetry Collector是一个开源的组件用于接收、处理和导出遥测数据。它可以部署在各个服务节点上也可以作为一个集中式的处理层。Receiver接收来自不同来源的遥测数据。Processor处理和转换数据例如过滤、聚合等。Exporter将处理后的数据导出到各种后端系统如Jaeger、Prometheus、Zipkin等。
可不要小看这些概念在写代码的时候处理问题可有用了。从上面的图可以看出数据整个流向的过程当数据经过Collector采集器之后就可以Exporter到各种存储介质上了。细心的小伙伴们发现了OpenTelemetry并未直接实现Exporter之后的数据存储而是交给遵循了OpenTelemetry协议的Jaeger、Prometheus、Zipkin等存储平台。通俗理解就是只要数据格式是遵循OpenTelemetry的上报都可以进行数据标准化等处理并被上报到任意遵循了OpenTelemetry协议的存储介质平台上进行下一步的遥测观察和统计。 OpenTelemetry内心OS“我只是个协议而已存储就交给别人来做吧要实现存储这得是另外的价钱~~”。
四、OpenTelemetry的分布式追踪Trace实践
我们知道OpenTelemetry有几个方面的标准分布式追踪trace、日志logging和度量metrics。这就意味着他可以用来做很多不仅仅是分布式追踪trace之外的事比如K8s的监控服务的监控等等。我们这里之所以当独讲分布式追踪trace主要是因为其不仅是OpenTelemetry的核心功能在监控和分析微服务架构中的请求传播路径和性能问题上目前也是普遍流行的解决方案。
那么我们如何基于OpenTelemetry实现链路追踪呢
我们先来看OpenTelemetry官网的介绍。
光说不练假把式。于是我们以PHP为例来一步一步详细操作下来简单demo实践一下。其他语言同理。
1、准备PHP环境
它说PHP版本要求至少7.4而如果希望0代码非入侵式的接入PHP版本至少要8.0。
OpenTelemetry部分是支持无缝接入的也就是非入侵式的服务监控和分布式追踪当然如果你需要个性化地“埋点”自己的服务调用链路情况那就可以自己手动用代码实现了代码侵入式。 由于小马的本地已经安装了PHP相关环境特意检查了下版本号符合条件环境准备完毕。
2、下载SDK
参考官网案例我们进入代码目录下运行composer命令安装SDK依赖composer.json文件需要安装的依赖包配置参考如下。 但这里需要注意市面上开源SDK实现可能会有很多不管你依赖于哪个SDK只要遵循OpenTelemetry协议即可。
{name: vendor/m.server3,description: description,minimum-stability: stable,license: proprietary,authors: [{name: 小马过河R,email: emailexample.com}],require: {slim/slim: ^4,slim/psr7:^1,nyholm/psr7: ^1,open-telemetry/opentelemetry: *,open-telemetry/api: *,open-telemetry/sdk: *,symfony/http-client: ^5.4,guzzlehttp/promises: ^2.2,php-http/message-factory: ^1.1,php-http/httplug: ^2.4},config: {allow-plugins: {php-http/discovery: true}}
}
3、编写实例代码
进入代码目录下创建index.php文件。 为了验证我们先将TRACES输出到console查看。
putenv(OTEL_SERVICE_NAMEdemo1);
putenv(OTEL_PHP_AUTOLOAD_ENABLEDtrue);
putenv(OTEL_TRACES_EXPORTERconsole);//console otlp
putenv(OTEL_METRICS_EXPORTERnone);
putenv(OTEL_LOGS_EXPORTERconsole);
#putenv(OTEL_EXPORTER_OTLP_PROTOCOLgrpc);
#putenv(OTEL_EXPORTER_OTLP_ENDPOINThttp://collector:4318);//http:4318,grpc:4317
#putenv(OTEL_EXPORTER_OTLP_HEADERS);
#putenv(OTEL_PROPAGATORSb3,baggage,tracecontext);use OpenTelemetry\API\Globals;
use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;require_once __DIR__ . /vendor/autoload.php;$tracer Globals::tracerProvider()-getTracer(demo-tracer-name);$app AppFactory::create();$app-get(/rolldice, function (Request $request, Response $response) use ($tracer) {$span $tracer-spanBuilder(manual-span)-startSpan();try {$span-setAttribute(user_id, 12345);$result random_int(1, 6);$response-getBody()-write(strval($result));$span-addEvent(rolled dice, [result $result])-end();return $response;} catch (Exception $e) {$span-setStatus($e-getCode(), $e-getMessage());$span-end();$response-getBody()-write(exception);return $response;}});$app-run();
4、run起来
我们在代码目录下执行php -S localhost:8080命令让程序监听8080端口。 回到浏览器访问路由http://localhost:8080/rolldice。我们看到了响应返回。 而console如约打出了日志信息。 好了我们的demo实现完毕了看起来超级简单对吧。
5、otlp协议上报到存储介质平台
我们刚刚为了方便演示把日志输出在console但是实际生产场景中肯定不是这样的那如果我要上报到诸如Jaeger、Prometheus、Zipkin等的后端系统或存储平台要如何处理很简单修改配置即可。详细的可以参看官方的配置介绍文档。小马这里主要拎几个重要的配置项来介绍。
//something todo...
putenv(OTEL_TRACES_EXPORTERotlp);//改成otlp
#putenv(OTEL_EXPORTER_OTLP_PROTOCOLgrpc);//默认http
putenv(OTEL_EXPORTER_OTLP_ENDPOINThttp://collector:4318);//填写ENDPOINT上报地址http:4318,grpc:4317
putenv(OTEL_EXPORTER_OTLP_HEADERS);//如果有些平台是要求传鉴权token可以通过HEADERS透传//something todo...好了这就改完了重新run起来。
在平台你将看到如下类似效果由于信息敏感小马就不贴自己实验的截图啦日志信息将比console展示更完整和丰富。 当然至于TRACES相关的知识点以及如何合理规划设置span不是本文重点小马这里就不再赘述啦。
