7年沉澱之作--滴滴Logi日誌服務套件

01 日誌服務面臨的挑戰

• 日誌採集能力：服務端、客戶端、Web、資料庫的日誌蒐集工作；
• 日誌ETL能力：日誌實時ETL、ETL鏈路監控，ETL鏈路質量度量；
• 日誌檢索能力：全文搜尋能力、日誌上下文還原能力；
• 日誌分析能力：Adhoc的日誌OLAP能力。

• 需要支援物理機、虛擬機器、容器化場景，以服務粒度進行日誌採集；支援彈性動態擴縮容；
• 需要支援海量、數十萬Agent監控、運維、多版本管理；
• 需要支援共享多租戶分級保障模型；
• 需要針對任務級別提供豐富的指標，故障診斷和自愈能力。

• ETL語義表達要簡單清晰可運維，同時與底層基礎設施解耦，對SQL表達方式是強需求；
• ETL鏈路涉及多個環節，各自有自己的指標體系，口徑不統一，問題定位與排查成本很高；
• ETL鏈路涉及日誌儲存與計算，在Quota內端到端彈性擴縮能力充滿了技術挑戰。

• Kafka磁碟IO熱點導致的叢集生產消費雪崩；
• Topic資源隔離差，流量突增、回溯消費，影響叢集穩定性；
• Kafka有大量的叢集和topic的操作需要平臺來承接社群Kafka-Manager能力缺失。

• ElasticSearch受制於元資訊瓶頸，叢集Shard數無法突破數十萬級，需要解決擴充套件性問題；
• ElasticSearch叢集資源多租戶與查詢隔離體系的缺失，是穩定性的最大殺手；
• ElasticSearch端到端立體化監控體系缺失，運維保障能力不足，需要解決運維友好性問題。

• 億級明細資料級的Adhoc查詢分析能力；
• 億級基數維度列高精去重場景能力的支撐；
• 端到端立體化監控體系的缺失，運維保障能力不足，需要解決運維友好性問題。

02 滴滴Logi日誌服務套件

• 服務保障的需要：全鏈路追蹤是穩定性保障的重要抓手；
• 業務運營的需要：A/B TEST、活動運營分析、端上使用者行為分析、精準營銷，對百MB/S日誌的秒級收容能力，TB級日誌的秒級搜尋能力強烈訴求；
• 業務安全的需要：識別攻擊源進行資產止損，安全審計與溯源，TB級別日誌Adhoc分析能力。

• 開源自主可控：Logi-Agent、Logi-LogX、Logi-KafkaManager、 Logi-ElasticSearchManager 各PAAS套件計劃全開源；

• 引擎穩定可靠：Agent 40MB/S的單任務採集效能，可控資源的隔離能力；LogX採集任務的實時ETL秒級延遲、計算效能的極致最佳化；滴滴kafka百GB/S的實時流量；滴滴ElasticSearch數十PB的索引儲存叢集穩定性99.95%；

  
  

• 服務運營沉澱：數十萬日誌服務任務端到端全鏈路保障日誌資料的及時性、完整性、可觀察性、運維友好性；資源的彈性排程與分級保障能力的產品化沉澱；

• 平臺專業易用：分鐘級完成日誌全鏈路的端到端自助接入；SQL模板+UDF的個性化清洗能力支援；百TB級資料秒級的檢索體驗。

03 滴滴Logi應用案例

• 顯著降低日誌使用、儲存成本
  全託管、彈性伸縮，免運維 冷備儲存，約0.02元/GB/月，顯著降低儲存開銷，支援1-365天自定義儲存時間；

• 快速發現、定位問題，提高業務穩定
  基於大資料流式計算實現介面效能與錯誤日誌的統計分析，提供介面呼叫關係、拓撲關係、上下游流量分析、服務錯誤定位、錯誤聚類等功能；

• 安全可靠
  可用性不低於99.9%，每天可處理上百TB日誌量 資料實時採集，分鐘級落盤，日誌儲存不丟失滿足日誌審計需求。

• 場景化分析模型
  使用者留存分析，使用者軌跡分析，使用者畫像分析；

• 基礎服務能力
  核心指標可實時查當日資料，實時計算，秒級產生資料，大盤支援整合報表；

  
  

• 資料分析能力
  非研發人員可自建指標，支援多型別視覺化報表，支援資料匯出隨心分析，支援omega資料上報資料；

  
  

• 多產品滿意度調研
  支援多組織多產品結構，支援線上自動化配置，支援抽獎，提高參與度。