日志分析
日志，想必大家不陌生，程式遇到一個意想不到的問題（俗稱BUG），研發同學會本能的想到看下運作日志；網站受到攻擊，安全同學第一反應會是查下通路日志找出兇手；需要統計業務的PV/UV，營運同學也是會想到日志，做個統計。這些都是在做日志分析。
上圖可以看到，日志分析面對業務場景、時效性要求以及相關業務角色都很多，另外，産生日志的伺服器、程式多的都數不過來。密碼對這麼複雜的場景，如果我們還是用原始的 Linux 指令來做分析，那頭發絕對是保不住了。
有沒有一個一體化的平台來幫我們解決這個問題呢，既能友善的把資料接入，又能快速的進行各種業務分析，還能把分析結果展示到酷炫的報表，甚至，都不用我整天盯着，系統發現問題自動告警。SLS 就是為此而生的。
SLS
SLS 是阿裡巴巴自主研發的、雲上一站式日志分析平台。請看下圖 SLS 的生态圖，SLS 已經做到了資料想來就來（各種資料協定和工具、SDK）、不服就幹（查詢百億資料秒級傳回、各種報表供選擇）、說走就走（對接各種資料平台）。
你以為就這麼多？當然不止！！！除了資料分析的一站式服務，SLS 還提供了不同資料業務場景的增值服務，比如新冠病毒疫情APP（全免費）、阿裡雲成本管家、K8S事件中心，以及日志審計服務。
SLS vs ELK
除了 SLS，業界也有一些很優秀的日志分析産品和解決方案，這裡就選廣受歡迎的自建 ELK 方案做一個對比。對比方案如下：
資料寫入性能和存儲壓縮效率
從下圖測試結果可以看出，相同資料量寫入，SLS 的時間開銷隻有 ELK 的 35%，這裡自建 ELK 可以通過加入 Kafka 來提高寫入性能，接近 SLS，是以 SLS 并不算是絕對優勢。從落盤資料量大小來看，SLS 的壓縮效率更優。
資料讀取性能
這裡資料讀取對比測試有兩個常用的場景：簡單日志查詢和涉及統計分析的聚合計算。下圖為測試結果，在日志查詢場景中，在面對億級資料量，二者都達到了秒級傳回。當查詢并發度較低時，二者性能接近，随着并發度增加，SLS 優勢凸顯出來。在聚合計算場景下，二者的性能旗鼓相當。
成本費用
下圖是成本對比計算細節，SLS 有絕對優勢。有一點，SLS 的費用随着資料量增長而線性增長，也就是說跟資料量比較敏感；但是 ELK 的投入是階段性的，直覺上是增長較慢，這其實是一種錯覺。
綜合對比
從以上對比測試結果來看，SLS 在并發較高的查詢場景，以及成本費用上有明顯優勢。
從綜合的場景來看，自建 ELK 是一套日志分析解決方案，需要自行搭建和運維。而 SLS 則是一站式的日志分析平台，使用者無需關心平台實作和運維，而是将精力放在業務分析上。
是以整體來說，SLS 的成本效益遠要比自建 ELK 高。
從 ELK 遷移到 SLS
我的自建 ELK 裡面存儲大量的資料，通過全方位對比，決定轉向使用 SLS，我的這些曆史資料怎麼遷移到 SLS？
其實 SLS 早有方案，3個指令即可解決：
> pip install aliyun-log-python-sdk aliyun-log-cli -U --no-cache
> aliyunlog configure <access_id> <access_key> <endpoint>
> aliyunlog log es_migration \
--cache_path='/root/es_migrate/nginx.access' \
--hosts='elastic:[email protected]:9200' \
--indexes='nginx.access.2020-*' \
--logstore_index_mappings='{"nginx-access-log": "nginx.access*"}' \
--project_name='my-project' \
--time_reference='@timestamp' \
--pool_size=3 要是你說“遷移過程中意外中斷了怎麼辦”，優秀！且看下文。
Q：遷移程式跑到一半意外中斷了，怎麼辦？重新開始是不是會從頭開始遷一遍？資料會重複嗎？
A：調用參數中
cache_path
指定遷移狀态的存放位置，當遷移程式中斷後，重新打開時指定相同的
cache_path
便可以繼續遷移任務，不會有資料重複。也可以主動中斷，更改遷移參數後，比如
pool_size
，
batch_size
，再重新開機。
Q：ES 中存儲大量冷資料，index 都是 closed 狀态，全部打開會給伺服器很大壓力，怎麼做遷移？
A：基于斷點續傳功能，分批進行遷移。在确定好遷移任務後，開啟一部分 index，執行遷移指令開始遷移，完成後關閉這些 index，開啟另一批 index，執行完全相同的遷移指令，會自動繼續執行新的遷移任務。分批依次執行，直到全部完成。
Q：遷移程式正常退出，但是資料遷移不全，怎麼解決？
A：如果 ES 的吞吐量較小，大規模的資料讀取可能會導緻 ES 中的 index 暫時不可用，遷移會跳過這些 index，建議改小
pool_size
。出現資料遷移不全時，可以确認
cache_path
中的内容沒有被更改後，重新運作相同的遷移指令，會繼續遷移被跳過的資料。這個繼續遷移過程可以執行多次。
還有問題？沒關系，這裡有深入靈魂的資料遷移
官方最佳實踐，還有技術風的
使用文檔。
什麼，看文檔不是你的風格？沒關系，拿起手機，釘釘掃文末二維碼，直接找客服做技術支援。
結語
如上文所說，ELK 是一個很優秀的日志分析解決方案，但是如果你隻想專注在業務，不想浪費寶貴時間在平台搭建、運維、性能優化這些技術細節，那就交給 SLS。
又或者說，你在追求極緻的資料分析性能，而且又對成本效益特别挑剔，那 SLS 特别适合你。
有任何問題請拿起手機，打開釘釘，掃描下面二維碼加入 SLS 服務群，技術支援會第一時間回複。
另外，還可以關注公衆号，不定期發送幹貨技術文章，就等你來。