原创智能优化,原创度检查,一键采集,文章组合(传统监控方案正在朝着可观察性方案快速演进(图))

　　原创智能优化,原创度检查,一键采集,文章组合(传统监控方案正在朝着可观察性方案快速演进(图))

　　简介：SLS于2015年发布了日志（Logs）解决方案，2020年发布了监控（Metrics）解决方案，今年又于2021年发布了分布式链路追踪（Traces）解决方案，正式配备了可观察数据的统一存储。、分析和可视化功能。未来，除了深化各个细分数据场景外，还将提供更完善的数据关联解决方案和AIOps异常检测与根因分析能力。

　　背景 IT系统演进

　　为了更好地适应业务模式的快速演进，包括开发模式、系统架构、部署模式、基础设施在内的核心IT能力正在逐步升级，使整个IT系统能够保持稳定的高水平发展在保持快速发展的同时。性能好、规模大、成本低。但它也带来了许多我们需要面对的挑战：

　　从监控到可观察性

　　为了保证系统在 DevOps 开发方式、微服务架构、容器化部署环境、云环境模式等方面依然具有高可靠性，传统的监控方案正在快速向可观察性方案演进，可观察性并不是很新鲜。概念方面，Google 的《SRE》一书中也介绍了一些相关内容。

　　相比之下，监控更多的是监控服务的性能、可用​​性等，能够尽早发现系统问题，然后问题的定位和解决不是核心重点，所以更多定义为指标如metrics 对于一些Golden Metrics，当出现问题时，会及时通知相应的负责人进行处理。

　　在 DevOps 流行之后，可观察性开始被逐渐接受。对于 IT 系统而言，稳定性不是问题的及时发现，而是问题的及时解决或防患于未然的能力。因此，在传统监控发现问题的基础上，可观察性还侧重于如何定位甚至预防问题，并使用白盒的方式来控制系统中各个组件的运行状态，包括Logs、Traces、指标和其他手段。当出现问题时，它可以快速定位到哪个模块有问题，错误信息是什么，甚至可以定位到代码块。更重要的是，如果你有系统的知识和经验，你还可以针对问题给出恢复计划甚至修复计划。

　　日志、跟踪、指标

　　看一下 Grafana 的 文章 中描述的典型故障排除过程：

　　起初，我们通过各种预设的告警发现异常（通常是 Metrics/Logs）。发现异常后，打开监控面板查找异常曲线，通过各种查询/统计发现异常模块（Metrics）。以及相关的日志进行查询/统计分析，找到核心错误信息（Logs），最终通过详细的调用链数据定位导致问题的代码（Traces）。

　　以上示例介绍了如何使用 Metric、Traces 和 Logs 联合排查问题。当然，根据不同的场景可以有不同的组合方案。比如简单的系统可以直接使用日志错误信息进行告警，直接定位问题，或者根据调用链中提取的基本指标（Latency，ErrorCode）触发告警。但总的来说，一个具有良好可观察性的系统必须具备以上三点。

　　SLS 的目标：可观察性的统一平台

　　对于 SLS，我们的目标之一是让 DevOps 更多地专注于创造价值，而不是将大量精力花在 采集 数据、监控系统、调查问题等琐碎的事情上。因此，我们不仅需要支持Logs、Metrics、Traces的统一存储和分析，还要具备对这些数据进行有效关联的能力，比如基于标准化关联规则的能力和基于机器学习的AIOps。

　　SLS于2015年发布日志（Logs）解决方案，2020年发布监控（Metrics）解决方案，今年2021年发布分布式链路跟踪（Traces）解决方案。它正式配备了可观测数据的统一存储和分析。，可视化能力。未来，除了深化各个细分数据场景外，还将提供更完善的数据关联解决方案和AIOps异常检测与根因分析能力。

　　SLS的跟踪服务

　　SLS 的 Trace 服务并没有自始至终打造自己的轮子。在上一篇文章《10个特点：这就是你需要的Trace解决方案》中，我们也提到了Trace必须遵循统一的规范。OpenTelemetry 是目前全球公认的 Trace 标准化方案，而且 OpenTelemetry 本身兼容 Jaeger 和 Zipkin 等 OpenTracing 协议，以及 OpenCensus 等方案，所以我们不会独立创建新的协议，而是直接使用 OpenTelemetry 作为 Trace SLS 提供服务的标准协议。

　　因此，可以说SLS的Trace服务更像是对OpenTelemetry的补充。OpenTelemetry 定义了 Traces 规范、各种 SDK 实现以及数据的采集Agent，而 SLS 支持 OpenTelemetry Traces 数据存储、分析、可视化、告警以及后续的 AIOps 等能力。

　　SLS Trace1.0 函数 OpenTelemetry 标准

　　目前一些公司已经开始支持OpenTelemetry数据的接入，但是都是将OpenTelemetry数据转换成自己的内部标准，所以无论如何都会有一些数据丢失，无法做到100%兼容。SLS Trace服务直接基于OpenTelemetry数据格式开发，所有存储格式定义完全兼容OpenTelemetry标准（详见《SLS Trace格式定义》），因此可以做到：

　　跟踪数据传播支持 OpenTelemetry 的各种传播协议。Trace可以接入各种开源组件，保证整个链路的覆盖率足够高。可以完美支持各种属性信息的语义，包括Resource/Attribute等，比如Resouce标识Trace的来源信息，包括主机名、服务名、版本号、发布环境、K8sPod/Deploy等信息，其中可以更好地适应现代 IT 环境，未来可以更好地支持 Metrics 和 Logs。目前OpenTelemetry只有Trace解决方案1.0的定义是稳定版。以后在Metrics和Logs的定义完成后，

　　跟踪数据访问

　　作为服务型产品，SLS的Trace服务只需在页面上点击几下即可激活，无需对Trace后端进行部署、运维和维护。大部分工作已经完成。在接入的步骤中，SLS 还提供了更方便、更多样化的方式来适应不同的技术栈、架构或现有的 Trace 解决方案。

　　SLS 服务器直接内置了各种 Trace 协议的接入点。您只需在 Trace 客户端 SDK 中配置接入点信息即可完成接入。目前内置的协议有：OpenTelemetry、Jaeger、Zipkin、OpenCensusSLS，2020年已经正式支持OpenTelemetry Collector写入SLS。因此，OpenTelemetry Collector 支持的所有类型的 Receiver 都可以使用 OpenTelemetry 协议写入 SLS。例如，如果使用 SkyWalking 解决方案，也可以使用 AWS 的 X-Ray 和 SignalFx 等商业软件。连接 SLS，只需要部署最新版本的 SLS Logtail。对于其他的或者自建的Trace协议，比如阿里的鹰眼Trace，你只需要将数据写入SLS，然后使用ETL转换格式即可使用。

　　当然，如果是新建的 Trace 方案，建议尽量使用 OpenTelemetry 方案。毕竟其他协议都是转换成OpenTelemetry格式的，其他协议的定义没有OpenTelemetry那么规范和严谨，可以更好的发挥Trace的优势。.

　　有关访问的详细介绍，请参阅：SLS Trace 数据访问概述。

　　指标计算

　　借助 SLS 强大的计算能力，我们会根据不同的服务和调用，实时预计算 Trace 数据，提取 Trace 的黄金指标，包括延迟、错误率、QPS 等。对于延迟，它还支持PXX的分位数计算，更真实地反映实际用户体验。

　　轨迹显示

　　Trace显示是最基本的需求，这里就不介绍了。借助 OpenTelemetry 规范，我们可以清楚地知道数据来自哪种语言，调用了什么协议，调用的类型，调用的结果，错误信息等，并将这些数据以图形的方式显示在图表上，并且所有属性和信息都支持关联跳转到 Trace 分析。

　　痕量分析能力

　　Trace 数据的丰富性极强。如果只是用来根据 TraceID 来显示，那么它的价值会被极大的浪费。因此，定制化、多维度的分析能力可以充分发挥Trace的价值。SLS 内置 Trace 分析能力，并支持 Query Builder 帮助您更好地筛选出您想要关注的 Trace 数据。您只需要在界面中使用各种条件组合即可完成，每个组合的可选值都会自动提示出来。

　　点击查询按钮会自动过滤掉符合条件的跟踪数据。概览框会显示查询范围内的trace分布、错误率、延迟等信息，分析框会显示这些span的详细信息。同时还支持根据各种自定义维度进行统计分析。比如下面的例子会找出用户服务延迟超过1ms的span，并根据调用组分析这些span的分布情况。

　　可扩展性

　　SLS Trace 服务具有极强的可扩展性，主要包括 OpenTelemetry Trace 协议本身的可扩展性和 SLS 自身能力的扩展：

　　OpenTelemetry协议中Traces的规范比较完善，后续的Resource和Attribute字段可以任意扩展；此外，在后续Logs和Metrics规范1.0版本发布后，SLS目前的Trace服务也将直接升级为SLS OpenTelemetry服务。目前已经在默认的 Trace 实例中创建了 Logs 和 Metrics 相关的资源，并且 Metrics 已经在一些场景中使用，例如 Java Agent、SkyWalking、Golang SDK。SLS本身提供SQL92分析语法、数据处理、可视化仪表盘、告警等功能。Trace 服务可以基于这些功能直接定义一些自定义场景。另外，它支持数据队列的功能（如Kafka），

　　功能摘要

　　SLS Trace 解决方案的定位是 SLS 可观察性解决方案的一部分。从 Trace 服务本身出发，SLS 主要是想给大家带来一个有几大特点的解决方案：

　　Trace数据全覆盖：除原生支持OpenTelemetry外，可覆盖市面上各种主流Trace解决方案，尤其是开源场景，保证数据访问能力足够全面。与其他数据的关联：SLS本身已经可以支持Traces、Metrics、Logs所有可观察数据的统一存储和分析，因此更容易构建能够快速关联其他数据的平台，从而在一个系统中完成故障排除，降低复杂度。云原生 Trace 服务：作为云端服务，SLS 的 Trace 解决方案仍然是按量付费的模式。无需自行部署、运维和维护 Trace 系统，支持弹性扩展、高可靠性等高级能力。简单易用：无论从数据访问还是使用，SLS Trace 服务都尽最大努力为您提供简单易用的解决方案，例如直接将各种 Trace 协议写入 SLS 后端、内置 Trace 指标计算、图形化 Trace 分析、等。还将提供更简单的Trace分析功能。智能：虽然当前版本的SLS Trace1.0没有集成SLS的各种AIOps算法，但是我们很快会在1.1版本中发布很多自动Trace分析功能，让AIOps可以使每个云上的所有用户受益。SLS Trace的后续规划 图形迹线分析等。还将提供更简单的迹线分析功能。智能：虽然当前版本的SLS Trace1.0没有集成SLS的各种AIOps算法，但是我们很快会在1.1版本中发布很多自动Trace分析功能，让AIOps可以使每个云上的所有用户受益。SLS Trace的后续规划 图形迹线分析等。还将提供更简单的迹线分析功能。智能：虽然当前版本的SLS Trace1.0没有集成SLS的各种AIOps算法，但是我们很快会在1.1版本中发布很多自动Trace分析功能，让AIOps可以使每个云上的所有用户受益。SLS Trace的后续规划

　　SLS Trace解决方案基本是按照上篇文章文章《10个特点：这就是你需要的Trace解决方案》中定义的路线开发的。目前我们发布的1.0版本已经有了。1-6 的特性，所以除了让 Trace 服务更简单易用外，主要关注点会逐渐具备 6-10 的能力。目前正在规划和推进的功能/优化包括：

　　访问体验优化：我们将提供更多访问示例，以便您快速访问不同语言和平台的 Trace 数据。同时，我们还将提供微服务的示例，让您快速体验 Trace 服务的优势。Trace使用最佳实践系列：Trace对于生成和使用都有一定的门槛，所以我们会为您提供最佳实践系列，让大多数人都能用好Trace，充分发挥Trace一键报警的价值配置功能：目前告警配置只能使用SLS的通用告警功能，工作量比较大。后续会根据 Trace 服务和调用提供 Trace 告警的一键配置和快速配置功能。Trace自动分析：使用AIOps中的模式分析算法，自动分析导致trace错误率或延迟增加的模式组合，快速找出是哪个服务、哪个调用、哪个机器、哪个接口导致了问题 Trace Compare功能：支持和历史对某段时间或某个服务的版本进行对比分析，在服务发布后快速找出是服务的哪些部分导致了问题。关联Logs和Metrics功能：目前Trace服务本身的数据关联只是Trace的内部循环，未来会提供各种跳转能力，方便关联Trace相关的日志和监控信息。内置Metrics功能：目前Java Agent、SkyWalking、Golang SDK等都有内置metrics，比如GC信息、主机指标、进程指标等，后续的Trace服务都会支持显示的指标。过程中直接关联这些内置指标，方便定位问题。Trace自定义Dashboard：目前Trace的查询分析能力只能在Trace服务本身使用。稍后，它将支持将分析能力提取到 Dashboard 中的图表中，以及日志和监控。安排到仪表板进行查看。Trace 的查询和分析能力只能在 Trace 服务本身中使用。稍后，它将支持将分析能力提取到 Dashboard 中的图表中，以及日志和监控。安排到仪表板进行查看。Trace 的查询和分析能力只能在 Trace 服务本身中使用。稍后，它将支持将分析能力提取到 Dashboard 中的图表中，以及日志和监控。安排到仪表板进行查看。

　　助力可观测性统一平台：SLS Trace服务发布-阿里云开发者社区