日志服务Dashboard加速

本文涉及的产品
对象存储 OSS,20GB 3个月
文件存储 NAS,50GB 3个月
对象存储 OSS,内容安全 1000次 1年
简介: 阿里云日志服务致力于为用户提供统一的可观测性平台,同时支持日志、时序以及Trace数据的查询存储。用户可以基于收集到的各类数据构建统一的监控以及业务大盘,从而及时发现系统异常,感知业务趋势。但是随着收集到的数据量不断增长,特别是遇到业务峰值的时候,大盘报表展示会产生明显的延迟,无法及时查看重要数据。Scheduled SQL支持定时分析数据、存储聚合数据、投影与过滤数据,并将执行的分析结果存入用户指定的日志库或者时序库中,供用户后续分析使用。由于在聚合后数据量将大大小于之前,因而非常适合进行即时数据分析以及大盘展示。

背景

阿里云日志服务致力于为用户提供统一的可观测性平台,同时支持日志、时序以及Trace数据的查询存储。用户可以基于收集到的各类数据构建统一的监控以及业务大盘,从而及时发现系统异常,感知业务趋势。但是随着收集到的数据量不断增长,特别是遇到业务峰值的时候,大盘报表展示会产生明显的延迟,无法及时查看重要数据。Scheduled SQL支持定时分析数据、存储聚合数据、投影与过滤数据,并将执行的分析结果存入用户指定的日志库或者时序库中,供用户后续分析使用。由于在聚合后数据量将大大小于之前,因而非常适合进行即时数据分析以及大盘展示。下面我们以服务的请求成功率为例,介绍下如何基于Scheduled SQL加速大盘报表。

方案

假如我们需要查看以一分钟为粒度,一小时内的请求成功率。在构建报表的时候,需要基于当前不足一分钟的部分数据配置实时报表,而针对之前已满一分钟的历史数据配置历史报表。当然,如果用户觉得一分钟的数据延迟是可以接受的,就可以只配置历史报表,而不需要实时报表。假如当前时间为11:09:47,需要查看10:11:00一直到11:09:00的分钟级请求成功率,以及11:09:00到11:09:47的秒级成功请求率。

日志内容

字段名称

示例

描述

receive_time

1636616663654

时间戳,毫秒级

status

500

http状态码,200表示成功,其余表示失败

error_code

2001

错误码,标识错误原因

message

server is busy

错误描述

action_name

list_shop_product

访问的服务接口

user_agent

chrome

客户浏览器

历史报表

如图所示展示了分钟级的请求成功率,可以通过配置分钟级的ScheduledSQL任务,计算每分钟的成功率,并通过历史报表直接展示。因为只需要直接拉取聚合结果,不需要即时计算,所以展示速度大大提升。

实时报表

如图所示展示了秒级的请求成功率,因为只需要计算不到一分钟的数据,而不是1小时的数据,因而速度也得到的提升。

配置

下面仍然以请求成功率为例,向大家介绍下如何实现通过ScheduledSQL加速报表。

创建目标时序库

首先需要创建目标时序库存储ScheduledSQL的聚合数据。

创建Scheduled SQL任务

在存储服务请求的数据logstore查询界面,输入查询语句,点击查询/分析按钮,在成功执行查询分析之后,点击创建Scheduled SQL按钮。

*|select(__time__ - __time__ %60)astime, sum(IF(status =200,1,0))*1.0/count(*)AS success_ratio  from log groupbytimeorderbytime

计算配置

  1. 填入对应的作业名以及作业描述,写入模式选择日志库导入时序库
  2. 指标列指选择结果中的一列作为时序结果,此处选择success_ratio;
  3. Labels指选择结果中的哪几列作为时序数据的标签,此处留空即可;
  4. 时间列指时序数据的时间,此处选择time;
  5. 目标库选择刚刚创建的目标时序库;

调度配置

因为我们需要查看分钟级别的服务请求成功率,所以调度间隔还有SQL时间窗口均需要以分钟为粒度。用户也可以根据自己的需求进行调整。

  1. 调度间隔选择1分钟;
  2. SQL时间窗口填入@m - 1m ~ @m;
  3. 点击确认创建任务

查看任务详情

在作业菜单中点击Scheduled SQL,即可查看Scheduled SQL任务列表。点击刚刚创建的任务名称即可查看任务执行详情。在任务执行成功之后,我们就可以创建历史报表了。

配置历史报表

在目标时序库查询界面,执行查询语句,点击添加到仪表盘,即可创建历史报表。

*|select promql_query_range('success_ratio')from metrics limit1000

配置实时报表

在存储服务请求的数据logstore查询界面,输入查询语句,并选择时间范围为1分钟,点击添加到仪表盘创建实时报表:

*|select  __time__ astime, sum(IF(status =200,1,0))*1.0/count(*)AS success_ratio  from log groupbytimeorderbytime

总结

Scheduled SQL为用户周期性的进行分析数据、存储聚合数据、投影与过滤数据提供了较大的便利。用户还可以使用Scheduled SQL定时执行聚合任务,减少即时查询所需要的数据量,从而加速大盘展示。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
存储 Prometheus Kubernetes
轻量级日志可视化平台Grafana Loki接入nginx访问日志
轻量级日志可视化平台Grafana Loki接入nginx访问日志
1663 0
轻量级日志可视化平台Grafana Loki接入nginx访问日志
|
6月前
|
存储 Kubernetes Cloud Native
云原生|kubernetes|apiserver审计日志的开启
云原生|kubernetes|apiserver审计日志的开启
195 0
|
存储 JSON Kubernetes
Kubernetes【日志】日志架构介绍
Kubernetes【日志】日志架构介绍
Kubernetes【日志】日志架构介绍
|
存储 Prometheus Kubernetes
|
存储 JSON Kubernetes
Kubernetes 集群日志和 EFK架构日志方案
Kubernetes 集群日志和 EFK架构日志方案
793 1
Kubernetes 集群日志和 EFK架构日志方案
|
Kubernetes 容器 Perl
使用Logstash收集Kubernetes的应用日志
前言 本文同步更新到Github仓库kubernetes-handbook中。 很多企业内部都有自己的ElasticSearch集群,我们没有必要在kubernetes集群内部再部署一个,而且这样还难于管理,因此我们考虑在容器里部署logstash收集日志到已有的ElasticSearch集群中。
2994 0
|
Kubernetes 监控 Cloud Native
fluentd收集kubernetes 集群日志分析
EFK (Elasticsearch + Fluentd + Kibana) 是kubernetes官方推荐的日志收集方案,我们一起了解一下fluentd是如何收集kubernetes集群日志的,庆祝一下fluentd从 CNCF 毕业。开始之前,希望你已经读过Docker 容器日志分析, 本文是其延生的第二篇。
1336 0
fluentd收集kubernetes 集群日志分析
|
存储 JSON Kubernetes
kubernetes 的日志解决方案
对于一个分布式平台来说,日志收集处理是一个不可或缺的功能。目前,ELK Stack 已经成为最流行的集中式日志解决方案。本文主要梳理一下ELK的一些理论知识,并针对K8S容器云平台探讨一下集中式日志解决方案的可行性,并做一下简单实践。
424 0
kubernetes 的日志解决方案
|
数据安全/隐私保护
fluentd接入Elasticsearch的简单例子
最近想学习一下elasticsearch和fluentd的配合使用, fluentd比logstash节省太多资源了,所以就有了如下文章
1511 0
fluentd接入Elasticsearch的简单例子
|
数据采集 存储 Kubernetes
Filebeat 采集 Kubernetes 日志
由于容器的特性,在容器重新创建后日志会废弃掉,如何通过持久化和中心化的处理容器日志变成一个棘手的问题,如何通过 Elastic Stack 进行一站式的数据采集,数据清洗,数据落地,数据可视化,让数据发挥真正的价值呢?
679 0
Filebeat 采集 Kubernetes 日志