1. SLS 全栈可观测
1.1 一句话概览
全栈可观测应用是日志服务提供的一站式IT系统可观测方案，包含全链路Trace、IT系统监控、性能监控、用户体验监控、智能告警等功能。、
1.2 功能优势
简单：一站式开通、中心化使用，内置丰富的报表，可满足监控大盘、问题排查、可观测数据融合分析等需求。
全栈：全面覆盖各类IT系统，支持多种可观测数据，支持多种语言的指标、日志、Trace接入。
自动化：支持ECS、Kubernetes自动安装，具备自动生成服务拓扑和网络拓扑的能力。
海量：基于日志服务自研的可观测存储分析引擎，支持写入与查询超大规模的可观测数据。
弹性：支持过滤任意的可观测数据，也支持任意设置可观测数据存储周期。Logstore和Metricstore容量可动态伸缩满足业务增长需求。
智能：基于达摩院智能AIOps的流式巡检算法，有助于更快、更准确地发现并定位问题。
SLS 十年前从日志、监控做起，逐渐从阿里云的飞天神农监控、简单日志发展成阿里集团的基础设施，并在阿里云上吸引了数十万企业用户。面对可观测的技术浪潮、成熟可观测的痛点诉求，SLS从数据引擎的角度出发，尝试把可观测数据生命周期中的采集、存储、计算、分析做深做精，并基于这些基础技术为客户提供单一场景的开箱即用的可观测方案。更多关于SLS可观测背景、发展理念、策略打法、未来展望，可参见《从存储统一到数据融合-SLS在可观测场景的思考和行动》。
2. 全栈可观测核心功能升级
2.1 旧版本痛点
- 功能零散：旧版本中存在许多独立的功能，缺乏整合和协调，无法突出SLS可观测统一引擎的核心优势，同时也容易给用户带来了不必要的复杂度和困扰。
- 体验不一致：旧版本由于不同功能之间缺乏协调和整合，导致开通、资源管理和页面布局等方面存在不一致的问题，容易给用户带来割裂的体验。
- 数据互通困难：旧版本由于存在大量独立的功能，导致数据互通的路径变得过长，相关联的数据难以发挥其潜在的价值。
- 功能重复建设：旧版本不同独立的功能中，也存在许多相同的方面，例如接入、告警、巡检等，这导致不得不进行重复建设。
基于以上问题，SLS对全栈可观测的核心能力进行全面的升级。
2.2 真正的可观测统一引擎
SLS新版全栈可观测整合了原有Trace分析、全栈监控、RUM监控、移动端监控这几大分散的App，将原先存在于全栈监控的性能监控独立为平级，将RUM和移动端监控合并为用户体验监控。
SLS对以上几种数据进行统一的数据建模，用统一的可观测数据引擎驱动这几种数据。优势如下：
- 将原有零散的功能进行中心化处理，更加高效方便。
- 对于每种不同的数据实体类型，都具备连贯统一的使用体验。
- 具备良好的多态能力，针对某些特殊实体类型，兼顾特化的浏览能力（例如Trace详情、Web会话详情）
- 释放数据潜能，在统一数据建模中，实现了将原先分散的数据整合，灵活互通，1 + 1 > 2。
- 实现了基于数据实体类型的统一事件告警。不但解决了原先重复程度高的问题，而且针对实体类型本身提供了更智能化、自动化的告警方案，无需手写SQL即可轻松掌控高达数十种实体类型、几百种指标的告警。
集成至全栈可观测后，无须担心以上几种App原有功能受限，全栈可观测是在其原有能力基础上，不改变原有使用逻辑，额外搭载了全新的建模体系，灵活融合在原有场景的相关位置中（例如Trace的详情页、详细信息处），带来更一致的体验，同时真正实现了相关联的数据融合。
3. 数据模型
接下来对全栈可观测的统一可观测数据引擎进行简述。
3.1 实体建模
数据模型对全栈可观测涉及的各种数据进行分类，对每一种类别的数据进行抽象，本文后续将这种数据抽象命名为“实体类型”，而在每种实体类型下的真实存在的对象，命名为“实体”（例如，“主机”是一个“实体类型”，“iZ2as3uifh38sd67fhsdfk”是一个实体）。目前全栈可观测支持的实体类型如下图所示。
以实体类型为维度，每个实体类型都具备一系列共性：都需要被观测（观测的指标是差异化的）、自身都具备一定描述性属性、都存储于某个日志库或时序库中。因此，一个实体类型的最小化数据模型如下图所示。
核心功能如下：
- 提取了每种实体类型的一些基础实体信息，作为该实体类型的主要描述
- 针对每种实体总结了关于该实体类型的各种观测指标核心信息
- 根据这些指标信息，可以自动生成某个实体的观测仪表盘、一键生成告警配置、自动配置指标巡检等多种扩展能力
- 若实体自身若存在某些特殊模板仪表盘，模型支持灵活添加
目前全栈可观测建模已覆盖大部分数据类别，仍存在少量种类的数据暂未建模。全栈可观测会在即将到来的版本中逐步扩充能力，敬请期待！
3.2 实体类型关联
实体，不是一个孤岛。
以一个Trace服务实体为例，一个Trace服务可能涉及多种相关联的观测对象：
- Trace应用方面
- Trace服务主机：Trace服务需要在特定的主机上运行，这个主机可以是物理服务器、虚拟机、容器等。
- Trace服务方法：Trace服务会提供一系列的方法或接口，用于记录和追踪应用程序的执行过程和关键操作。这些方法可以用来标记、记录和传递关键的上下文信息。
- 相关IT系统方面
- K8s相关资源：由于Trace服务需要在特定的主机上运行，需要监控物理服务器、虚拟机、容器的运行情况指标。
- 基础设施方面
- Trace服务存储：服务通常需要将相关数据进行存储。存储可以采用关系数据库、分布式存储系统等形式。
关于实体类型关联的建模，可以解决数据的融合分析这种用户痛点。
我们将数十种实体类型建立联系并可视化跳转，让复杂的的数据信息可以结构化展示。
SLS为Log、Metric、Trace等数据提供了统一存储，而全栈可观测应用通过实体类型关联，将数据价值激发出来，提供了SLS的一站式IT系统可观测方案。
3.2.1 全栈可观测的实体类型关联
多个实体之间具备一系列的关联关系：服务于、调用、属于、包含、管理、消费... 正是这些实体之间错综复杂的关系，让问题的定位变得困难。以下是一些全栈可观测相关实体的关联关系示例。
在全栈可观测的实体类型关系建模当中，虽然逻辑上的关系是单向的，但在数据上大部分的关系都是双向的，也就是说，您可以自由地查看所有关联，而并非区分主动和被动关系，同时，关联模型也支持多级，可以找到连通图中的任一节点。
3.2.2 全栈可观测的问题排查路径
在真实场景的问题定位中，通常问题的根因调查比较复杂。如果只通过日志查询，需要大量排查时间，且无法做到提前预知问题，也难以评估问题影响方面。
但在新版的全栈可观测中，可以高效地解决复杂问题根因定位，对于关联问题和影响，也可以全面而轻松地观测。
上图展示了一个Trace服务发生异常，它和它关联的多个实体类型可以提供的排查问题方向：
- 直接浏览问题服务指标：对于Trace服务本身，提供了服务关键的指标信息，从中可以快速查看某个服务的指标异动。同时，也提供了对于某个服务快速查找Trace Explorer分析的能力，丝滑切换。
- 定位代码行号：Trace服务报错，通过配置Trace ID跳转日志库，可直接定位代码行号。
- 浏览关联指标：Trace服务背后的主机或数据库，可以通过全栈可观测的实体关联功能，找到服务实体对应的K8s相关实体，例如K8s Pod、K8s 节点、K8s Deployment等，也可以找到服务实体对应的数据库，例如MySQL、Redis或MongoDB等，通过查看关联实体的关键指标状态，判断服务问题的影响面，以便及时采取对应的处理方案。
- 浏览关联日志：关联实体当然也可以查看相关日志，以排查更细节的信息。同时，如果关联实体也出现异常，则将该节点作为问题起点，同样可以提供以上多种排查问题方向。
- 实体指标告警：您也许会发现图中有出现几种告警事件，在全栈可观测的新版告警中， 融合了事件驱动的告警，和实体配合紧密，如果触发了告警事件，在实体详情页会有醒目提示。关于实体告警在模型中的应用，将在下一个部分进行详细介绍。
最终，通过查看Trace服务关联的K8s Pod的部署日志，查找到了触发这一次CICD发布的人，找到了问题根因对应的人员。
3.3 实体事件
实体事件是全栈可观测基于数据实体类型的统一事件告警，通过事件库驱动，带来了完整、直观、统一、简单的告警配置方案，大部分实体类型，基于重点的指标项，具备默认的告警规则。您可以一键开启自动告警，后续也可以在默认配置的基础上根据您的需求自由更改。
目前全栈可观测支持16个实体类型的默认告警。事实上您可以不受默认关键告警指标的限制，基于任意指标项创建告警。而且无需手写SQL，一切都是自动的！
4. 数据融合功能实机演示
4.1 查看Trace服务实体详情
在服务每一个服务被抽象为一类实体，详情页包括该实体的状态概览，关于它的Trace分析，相关调用列表，以及上下游拓扑结构。
4.2 Trace 服务关联Trace服务方法与服务主机
在Trace服务列表页面进入到一个服务实体，在相关联实例中可以找到它的服务方法，点击可以查看服务方法实体详情，同时方法实体也可以关联服务主机，当然，主机也可以反向找到服务实体。
4.3 实体列表
对于大部分实体类型，全栈可观测提供了实体列表，当实体数量较多时，支持筛选、翻页。
4.4 应用-Kubernetes-基础设施 数据融合
当数据接入比较完整时，以一个cart服务为例，可以在查看它关联的方法与服务主机，Kubernetes实体，还有MongoDB等基础设施。由于关联都是双向的，数据库也可反向关联Trace服务。order服务也可以查看它相关的Pod信息。
4.5 在多个位置使用数据实体建模
数据建模的强大能力，不但可以在全栈可观测App内部使用，还可以在您可以在 Log 页面、Trace详情标题处、Trace详细信息处、仪表盘处均可融合使用。只需要简单的配置。
5. 总结
日志服务新版本全栈可观测应用，为用户提供了多种数据融合、关联增强功能，在提供多样化的指标查看的同时，使得问题定位、指标分析更加准确、直观，整体更加实用。
- 实体类型建模，定义数据模型。通过建模实体类型，将原有的单独指标抽象成实体，形成关联，并在实体上定义关联的指标，形成全面、实时、精细的数据展示。
- 实体类型关联，快速定位问题。全栈可观测的实体类型关联功能，为用户提供了关联分析功能，支持实体之间的双向关联，使得数据关联更加清晰，帮助用户快速定位问题。
- 事件驱动，高效的自动化告警。基于全栈可观测的实体类型事件告警，支持基于实体类型事件的告警，大幅提升用户告警的自动化程度。
以上这些新特性，更加凸显了全栈可观测提供的一站式IT系统可观测能力，切合用户需求痛点，保障数据可靠性、提升数据价值、提高数据分析效率。
5.1 立即体验
SLS Playground中的全栈可观测Demo，内置了实例、演示数据、可视化图表等资源，提供了完整的演示环境，便于您快速了解及体验功能。
