如何使用ARMS配置tengine的日誌監控

摘要： 業務實時監控服務 ARMS 很好的提供了這麼一個入口，為公司提供了一個實時查詢Tengine運行情況的解決方案。在未來，ARMS將很好的和ODPS為公司監控形成互補方案，tengine日誌日後可同時投遞到ARMS和MaxCompute中: ARMS響應第一時間的多維度報警； MaxCompute來做深層次分析，例如介面的請求數、響應時長等，並有針對性地進行調優。

最近公司通過業務實時監控服務 ARMS 成功搭建了基於tengine的日誌監控系統。這裡簡單分享一下使用ARMS用於監控tengine日誌的經驗。

公司發展至今，現階段所有介面都使用阿里的tengine作為web容器，類似nginx，在日誌中也記錄了包括host, url, ip, 包體大小，響應時長等信息。目前的業務需求場景是希望有一套系統來監控介面的異常，來及時發現系統的異常，並能具體到哪些項目、哪些伺服器、甚至哪些URL出現異常，提高分析問題和解決問題的速度。

tengine日誌分布到不同伺服器上，首先使用日誌服務來分別收集這些日誌。再以logHub作為日誌源，來進行監控。想到使用ARMS的其中一個最重要原因是因為我們系統tengine的日誌格式有一定的定製，需要有一個端到端監控產品提供的定製化特彆強的數據清洗功能，以及聚合計算+報警功能。

這裡詳細介紹一下ARMS吊炸天的日誌切分功能。

第一步，一個開始節點；

第二步，LogHub數據源過來默認是JSON格式，進行JSON解析，如下圖：

注意日期類型的時間格式，尤其是「小時」部分，默認格式是hh（12小時），需要改為HH（24小時）。

第三步，清洗，過濾掉這裡不需要監控的host，如下圖：

通過函數，過濾掉不以指定域名結尾的host。

第四步，解析URL。使用「單分隔符切分器」，將request欄位按照空格切分，分別獲取調用方式（GET/POST）、完整URL、協議版本。

第五步，區分錯誤碼。這裡主要是為了區分，返回碼是代表正常、還是錯誤。這裡只對錯誤的返回碼進行監控。下圖的例子是，返回碼是4xx或5xx的表示錯誤，其他表示正常。新增欄位is_error表示是否是「錯誤碼」，賦值1或0表示是或否。

第六步，配置伺服器IP和伺服器名稱的對應關係。配置了一個映射表如下：

注意，這裡一定要配置一個127.0.0.1的k-v關係，否則日誌切分預覽的時候會看不到這個「伺服器名稱」欄位。

至此，日誌切分全部結束。點擊「日誌切分預覽」，即可查看切分效果。點擊保存，下一步。

配置數據集，例如要監控介面的訪問次數，使用count(_line)；要監控平均包體大小，使用sum(包體大小)÷count(_line)；要監控平均響應時長，使用sum(響應時長)÷count(_line)。維度根據需要配置，此處配置為先伺服器，後介面域名。

至此配置全部結束，點擊保存，完成配置。即可啟動任務了。以上為簡單示例。

這邊展示我製作的其中幾項監控的大盤。

請求數效果圖：

響應時長效果圖：

包體大小效果圖：

錯誤碼個數效果圖：

運維人員通過對幾個圖表的觀察分析，可以很快得出一些異常情況發生的原因，並及時處理掉。

一個年輕的互聯網公司，需要不斷的成長。系統也一樣，需要不斷的提升、優化。業務實時監控服務 ARMS 很好的提供了這麼一個入口，為公司提供了一個實時查詢Tengine運行情況的解決方案。在未來，ARMS將很好的和ODPS為公司監控形成互補方案，tengine日誌日後可同時投遞到ARMS和MaxCompute中: ARMS響應第一時間的多維度報警； MaxCompute來做深層次分析，例如介面的請求數、響應時長等，並有針對性地進行調優。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！