gydtep

Traces：是最标准的调用日志，除了定义了调用的父子关系外（一般通过TraceID、SpanID、ParentSpanID），一般还会定义操作的服务、方法、属性、状态、耗时等详细信息，通过Trace能够代替一部分Logs的功能，通过Trace的聚合也能得到每个服务、方法的Metrics指标。

gydtep

基于上述我们的一些思考，回归到可观测这个问题的本质，我们目标的可观测性方案需要能够满足以下几点：

数据全面覆盖：包括各类的可观测数据以及支持从各个端、系统中采集数据
统一的系统：拒绝割裂，能够在一个系统中支持Traces、Metrics、Logs的统一存储与分析

gydtep

算法：除了基础的数值算法外，目前我们支持了十多种的异常检测/预测算法，并且还支持流式异常检测；同时也支持使用Scheduled SQL进行数据的编排，帮助我们产生更多新的数据。

gydtep

Metrics：时序引擎我们在新版本设计之初就兼容了Prometheus，并且支持Telegraf、OpenFalcon、OpenTelemetry Metrics、Zabbix等数据接入。

gydtep

同时可观测性数据还有一些共性的特点，例如高吞吐写入（高流量、QPS，而且会有Burst）、超大规模查询特点、时间访问特性（冷热特性、访问局部性等）。

gydtep

数据分析（一般针对Traces、Logs）：通常Traces、Logs还会用于数据分析和挖掘，所以要使用图灵完备的语言，一般程序员接受最广的是SQL

gydtep

上述的分析方式都有对应的适用场景，我们很难用一种语法/语言去实现所有的功能并且具有非常好的便捷性（虽然通过扩展SQL可以实现类似PromQL、关键词查询的能力，但是写起来一个简单的PromQL算子可能要用一大串SQL才能实现），

gydtep

上述的例子同时查询了LogStore、MetricStore，而且关联CMDB以及ML模型，一个语句实现了非常复杂的分析效果，在实际的场景中还是经常出现的，尤其是分析一些比较复杂的应用和异常。

gydtep

AIOps巡检：针对时序数据特别开发的基于时序异常算法的巡检能力，用机器和算力帮我们去检查到底是哪个指标的哪个维度出现问题。

gydtep

各类数据全部存储在SLS可观测数据引擎中，主要利用SLS提供的索引、查询和聚合分析能力
上层基于SLS的接口构建全链路的数据展示和监控系统