数据洞察创新挑战赛-智能运维赛新手训练营：课时1：可观测（Trace）相关介绍
可观测（Trace）相关介绍
内容介绍
一、 电气工程的可观测性
二、 SLS可观测性整体架构
三、 自动埋点原理
四、 观摩演示
一、电气工程的可观测性
可观测性概念最早起源于20世纪70年代。其核心思想是通过外部输出来推断系统当前的运行状况。这种方式与传统的告警和监控相比，可观测性以更为细致的方式揭示了复杂系统，它有助于更好地观察系统的运行状况，快速定位和解决问题。就像考虑发动机的情况一样，告警只会告诉你发动机是否存在问题。
而包含转速、温度和高压等信息可以粗略指出可能存在问题的区域。然而，要真正定位问题的细节，需要观测每个部件传感器的数据。
IT系统经过数十年的飞速发展，无论是开发环境、系统架构、部署模式还是技术设施，都经历了多轮的优化，以提高开发和部署效率。但是，随着系统的复杂性不断增加，开发涉及更多的人员和部门，部署模式和运行环境也变得更加动态和不确定。
因此，IT系统观测也需要更加有组织、系统化，体系化。我们知道大多数系统的外部输出通常包括三个主要部分。第一部分是日志（log），它可以详细记录每行代码的执行情况、参数和执行时间。然而，它产生的数据量巨大，包含了大量的细节,但是，这些数据通常没有上下文。
实际上，magic可观测性让我们能够从宏观角度全面了解整个系统的运行情况。例如，我们可以轻松查看CPU和内存的使用情况，即使在复杂的调用链中，trace也可以精确追踪每个方法的执行时间以及它们的运行上下文。
通过这些信息magic，log，magic，我们可以全面推断系统的整体运行状况，有助于在复杂的系统环境中迅速定位和解决问题。
接下来，让我们看看在复杂环境中使用可观测性数据时的几个关键步骤。
首先，当我们收到告警时，我们会根据告警提示magic，log来查看当前系统的指标数据，去确定日志。然后，通过日志，以获取有关这次请求的唯一标识符（通常称为调用ID）。有了这个调用Trace ID，我们可以精确地追踪整个请求的调用顺序、执行时间和运行情况，这有助于我们详细分析问题。
现在已经有很多系统帮助我们收集magic，trace，log。
本身也不帮助提供存储及智能化的算法，但是在这种情况下，SLS提供了一个平台我们快速搭建可观测性系统，在有这些的帮助之下会更加的容易,以下是SLS的可观测整体架构。
二、SLS可观测性整体架构
将Trace，log，magic进行了存储，并且会自动关联这些可观测数据，提供了盘古底座，提供了高性能的算力，提供准确高效的查询性能，帮助我们及时的发现问题，然后同时还提供了很多处理方式，例如函数等，在存储算力的上一层提供了智能化的能力帮助我们在大量的数据中去发现和定位我们的问题。同时提供了非常丰富的UI继承和告警的集成。
在介绍了整体可观测性解决方案之后，让我们深入了解trace相关知识。
这实际上包括三个部分。首先是数据采集端，它负责收集数据。这部分涉及到许多开源系统和主流协议，比如者以及其他协议。
这些数据会被统一存储到SLS中，并通过我们自身提供的算法来提取有用的信息，如服务依赖关系、服务自动发现、上下游分析、中间件分析和质量分析服务的告警。
接下来，我们将介绍探针的原理
探针分为三类：全自动、半自动和手动。全自动探针可以自动完成，无需手动更改代码。半自动探针只需更改部分框架代码。手动探针需要手动添加代码，类似于编写代码。这三种类型并不是互斥的，它们可以相互结合使用，以更好地帮助我们定位问题，全自动支持的语言有Java,Net,Python,半自动Golang,NodeJS.手动就是包括所有语言。
三、自动埋点原理
接下来，介绍一下自动埋点的原理，以Java为例，自动埋点利用Java的API进行注册。我们只需实现一个特定的方法，该方法提供了原始类的内容，然后使用字节码修改工具对代码进行修改，最终能够自动添加到我们的业务类中去添加代码。
整个原理就是在注册完成后，JVM会在加载类文件时自动调用我们的方法来修改类字节码，最终定义新的类。
接下来，介绍一下半自动埋点的原理
半自动埋点需要我们部分修改代码，以上是以 golong的HTTP服务为例，我们会在代码中注入一些方法，例如解析上下文和创建埋点代码，这个方法会注入埋点代码，实际上我们可以通过引入OpenTelemetry的包并创建所需的类来实现。
手动埋点的方式，手动埋点实际上就是说我们本身写业务代码一样通过API调用它的一些代码，比如我想记录一些异常的事件，或额外的字段，记录外的字段在业务场景下非常的有用，比如假设我想统计下每一个用户的行为轨迹，这样只需把用户ID记录进去，就可以增加用户维度的统计。
当成功接入了之后，每次请求都会将相应的Trace数据上报到SLS中。接下来，通过Trace详细信息，我们可以查看每次请求的调用轨迹。
左侧的调用轨迹图显示了不同服务之间的调用情况。实现代表了每个方法独占的时间，下面是整个Trace调用的轨迹，当我们点击左侧span的时候，右面会出现span很多详细的信息，包括资源的信息，线程等，同时还会有记录的业务字段的属性等一系列的信息。span具体的属性字段，调用类型，目前分为5类，一是producer，consumer，这两个是对应于消息中间件的发送者和消费者的关系。internal为内部的调用，不同的颜色代表不同的服务，在记录一些服务名及调用名。
四、观摩演示
通过Trace关联有关下游方法及其日志记录。
一旦我们将系统集成到前端可观测实例中，我们可以在该实例中查看当前系统的运行情况，例如错误率、平均响应时间以及差异的服务。
然后，我们可以点击应用程序进行查看。
我们可以直接搜索正在发生的请求。在我们的系统中，我们已经模拟了一个出错的请求。我们可以通过搜索来直接定位这种请求，在这个请求中，我们可以选择一个并查看其场景。
通过详细信息，我们可以清晰地看到，其中一个SPAN占据了大部分时间，并且都是由它引发的错误。
接着，我们继续查看整个调用轨迹。在这里，我们可以看到在调用“防震”接口后，出现了一个黄色的“order”接口，它的耗时约为5秒。
接下来，我们看到“Order”系统在此处出现了问题，我们将继续分析。
接下来，我们可以直接再次请求“payment”接口。这次请求的耗时超过了六秒，并且发生了错误。
我们可以通过右侧的属性查看状态码、请求参数和线程信息，通过更详细的情况，我们可以查看当前请求的相关日志。
此外，我们还可以查看当前主机的一些指标，例如服务使用率和内存使用情况，以更好地帮助我们定位问题。
除此之外，我们还可以通过详情中的分析来查看整个服务的一些性能情况，例如是否存在重复的调用、服务数量以及数据库或外部服务的延迟。
最后，我们可以观察同类延迟的分布情况，这里已经完成了50%的统计，可以看到存在一些分化，特别是超过500秒的错误，基本上都是由我们的服务引起的。
