隨著雲服務技術越來越成熟，作為一枚運維，不得不感慨雲端計算的發展對我的職業生涯起了積極推動的作用，一方面我可以通過雲服務來提高我的工作效率，另一方面我節省了更多時間來學習，在提高我專業度的同時，個人能力也越來越強，在此我就以阿里雲日誌服務，給我帶來的便利給大家做一個分享：

一，在使用阿里雲的日誌服務之前，我分析日誌的方法是這樣嬸兒的，如下圖。

通過rsyslog把伺服器上的日誌彙總到另外一臺機器上，然後使用指令碼來處理文字，獲取所需的資料。
這種方式在日誌分析上效率挺低的，還要耗費經歷去維護rsyslog服務。

自從使用了阿里雲的日誌服務後就省心多了。藉助阿里雲的日誌服務構造出來的一整套日誌分析系統是這樣嬸兒的，如下圖。

這裡主要用到阿里雲的三個服務，下面來挨個介紹一下我是怎麼使用的。
日誌服務（Log Service，簡稱Log）
這個是整個架構的核心點，我目前主要用它來實現的是日誌採集、日誌投遞以及日誌查詢分析。
1. 日誌採集
目前是在每臺機器上安裝logtail Agent，來採集日誌。在ECS上直接三條命令就安裝了，不需要做任何的配置就可以使用了，非常省力。
2. 日誌投遞
如上圖所示，可以把採集強調文字後的日誌投遞到OSS和ODPS中，這個稍後再說。
3. 日誌查詢分析
這裡是藉助於日誌服務中的日誌索引功能，通過控制檯來查詢日誌，我一般是用這個來跟蹤一些使用者的訪問行為，這裡查詢速度是非常快的，基本上都是一秒鐘內出結果。

當然還可以根據日誌服務的API來實現更多的查詢，我這裡就先不介紹了。
OSS
我會把日誌投遞到OSS中，主要是因為兩個需求。
1. 日誌歸檔儲存
把一些歷史日誌都存放到OSS中，以減少伺服器上佔用的空間。當然也不是所有歷史的日誌都存放到OSS中的，通過OSS中的生命週期功能來把更古老的日誌刪除就可以了。
2. 離線日誌分析
因為我也是剛剛把日誌分析這事遷移到阿里雲不久，有一些古老的指令碼需要通過檔案來處理日誌（這個需要點時間才能幹掉這些指令碼），目前我的做法是通過API把OSS中的日誌下載到ECS中，然後再讓那些古老的指令碼工作（要知道，ECS通過內網訪問OSS是免流量費的啦）
ODPS
ODPS中文名稱叫做大資料計算服務，不過剛剛看了一下它的控制檯，這個產品要下線了，取而代之的是一個叫數加的產品，其實就是再ODPS中套了一層殼，然後加了額外的一些功能。
數加這個產品暫時我還沒完全研究明白，還是接著說一下我最早使用ODPS分析日誌的事情吧。
把日誌投遞到ODPS中，是為了實現把資料更加統一的進行分析，出報表，據說使用Quick BI做報表是非常容易的，不過說來慚愧我一直都是拿ODPS單純的當個數據庫來使用的，還沒有用到Quick BI（不過我當時用ODPS的時候好像Quick Bi還沒有完善吧，哈哈）
二，這裡就舉一個簡單的例子吧：
通過ODPS的API，來統計週期時間內耗時最長的URL，然後生成報表通過郵件通知（自己生成的表格確實很醜）
比如我這裡剛剛統計到一些處理時間將近10秒的URL，通過排查發現都是因為呼叫了第三方的API，第三方的API介面耗時過長導致，豬一樣的隊友啊。

OK，以上就是我藉助阿里雲的日誌服務、OSS、ODPS（數加）來處理分析日誌的一些事兒。
三，總結受益
在把日誌分析切換完全切換到阿里雲之前，需要查詢東西都需要跑個指令碼來完成，查詢結果要等個十幾分鍾才能出來。（不知為何，當時還會歸集日誌還會產生重複日誌的情況，還得先做一遍去重，簡直就是噩夢）
現在完全利用了阿里雲的日誌服務之後，再有同事跑過來讓我跟蹤某個使用者的行為日誌，直接給他丟一個阿里雲日誌伺服器的控制檯連結，再加一個子賬號，讓他自己去查了；再有同事跑過來讓我查某個介面的使用情況，直接在ODPS上執行一條SQL語句就行了；當然很多事情都做成了自動化的，比如週期內定時捕獲日誌中的異常，然後傳送到相關負責人的郵箱中，我都不用參與了，之前的噩夢就這樣變成了春夢，哈哈。