日志服务(原SLS)_2.5发布:支持SQL进行日志实时分析

摘要: 日志服务在2.5版本中提供 **SQL 实时统计分析功能** ,能够在秒级查询的基础上支持实时统计分析

日志服务(原SLS)是针对大规模日志实时存储与查询服务,半年内我们逐步提供文本、数值、模糊、上下文等查询能力。在2.5版本中日志服务提供 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

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

为了获得更好体验,我们对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?

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

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

p2

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

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

本文为云栖社区原创内容,未经允许不得转载,如需转载请发送邮件至[email protected]

猜你喜欢

转载自1369049491.iteye.com/blog/2375429