前幾篇我們講到遙測資料、監控指標、儀表板與警示系統，

這些都是為了在測試右移的實踐中，能更快速且有效發現客戶環境的問題。

從埋遙測資料、設計監控指標與儀表板到定義警示系統，

最後一哩路，就是從茫茫Log海中找到有問題的遙測資料並回頭尋找產品的問題。

本篇會稍微提到ELK跟EFK，會說明這兩個英文縮寫各自代表什麼服務與簡單介紹

但主軸還是會放在QA怎麼使用這些服務和其背後的意義上。

ELK / EFK 的使用目的

隨著軟體雲服務的架構複雜化，各種log的收集與管理不可能到每台機器上去查

除了手動麻煩之外，對人員權限的控管與伺服器安全性的影響也會變得難以管理。

其實不只是像SaaS服務的遙測資料，一般傳統的軟體部署也會有日誌管理與查詢的需求

會需要像是ELK/EFK這樣的解決方案來去處理分散式系統的日誌管理問題。

ELK是ElasticSearch, LogStash, Kibana 這三個服務的字首縮寫

EFK則是把LogStash換成像是Fluentd的log收集服務

以下來簡單介紹各個服務的用途與實際應用。

LogStash

LogStash就是把分散在各地的Log搜集起來後，做資料預處理(Pre-processing)

直接舉一行Log的例子來說:

127.0.0.1 - - [11/Dec/2013:00:01:45 -0800] "GET /xampp/status.php HTTP/1.1" 200 3891 "http://cadenza/xampp/navi.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0"

可以藉由LogStash來定義篩選條件，把你想要的資料用指定欄位存起來，像是這樣：

{
     "timestamp" => "2013-12-11T08:01:45.000Z",
           "host" => "cadenza",
       "clientip" => "127.0.0.1",
       "response" => "200",
}

一般來說資料預處理的部分，如果沒有加入新欄位或是想看新種類的資料

就不會經常需要修改，是屬於一次工類型的work。

ElasticSearch

接著ElasticSearch作為資料集中儲存與快速搜索的全文檢索服務

除了能把不同類型的資料(系統日誌，應用程式日誌，網頁日誌)，分門別類地儲存之外

也可以建立索引(Index)來加快搜尋速度，並讓使用者可以對資料進行比較複雜的查詢。

以ElasticSearch的廣泛應用與網路資源豐富程度，學習起來非常友善。

Kibana

Kibana是ElasticSearch的前端GUI介面，可以用Web UI做資料查詢

比如說今天RD在程式裡對A功能埋了trace-id，它是一個uuid的index

你可以利用這個trace-id到web, application, operation等不同Log來源

用trace-id去查詢A功能的執行日誌，就可以找到錯誤訊息來找到問題根源

Kibana最方便的是Web UI輸入你想找的資料，就能快速查詢，非常方便。

另外一個方便的點是

使用Kibana做query所找到的搜尋條件跟結果會被包含在網址之中

所以如果用公司內部的通訊軟體傳網址給RD的時候，他也能看到相同的log

對於討論並記錄發現問題的點，或是進一步去尋找更多的線索也非常方便。

小結

我覺得ELK/EFK作為開源軟體來說，是一個QA工程師值得投資學習的項目。

原因是學習難度上不會太困難，網路上也有很多資源可以學習

而工作上可以帶來的應用效果可以說是非常的好，相當推薦！

上面有提到資料預處理(Data Processing)的部分

在像是ELK這種比較完整的服務建立起來前，很多時候會經過百廢待舉的陣痛期

需要土炮寫Shell script或是cronjob去記錄需要用到的資料

下篇來分享我自己當QA在Data-Driven轉型過程中的一些有趣經驗