日志服务(原SLS)五月份发布:支持SQL进行日志实时分析

日志服务(原SLS)是针对大规模日志实时存储与查询服务,半年内我们逐步提供文本、数值、模糊、上下文等查询能力。在五月份版本中日志服务提供 SQL 实时统计分析功能 ,能够在秒级查询的基础上支持实时统计分析。

支持SQL包括:聚合、Group By(包括Cube、Rollup)、Having、排序、字符串、日期、数值操作,以及统计和科学计算等(参见分析语法)。

如何使用?

例如,对访问日志(access-log)查询 “状态码=500,Latency>5000 us,请求方法为Post开头”所有日志:

Status:500 and Latency>5000 and Method:Post*

在查询后增加管道操作符”|“,以及SQL后(不需要from 和 where,既从当前Logstore查询,where条件在管道前):

Status:500 and Latency>5000 and Method:Post | select count() as c , avg(Latency) as latency_avg, sum(Inflow) as sum_inflow, ProjectName Group by ProjectName order by c Desc limit 10

可以在控制台上获得结果(包括一些基本图表帮助理解):

为了获得更好体验,我们对SQL执行数据量做了限制(参考SQL分析语法最后部分)。在机房扩容后和下一步优化后(大约2个月),我们会放开该限制,敬请期待。

案例(线上日志实时分析)

​ 在几百台机器、十几个应用程序、面向万级用户定位问题是非常有挑战的,需要在多维度及条件变量进行实时排查。例如在网络攻击中,攻击者会不断地变化来源IP、目标等,让我们无法实时做出反应。

​ 这类场景不光需要海量处理能力,还需要非常实时的手段,SLS+LogHub可以确保日志从服务器产生到被查询在3秒以内(99.9%情况),让你永远快人一步。

例如在监控发现线上有非200的访问错误产生,一般老司机的调查方法如下:

  1. 该错误影响了多少用户? 是个体,还是全局

    Status in (200 500] | Select count(*) as c, ProjectName group by ProjectName
    
  2. 确定大部分都是从Project为“abc”下引起的,究竟是哪个方法触发的?
    Status in (200 500] and ProjectName:"abc"| Select count(*) as c, Method Group by Method
    
  3. 我们可以获取到,都是写请求(Post开头)触发,我们可以将查询范围缩小,调查写请求的延时分布
    Status in (200 500] and ProjectName:"abc" and Method:Post* | select numeric_histogram(10,latency)
    
  4. 我们可以看到,写请求中有非常高的延时。那问题变成了,这些高延时是如何产生的
    1. 通过时序分析,这些高请求延时是否在某个时间点上分布,可以进行一个时间维度的划分

      Status in (200 500] and ProjectName:"abc" and Method:Post* |select  from_unixtime( time - time % 60) as t,
           truncate (avg(latency) ) ,
           current_date
           group by   time - time % 60
           order by t  desc
           limit 60
      
    2. 通过机器Ip来源看,是否分布在某些机器上
      Status in (200 500] and ProjectName:"abc" and Method:Post and Latency>150000 | select count() as c, ClientIp Group by ClientIp order by c desc
      
  5. 最终大致定位到了延时高的机器,找到RequestId,可以顺着RequestId继续在SLS中进行查询与搜索
  6. 这些操作都可以在控制台/API 上完成,整个过程基本是分钟级别

什么场景适合使用SLS?

和数据仓库、流计算等分析引擎相比,有如下特点:

  • 针对结构化、半结构化数据
  • 对实时性、查询延时有较高要求
  • 数据量大,查询结果集合相对较小

​ 除此之外SLS与 MaxCompute、OSS(E-MapReduce、Hive、Presto)、TableStore、流计算(Spark Streaming、Stream Compute)、Cloud Monitor等已打通,可以方便地将日志数据以最舒服姿势进行处理。

​ 更多的内容请关注产品主页,欢迎关注存储服务公众,也欢迎加入VIP钉钉群

时间: 2024-11-02 07:44:47

日志服务(原SLS)五月份发布:支持SQL进行日志实时分析的相关文章

日志服务2.4版本发布:新增数值索引与区间查询

主要功能 支持数值类(Double/Long)索引与查询,使用说明 对于日志中延时.位置和精度等数据提供多维度过滤 支持与文本类数据进行多维数据查询(最大30维) 通过技术大幅优化降低了成本,启用新计费模式(3月20日生效,费用下降10%-85%),与其他方案成本对比: 与开源搭建的日志查询方案对比:是Elastic Search(ELK)成本 20%,Hive成本 50% 自定义TTL时长,具备100 PB 级长时间存储能力 数值类索引与文本类查询有什么不同?让我们来看2个例子: Case1

日志服务(原SLS)新功能发布(15)--控制台支持查看协同消费组(ConsumerGroup)消费进度

背景 日志服务中分区(Shard)是每个日志库下基本读写单元,每个分区能承载一定量的服务能力,随着日志数据不断增加,需要通过分裂增加Shard数量,对于多个Shard如果直接通过PullLogs接口拖取数据的话,需要处理负载均衡和故障恢复等各种问题,因此强烈建议使用Consumer Library(storm和spark streaming已支持通过conusmergroup消费数据),用户只需要关心数据处理逻辑,同时在控制台也提供协同消费进度查看功能供用户进行使用. 使用方式 查看Consum

日志服务新功能发布(1)--支持保序写入和消费

日志服务在上周新上线的版本,支持数据的保序写入和消费,shard的split和merge, server端consumer group的原生支持(除去对mysql的依赖),数据自动同步至oss等一些列新功能.本文主要介绍数据的保序写入和消费的功能. LogStore & Shard 关系 每个LogStore对应一类日志,对于同一个LogStore下的数据,所有处理逻辑相同(索引方式.导入odps.oss等配置) 每个LogStore由一个或多个shard组成,用于支持数据写入水平扩展 每个sh

日志服务(SLS) - 通过 Flink 消费Loghub日志

Flink log connector 介绍 Flink log connector是阿里云日志服务提供的,用于对接flink的工具,包括两部分,消费者(Consumer)和生产者(Producer). 消费者用于从日志服务中读取数据,支持exactly once语义,支持shard负载均衡.生产者用于将数据写入日志服务,使用connector时,需要在项目中添加maven依赖: <dependency> <groupId>com.aliyun.openservices</g

使用日志服务LogHub替换Kafka

前几天有客户问到,云上有什么服务可以替换Kafka? 怀着程序员的一丝小小的骄傲回复:日志服务(原SLS)下LogHub功能可以完全替代Kafka等产品,并且在性能.易用性和稳定性上更佳. 但客户将信将疑,于是花了一天时间整理一篇文章,简单从各个角度解释下为何建议用户从自搭Kafka换成使用LogHub. 背景信息 Kafka是分布式消息系统,由Linkedin原员工Jay Kreps编写(感兴趣的可以参见这篇文章<The Log: What every software engineer sh

5分钟搭建网站实时分析:Grafana+日志服务实战

阿里云日志服务是针对日志类数据一站式服务,用户只需要将精力集中在分析上,过程中数据采集.对接各种存储计算.数据索引和查询等琐碎工作等都可以交给服务.2017年9月日志服务加强日志实时分析功能(LogSearch/Analytics),可以使用查询+SQL92语法对日志进行实时分析. 在结果分析可视化上,除了使用自带Dashboard外,还支持DataV.Grafana.Tableua.QuickBI等对接方式.本文主要通过一个例子,演示如何通过日志服务对Nginx日志进行分析与可视化. 演示:线

【阿里云网站日志分析实践】通过Log Service日志服务导入MaxCompute分析

免费开通大数据服务:https://www.aliyun.com/product/odps 日志服务收集的日志除了可以被实时查询外,还可以把日志数据投递到大数据计算服务MaxCompute(原ODPS),进一步进行个性化BI分析及数据挖掘.通过日志服务投递日志数据到MaxCompute具有如下优势: 使用非常简单.用户只需要完成2步配置即可以把日志服务Logstore的日志数据迁移到MaxCompute中. 避免重复收集工作.由于日志服务的日志收集过程已经完成不同机器上的日志集中化,无需重复在不

日志服务十大经典问题

日志服务十大经典问题 一. 非阿里云的机器能用logtail吗? 能用,装好logtail之后要额外做一个配置 先找到自己的阿里云账号ID,例如:123456 Linux touch /etc/ilogtail/users/123456 Windows 原理同Linux,创建.删除用户标识同名文件到目录 C:\LogtailData\users C:\LogtailData\users\123456 注意:非阿里云的机器,或者是阿里云的ECS但是跟日志服务不是一个账号买的,都必须做这一步 二.

阿里云-日志服务-Log4j写入日志

---------Maven依赖--------- <dependency> <groupId>com.aliyun.openservices</groupId> <artifactId>aliyun-log</artifactId> <version>0.6.6</version> </dependency> <dependency> <groupId>com.aliyun.opens