閱讀890 返回首頁    go 阿裏雲 go 技術社區[雲棲]


日誌服務(原SLS) 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釘釘群,旺旺群(1526982410)。

最後更新:2017-05-19 10:31:15

  上一篇:go  小規模的流處理框架.Part 1: thread pools
  下一篇:go  《LOG4J2官方文檔》Chainsaw 可以自動處理你的日誌文件(通知appender的配置)