内容最全：程式日志是由程式員給出，在重要的地點、變量數值以及異常都會有記錄，可以說線上90%以上bug都是依靠程式日志輸出定位到
格式比較随意：代碼往往經過不同人開發，每個程式員都有自己愛好的格式，一般非常難進行統一，并且引入的一些第三方庫的日志風格也不太一樣
有一定共性：雖然格式随意，但一般都會有一些共性的地方，例如對log4j日志而言，會有如下幾個字段是必須的：
時間
級别（level）
所在檔案或類（file or class）
行數（line number）
線程号（threadid）
程式日志一般會比通路日志大1個數量級：假設一個網站一天有100w次獨立通路，每個通路大約有20邏輯子產品，在每個邏輯子產品中有10個主要邏輯點需要記錄日志。
則日志總數為：
每條長度為200位元組，則存儲大小為
這個資料會随着業務系統複雜變得更大，一天100-200gb日志對一個中型網站而言是很常見的。
大部分應用都是無狀态模式，跑在不同架構中，例如:
伺服器
docker（容器）
函數計算（容器服務）
對應執行個體數目會從幾個到幾千，需要有一種跨伺服器的日志采集方案
程式會落到不同的環境上，例如：
應用相關的會在容器中
api相關日志會在functioncompute中
舊系統日志在傳統idc中
移動端相關日志在使用者處
網頁端（m站）在浏覽器裡
為了能夠獲得全貌，我們必須把所有資料統一并存儲起來。
目标：要把各管道資料采集到一個集中化中心，打通才可以做後續事情。
在建立完成一個日志采集配置後，我們就可以在項目中操作各種日志了。
可能有人要問到，日志采集agent非常多，有logstash，flume，fluentd，以及beats等，logtail和這些相比有什麼特點嗎？
使用便捷：提供api、遠端管理與監控功能，融入阿裡集團百萬級伺服器日志采集管理經驗，配置一個采集點到幾十萬裝置隻需要幾秒鐘
目标：無論資料量如何增長、伺服器如何部署，都可以保證定位問題時間是恒定的
例如有一個訂單錯誤，一個延時很長，我們如何能夠在一周幾tb資料量日志中快速定位到問題。其中還會涉及到各種條件過濾和排查等。
例如我們對于程式中記錄延時的日志，調查延時大于1秒，并且方法以post開頭的請求資料：
對于日志中查找包含error關鍵詞，不包含merge關鍵詞的日志
一天的結果
一周的結果
更長時間結果
這些查詢都是在不到1秒時間内可以傳回
關聯有兩種類型，程序内關聯與跨程序關聯。我們先來看看兩者有什麼差別：
程序内關聯：一般比較簡單，因為同一個函數前後日志都在一個檔案中。在多線程環節中，我們隻要根據線程id進行過濾即可
跨程序關聯：跨程序的請求一般沒有明确線索，一般會通過rpc中傳入tracerid來進行關聯
還是以使用日志服務控制台距離，線上通過關鍵詞查詢定位到一個異常日志：
點選上下文查詢後，既跳轉到前後n條上下文
顯示框可以通過“更早”、“更新”等按鈕加載更多上下文
也可以點選“傳回普通搜尋模式”進一步排查通過篩選框篩選threadid，進行精準上下文的過濾
dapper(google): 各 tracer基礎
stackdriver trace (google)，現在相容了zipkin
zipkin：twitter開源的tracing系統
appdash：golang版本
鷹眼：阿裡巴巴集團中間件技術技術部研發
x-ray：aws在2016年re：invent上推出技術
如果從0開始使用tracer會相對容易一些，但在現有系統中去使用，則會有改造的代價和挑戰。
今天我們可以基于日志服務，實作一個基本tracing功能：在各子產品日志中輸出request_id, orderid等可以關聯的标示字段，通過在不同的日志庫中查找，即可拿到所有相關的日志。
例如我們可以通過sdk查詢 前端機，後端機，支付系統，訂單系統等日志，拿到結果後做一個前端的頁面将跨程序調用關聯起來，以下就是基于日志服務快速搭建的tracing系統。
查找到特點日志後，我們有時希望能做一些分析，例如線上有多少種不同類型的錯誤日志？
我們先通過對"__level__"這個日志級别字段進行查詢，得知一天内有2720個錯誤：
接下來，我們可以根據file,line這兩個字段(确定唯一的日志類型)來進行統計聚合
就能夠拿到所有錯誤發生的類型和位置的分布了
目前有如下方式可以進行報警