SLS全新查询分析体验—v2.0总结与思考

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
对象存储 OSS,恶意文件检测 1000次 1年
简介: 随着SLS(阿里云日志服务)近几年迅速发展,目前已经服务阿里云上万级客户,同时也成为了阿里云经济体的基础设施,为DevOps、AIOps、大数据分析、运营服务、大数据安全、成本管理等多个场景场景保驾护航。SLS产品控制台作为SLS的门面,受到了用户们的厚爱,目前已是阿里云控制台PV/UV Top 5的核心产品,SLS团队也一直在致力打造功能便捷易用,持续稳定高效、性能表现卓越的控制台产品。

随着SLS(阿里云日志服务)近几年迅速发展,目前已经服务阿里云上万级客户,同时也成为了阿里云经济体的基础设施,为DevOps、AIOps、大数据分析、运营服务、大数据安全、成本管理等多个场景场景保驾护航。SLS产品控制台作为SLS的门面,受到了用户们的厚爱,目前已是阿里云控制台PV/UV名列前茅的核心产品,SLS团队也一直在致力打造功能便捷易用,持续稳定高效、性能表现卓越的控制台产品。

云原生下的机遇和挑战

云原生无疑是近年来最火的名词,相关的技术如K8s、容器、Prometheus、Service Mesh等快速发展,云原生技术带来了革命性的变化,各大企业上云后应用监控和管理的方式也在随着发生改变。在云原生时代,CNCF(Cloud Native Computing Foundation)提出的可观察性(Observability)中表示:监控告诉我们系统的哪些部分是工作的,而可观察性告诉我们哪个部分是为何不工作的,利用Logging,Metrics,Tracing这三大数据的特性:Metrics用来发现问题,Trace发现异常节点,异常节点的Logging来定位根因。SLS也紧跟OpenTelemetry的发展,从底层支撑了这三类数据源,在原先Logging、Trace场景之后,也支持了Metrics类数据源和Prometheus协议。

对于SLS控制台来说,如何做好可观察性是非常有难度的,在前台上将三类数据最佳的使用场景有机结合起来,形成一套直观清晰且编便捷的交互理论,我们制定的几大原则:

  • 布局的一致性(Logging、Metrics、Tracing)
  • 功能可拓展性
  • 同类功能的聚集性
  • 次要操作就近原则
  • 操作交互可回溯

查询页面是最高频使用场景

SLS一直致力于发展成一个DevOps的数据中台,为用户提供丰富的机器数据接入、存储、分析、可视化、数据加工等能力,我们也可以轻松地在SLS控制台完成这一系列的工作。当用户完成了数据接入后,几乎所有有关Logging/Metrics/Tracing的操作都在查询页面完成。

查询页面是最高频使用场景

可以说做好查询页面的用户体验是SLS控制台非常重要的一环。

页面分析和需求收集

v2.0查询分析页面,我们从两个方面来进行前期规划:

  • 对旧版的页面进行数分析,从中提取到关键功能和用户习惯路径,针对性强化和弱化
  • 收集深度用户的需求和业界做法

1. 数据分析

热力.png

提取一段时间的埋点数据,并制作热力图,非常直观可以看到查询页面的高频操作分布,这里我们可以看到几个明显的弊端:

  • 查询按钮和时间选择异常高频,而两者之间的操作路径间隔较长,需要整合相关功能
  • 设置相关功能按钮的分布比较杂乱,左下角的设置按钮几乎无操作而日志右上方的设置功能存在语义重叠
  • 原始日志、liveTail、日志聚类、统计图表的使用频次需要调整顺序

2. 需求和功能拆解

有数据支撑之后,我们还需要收集深度用户的一些需求,避免细节太多这里提出两个比较有代表性的例子:

2.1 上下文

上下文功能一直是SLS非常核心的功能,当我们通过查询得到了一条日志后,很自然需要去找到前后日志并分析问题产生的原因,这个时候做好查询结果到上下文预览的链路是非常重要的。

shangxiawen.gif

旧版上下文通过右侧弹层实现,我们收到一些很典型的问题反馈:

  • 右侧弹层的出现视觉上的冲击比较强,和原始日志割裂严重
  • 可视区域较小,如果单条日志较大,无法完全看完整条日志
  • 只有过滤功能,二次交互比较鸡肋

shangxiawen2.gif

新版上下文改用下方划上交互,减轻了视觉上变化带来的冲击,其次日志查看和原始日志类似,交互保持一致性的同时,可视区域和原始日志一样,能容纳页面80%的空间给大日志进行展示,最后也增强了高亮显示和过滤的相关功能,整体体验更加友好

2.2 查询分析框遮挡

当我们查询分析语句过大时候,旧版的很容易出现遮挡问题,需要通过整个页面的滚动条来解决:

searchBar.gif

新版我们支持了滚动收起+折叠查询的交互模式,同时支持固定框

searchBar2.gif

设计详细

界面的详细设计,以专业,高效,简洁,清晰为主要设计原则,吸收了行业优秀产品的视觉及交互亮点,力争为用户打造易学,易用,清晰的产品体验,并希望在UI迭代的同时,逐步建立和完善SLS视觉体系。

旧版

旧版

新版

新版

1. 页面总体布局

从众多SLS用户的习惯反馈和经验来看,此次界面设计中总体布局与旧版基本保持一致,部分功能区域的内部元素位置做了适当调整,需要遵循的还是大的设计方向:同类功能的聚集性、次要操作就近原则

总体布局

1.1 Title行

将日志库/快速查询详细信息隐藏到左侧Title中进行悬停显示,右侧按照使用频率对排列相应的功能,保留从日志库到快速查询、告警等资源的延展,折叠设置和分享功能,设置功能以Tab形式也方便后续扩展,遵循:功能可拓展性

title行

1.2 Search行

根据次要操作就近原则,主要有以下2个变化:

  • 原有Title行时间选择功能移动到搜索按钮和查询按钮中间

    明确时间选择功能的附属属性和优先级,同时方便操作。为强调查询按钮的最高优先级,将时间选择功能调整为次按钮样式,减少主色过多产生的视觉噪声,突出主要功能。
  • 自动刷新功能从集成到查询分析按钮中

    符合其“按自定义时间自动实时查询”的语义,这也遵循**次要功能就近原则**。
    

    search行

1.3 Histogram

保持原有Histogram样式,底部红色解释性文字改为深灰色,减少页面整体颜色数量,页面更统一,更沉静。

1.4 Tab

Tab样式更加精简,逻辑上还是与下方内容联通,明确Tab与内容的从属关系;同时将旧版Tab行右侧的日志样式配置转移到日志内容上方的工具栏,明确日志功能逻辑和显示逻辑之间的关系,显示配置同样也是是遵循了就近原则。

1.5 工具栏

工具栏中对于日志显示设置功能较为复杂,本次改版重点对该位置进行了功能的梳理。

旧版的内容列显示中集成了较多功能且组织相对复杂不易理解,通过埋点我们发现其中换行与整行显示功能较为高频,满足用户对不同类型日志的查看需求,而JSON默认展开层级相对次要,其他功能并不常用,保留换行及JSON设置功能,并按照重要性分主次显示:

原有内容列设置过于繁杂|center

原有内容列设置过于繁杂

从用户的使用反馈上来看,我们此次新增了原始模式和表格模式两种形式的日志显示方式,并进行个性化的设置,设置功能下来设计也有比较强的可扩展性:

  • 原始显示模式

    以原始模式的特点来看,重点在于SLS对日志进行的推荐样式显示,保留高频整行、换行功能;其次提供设置图标按钮,将呼声最高的tag设置提出,同时也保留JSON配置,这样设计也方便扩展更多的个性设置功能。
    

    原始模式

  • 表格显示模式

    表格显示模式更像一种专注模式,更加直观清晰,表格模式下tag被平铺所以更加需要突出的是列设置模式,统一的配置方式也不会给用户带来困扰
    

    另外,将翻页器移至与显示工具同行,方便感知当前位置的同时,也增加了日志的显示高度

1.6 快速分析

与旧版基本相同,在UI元素及微交互方面有所改进,下文中会涉及。

1.7 Log

Log功能布置方面,将 上下文查询 和 Livetail 这两个较为常用的功能从下拉中独立出来,方便高频功能的操作,与新增的tag标签集成显示在日志首行。

字体方面,采用了代码字符较为适用的等宽字体,显示更清晰,更习惯,更亲切。

2. UI元素

2.1 颜色

旧版主色为浅青色:#00c1de,新版改为深蓝色:#0070cc,相比之下,新版主色亮度降低,饱和度增加,色彩感受更稳重,专业,更有信任感:
颜色
采用新版深蓝色为主色的另一个原因是,在使用过程中,发现当字体较小时,主按钮上的文字的辨识度存在问题:
undefined
即主色与白色的对比度较低,造成按钮文字显示并不足够清晰,为了定量确定主色与白色文字的对比度,我们做了如下验证:
颜色
旧版的青色与白色文字的对比度是2.16:1,较大幅度的小于WCAG 2.0 AAA标准的4.5:1;
新版的深蓝色:
颜色

新版颜色为阿里云大多数产品使用的页面主色,通过数据发现,其与白色文字的对比度符合WCAG2.0 AAA标准,在颜色传递的主观感受及数据体现的清晰度上来讲,该颜色作为页面主色更为合适。各页面将逐步全面替换旧版主色。

整体配色方面,有意体现页面“统一、清新、轻”的视觉感受,克制颜色色相的使用,保证页面主要任务的突出地位。取消histogram文字内容的红色,减少页面上的视觉噪声。

为了改观现有界面稍显陈旧的观感,在灰色的使用方面,加入主色色相,如快速查询区域和工具栏区域的底色#FAFBFD,快速分析当前选中底色#E8F0F6,快速分析分割线#E5EEF3;日志key的底色#E5EEF3;这些位置的带有主色色相的灰色,营造了界面的协调感,使界面不再陈旧原始。

颜色

2.2 图标

为了满足不同形状图标设计,使不同形状图标在整体审视时有着大致相当的视觉权重,制定绘图范围框,不同形状图标在对应的参考线内设计图形即可:

图标

对于线性图标,线型宽度模数为8,以8的整数倍规定线型粗细,不同疏密程度的图标,线型粗细可上下增减,画板大小1024px,基础描边粗细为64px。
图标风格外圆内方,圆角大小根据所处位置灵活调整,部分图标效果:

图标

3. 交互

在优化交互细节的同时,我们也做了一些大胆的交互尝试,如上下文浏览、Livetail的展示。

3.1 优化交互细节

  • 取消日志显示区域hover底色变化的交互:旧版日志显示区域,鼠标hover的背景色会变化,鼠标经过时,底色与key的底色对比度较低,影响日志的观察,且底色变化在此处没有实际用途;
  • 快速查询字段,鼠标hover底色变化,增强用户操作感知,同时点击整条底色区域,均可展开字段内容,点击区域变大,提高操作效率,另外旧版的眼睛图标,改成了更贴合语义的箭头图标;

快速查询

3.2 较大变化交互

1、滚动条向下滑动时,日志工具栏吸顶,隐藏搜索框及histogram,方便用户在观察过程中进行各项操作。另外,由于翻页器与工具栏集成,节省了纵向空间,页面内容划分更清晰;

翻页器

新版

翻页器

旧版

2、重新规整的日志表格显示模式,展示更为清晰,专业,除了自定义列设置,用户可任意拖动列宽,按需进行长日志的展示,且系统会记住用户的偏好设置,下次进入该日志,将展示用户上次使用时设置的列宽。

列宽设置.gif

表格模式拖动列宽

3、上下文、Livetail展示方式做了较大转变,展示载体由右侧滑出的pannel改为了从底部滑出,这样的优点:

  • 增强了当前日志与上下文/Livetail之间的紧密性,遵循同类功能聚集性
  • 上下滑设计,遵循可回溯性;
  • 后续原始日志上的功能可扩展,遵循功能可拓展性
  • 增加了上下文浏览/Livetail显示窗口的面积,可以看到更多的日志内容;

undefined

新版上下文浏览

undefined

旧版上下文浏览

undefined

新版Livetail

undefined

旧版Livetail

4、同时,在上下文及Livetail中,增加了高亮显示和过滤条件功能。

  • 高亮功能,输入框中输入关键词,通过回车按钮即可highlight对应字段,已选择的高亮字段存储在输入框头部的下拉中,高效且节省了界面空间,但也存在缺点:需要较小的学习成本;回车后的效果感知不明显,后续将做优化。
  • 新版上下文/Livetail高亮功能交互
    过滤功能类似高亮功能,由于过滤条件功能更重要,回车后,过滤条件显示在输入框后,方便观察,可以随时增减过滤条件。

LiveTail

新版上下文/Livetail高亮功能交互

写在最后

云原生下的可观察性日益受到企业的重视,在安全、稳定的基础上,为了更好的服务各种可观察性场景,SLS控制台对于整体页面的交互体验和性能也会持续探索和优化。灰度测试过程中也收到了用户宝贵的意见建议,也得到了用户的反馈和肯定,我们会随时倾听用户的声音,与用户一起,打造易用,易学,清晰的SLS,欢迎一起交流。

用户反馈

特别鸣谢:@吕兆健 设计师对于SLS控制台的贡献

欢迎各类前后端开发、大数据、分布式、机器学习的同学加入,招聘详情: https://talent.alibaba.com/off-campus-position/629751

知乎:https://zhuanlan.zhihu.com/aliyunlog
微信公众号:日志服务 or LogAnalytics
哔哩哔哩:https://space.bilibili.com/630680534
开发者社区(存储):https://developer.aliyun.com/group/storage/#/?_k=c756p3

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
12天前
|
存储 SQL 监控
|
12天前
|
运维 监控 安全
|
15天前
|
监控 关系型数据库 MySQL
分析慢查询日志
【10月更文挑战第29天】分析慢查询日志
35 3
|
15天前
|
监控 关系型数据库 数据库
怎样分析慢查询日志?
【10月更文挑战第29天】怎样分析慢查询日志?
32 2
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1632 14
|
1月前
|
存储 消息中间件 大数据
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
大数据-69 Kafka 高级特性 物理存储 实机查看分析 日志存储一篇详解
35 4
|
1月前
|
SQL 分布式计算 Hadoop
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
Hadoop-19 Flume Agent批量采集数据到HDFS集群 监听Hive的日志 操作则把记录写入到HDFS 方便后续分析
45 2
|
2月前
|
SQL 存储 缓存
高基数 GroupBy 在 SLS SQL 中的查询加速
本文详细介绍了SLS中的高基数GroupBy查询加速技术。
112 17
|
1月前
|
监控 网络协议 CDN
阿里云国际监控查询流量、用量查询流量与日志统计流量有差异?
阿里云国际监控查询流量、用量查询流量与日志统计流量有差异?
|
2月前
|
缓存 监控 算法
分析慢日志文件来优化 PHP 脚本的性能
分析慢日志文件来优化 PHP 脚本的性能

相关产品

  • 日志服务