本文根據演講視訊以及PPT整理而成。
本文将主要圍繞以下三個方面進行分享：
- 建構背景
- APM的建構過程
- 未來展望
一、建構背景
二維火公司的整體架構體系分為三個階段，即從單機到面向服務化，最後到面向微服務的架構。是以，監控平台所需要監控的也是上文所提及的這三個階段，即從單機到分布式的名額日志，最後到APM。在單機時平台往往是靠使用者對故障進行回報的，在接到回報後相關技術人員手動登陸伺服器，人工輸入指令，對問題進行定位，不但會導緻故障的時延非常長，而且對開發人員的技術要求也很高。但随着公司的業務發展，公司的整體架構進行更新後，對故障的容忍度進一步的降低，此時，便需要一些集中化的方法去管理相關名額和日志。二維火公司分布式名額的實作方法如下，首先會在每台機器上安裝falcon-agent，來對所需要的名額，如網絡名額等進行采集，然後将這些名額傳輸到transfer，transfer把這些名額發送到自帶時序資料庫的同時，會轉發一份到InfluxDB，最後通過InfluxDB在Grafana裡進行視圖配置，以及一些相關操作如同比、環比操作。對于日志，則使用ELK架構，通過把相關的日志資訊如應用日志，nginx日志，Mysql日志等儲存在指定的檔案中，根據系統環境的不同，在VM下通過rsyslog，在Docker下通過log-pilot把日志傳輸到Kafka，然後通過logstash對不同的日志進行解析處理，并發送到不同的ES叢集，最後通過kibana進行視圖的相應配置。在二維火，ES的作用不僅僅是全文搜尋，還有資料分析，比如得到nginx的通路趨勢，還有一些核心應用的名額趨勢等。
但随着公司的發展，這一套架構已經不能夠完全滿足公司的業務需求了。事實上，大家經常會遇到這樣的問題，底層服務挂掉後，往往需要很長的時間來進行問題的定位。随着微服務化的發展，一些架構也需要随之更新，但在更新時會遇到很多問題需要解決，例如如何确認優化之後的架構是不是合理的，調用是不是合理的，如何提供一個有效的衡量名額，如何梳理複雜的依賴，來快速的進行問題定位，又比如作為提供方，哪些服務調用了我們的應用，調用的情況是什麼樣的，以此友善進行熔斷，限流等操作，這些都是在架構更新時需要考慮的問題。
二、APM的建構過程
二維火公司是從2017年開始研發APM平台的，當時業界有一些開源的産品，比如Zipkin，Pinpoint，Skywalking等。雖然使用這些開源軟體可以很快的進行平台的搭建，但是經過調研後發現這些開源軟體的功能比較單一，并不能完全滿足相應的業務需求，同時擴充性較低，是以二維火公司選擇了對APM平台進行自研搭建。進行自研平台的搭建雖然需要投入專員進行開發維護，但對于APM平台是可以完全掌控的，能夠很好的和現有的技術體系進行內建，并且可以很好的支援自定義擴充。其實上述所說的自研并不是從零開始，也有很多現成的方案進行參考，包括谷歌，阿裡等都有相應的案例分享。對于APM來說，主要分為以下幾個步驟，第一個是資料的埋點，第二個是資料的采集，第三個是資料的處理，第四個是資料的存儲，第五個是資料的展現，關于資料展現需要根據不同公司實際的業務需求進行處理，同時資料埋點目前有許多案例可以進行參考，便不過多叙述。接下來将主要圍繞資料的采集，處理和存儲進行更加細緻的介紹。
（1）資料采集
首先介紹的是資料采集，我們會在各個中間件的攔截層将鍊路的資訊進行采集，如果一個元件沒有攔截層的話，則會通過靜态代理的方式對埋點進行注入。當采集到鍊路資訊後，會進行采樣和下層的RingBuffer未滿的判斷，如果都滿足，此時會在業務線程裡使用Protostuff進行序列化操作并發送到RingBuffer，最後通過異步線程批量的将資料發送到Kafka中。在資料采集過程中，需要注意的是采集資料要盡可能的減少應用的性能損耗，降低主機的資源消耗，是以使用ProtoStuff進行序列化操作，ProtoStuff相比于其他方法，序列化後的資料量更小，同時在業務線程裡進行序列化後，可以進一步降低之後異步線程的CPU占用時間。但是這種方案也會存在一些問題，比如，采樣或者RingBuffer滿時，資料會丢失，同時名額計算不夠準确，并且缺少應用名額，如連接配接池、線程池等，是以需要對資料的采集過程進行相應的改進。改進後的資料采集過程增加了jvm，redis、Mysql連接配接池，dubbo線程池等名額資訊的收集并發送到Kafka，同時在用戶端進行預計算，把每個接口的統計資訊，比如請求數，平均響應時間等先行進行計算，是以在采樣或者RingBuffer滿時，名額資料也能保證不會丢失。對于資料采集來說，最為關鍵的是要盡可能的對重要資料進行完整的采集，同時降低對應用的損耗，在APM中最重要的兩種資料分别是鍊路資料和名額資料，是以下文主要介紹這兩塊資料的處理和存儲。
（2）資料處理
在資料擷取後，便要進行資料的分析和處理。目前業界常用的方法是流計算，而在二維火平台中則是使用flink進行處理的，一方面，flink的核心代碼很多是Java，能比較快速的掌握，另一方面，flink有以下幾個優點，一是優秀的視窗機制，能夠允許一定時間的亂序，二是api非常簡潔，三是具有完善的監控，可以很快的對性能瓶頸進行定位，四是送出方式簡便，flink提供web界面進行任務送出，同時flink還具有容錯性強，社群活躍性好，及時性高等優點。
首先是對于鍊路資料的處理流程，從Kafka擷取到資料後，如果資料量不大，則直接通過flink把資料寫入存儲中，但資料量很大的話，如部分行業的高峰期，便會進行采樣控制，通過對traceId進行哈希取模後再寫入存儲中，但高優先級或異常資料一定會寫入存儲中。
其次是統計資料的計算，首先啟動一個job，消費原始的鍊路資料，因為資料量會非常大，如果直接将資料發送到下一個任務進行視窗計算，這時任務間的網絡傳輸量會非常大，因為flink中用于network的記憶體是有限的，大資料量的傳輸就會演變成為瓶頸。事實上，對于原始的鍊路資料來說，每一批資料大部分都是對同一個接口的調用，是以在資料轉發到視窗之前，首先要進行預計算，通過把屬于同一個接口的統計資訊提前計算出來，以此來減少任務之間的網絡資料傳輸，之後進行細粒度化的的keyby操作，來減少熱點問題。在這之後以一分鐘的視窗計算低維的統計資料，如某個應用其中一台機器下dubbo提供者的接口，計算出接口的請求總數、失敗數、平均響應時間、tps、在各個響應時間區間的數量等，将低維的統計資料寫入TSDB的同時，同時發送一份資料到Kafka，這樣便可以通過新的job進行更大視窗的計算或者高維的聚合。在二維火，目前flink每天處理幾十TB的資料，主要用于資料轉發，依賴分析，實時名額計算，預聚合，SQL統計，元件異常警告等方面，可以平穩無中斷運作數月。
（3）資料存儲
對于資料存儲，主要分為鍊路資料的存儲和名額資料的存儲，對于鍊路資料存儲，我們存儲在hbase，需要通過hbase還原整個調用鍊路，通用的做法是将同一次調用的所有資料存儲到hbase的同一行，然後使用traceId作為rowKey，通過traceId還原整個調用過程。但在spanId是随機數的情況下，通過traceId查詢出來的資料，調用順序是無法保證的，是以增加了一個parentId，parentId是上層鍊路的spanId。通過使用traceId+parentId作為rowKey的方法，便可以一層層還原整個鍊路的調用過程，但是這種方法隻能通過RowKey進行鍊路的查詢，是以需要對存儲方式進行改進，即将查詢條件放入elasticsearch中，并關聯rowKey。是以在通過flink進行寫入資料時，首先把鍊路資料寫入Hbase中，并把一些查詢條件寫入ES中，此時在前端進行查詢時，既可以通過RowKey查詢，也可以通過條件進行查詢。
接下來是名額資料的存儲，考慮到随着資料量的增大，單機無法滿足全部的業務需求，是以選擇分布式時序資料庫Aliyun TSDB。Aliyun TSDB具有很多優點，以二維火公司為例，監控團隊規模不大，沒有太多人力來做時序資料庫的運維，而Aliyun TSDB可以做到零運維，同時Aliyun TSDB有着極佳的寫入性能，可以支援秒級的資料寫入。Aliyun TSDB還具有永久儲存，時間線無限制，多值寫入等其他優點，可以滿足二維火平台絕大部分的業務需求。目前二維火監控平台有近400個應用的鍊路統計資訊以及部分的主機資訊，在寫入Aliyun TSDB時沒有産生過反壓問題，對于低維查詢可以做到毫秒級傳回，但和其他時序資料庫一樣，仍然會有一些小問題産生，比如在高維查詢或者時間線過多的時候響應不夠理想，不支援topN等，這時便需要結合使用一些其他方法，例如對資料進行預聚合，使用redis進行處理等。
4）整體架構
目前，二維火監控平台整體的前期架構是在應用層采集到鍊路資料和名額資料，将資料發送到Kafka，通過flink對資料進行分析，分析後對資料進行存儲，最後在前端通過UI視圖對資料進行展現。經過一段時間的功能疊代後，目前的總體架構中，一方面增加了移動端的相關資料資訊，會把移動端的監控資料進行采集後一并發送到Kafka，同時也增加了撥測功能，另一方面将日志處理子產品遷移到flink中。
三、未來展望
二維火監控平台對于未來的功能更新主要集中在以下幾個方面，首先是進一步完善移動端監控以及撥測資訊，其次是實時告警，目前告警的時延超過一分鐘，希望未來能夠在一分鐘内進行告警，同時會進行AiOps的開發，如自動化的故障檢測和實時的告警收斂，最後将會探索平台與Service Mesh的結合。