對於普通系統或者服務來說，一般通過打日志來進行埋點，然后再通過elk或splunk進行定位及分析問題，更有甚者直接遠程服務器，直接操作查看日志，那么，隨着業務越來越復雜，企業應用也進入了分布式服務化的階段，傳統的日志監控等方式無法很好達到跟蹤調用、排查問題等需求，可以想象，如果你的服務節點達到有很多很多（兩位數以上吧），而沒有一個自動跟蹤系統，那查找一個問題將成為噩夢。
那么，服務之間調用的問題是：
-
如何快速發現問題？
-
如何判斷故障影響范圍？
-
如何梳理服務依賴以及依賴的合理性？
-
如何分析鏈路性能問題以及實時容量規划？
-
如何在分布式服務進行日志監控呢？
首先大家會想到分布式鏈路追蹤系統，說到這，就得講 OpenTracing 規范，OpenTracing 是一個輕量級的標准化層，它位於應用程序/類庫和追蹤或日志分析程序之間。詳細介紹見 《
opentracing文檔中文版》。在谷歌論文《
Dapper, 大規模分布式系統的跟蹤系統》的指導下，許多優秀的APM應運而生，分布式追蹤系統發展很快，種類繁多，給我們帶來很大的方便。雖然目前市面許多優秀的APM系統，但是作為我們.NET程序員的選擇卻就少之又少了（甚至沒得選），幾乎各大分布式追蹤系統均提供java版的支持，而.NET上卻只有SkyWalking的
SkyAPM-dotnet一直在默默的支持着，辛苦了，大佬們。
好吧，既然不能做到技術選型，那么我們就開始工作吧。SkyWalking和Elasticsearch的安裝，網上一抓一大把，這里不在重復的介紹“如何安裝”和“如何使用”。
從SkyAPM-dotnet中，我們可以拿到團隊的官方示例，
https://github.com/SkyAPM/SkyAPM-dotnet/tree/master/sample，她分為請求端，前置端和后端（當然，你喜歡怎么叫都行），我稍微修改一下，做了一些數據和請求數上的調整，
本篇代碼不是重點(SkyAPM-dotne已經達到開箱即用的強大優勢)，希望得到的數據像下面這樣：
解釋一下這個數據是怎么來的（或者這個實驗的服務架設）：
-
后端：提供數據庫的查詢，隊列的接口等一系列數據操作的地方；
-
前置：提供接口的過濾和處理，可以把他理解為一個邏輯后端，或者一個API網關；
-
請求：提供請求，或者模擬串行或並行請求；
這樣從邏輯上理解就是1->2->3->2->1，其實一個請求從頭到尾然后在返回到前端也都是這樣的，你可以把他想象成我們常見的三層模型、等等。
啟動三個節點后，通過SkyWalking可以看到，Service數量是3，正是我們創建的三個服務節點，Endpoint表示所有連接的數量，DB和Cache作為數據庫（或緩存）的數量，MQ的數量、平均吞吐量、網絡拓撲圖等等。
整個界面一目了然，更多詳細介紹可查看官網解釋。
在.NET的生態圈中，曾經有ButterFly這樣的原生.NET框架來實現我們整個系統的鏈路追蹤，只是作者表示已不在維護，ButterFly放棄的原因之一也是因為.NET開源項目的參與者太少了，光靠一人之力是沒法做出一個穩定高效可用於生產的APM。作者轉而投入到了Skyapm-dotnet，所以，在.NET上，我們優先選擇有良好支持的skyapm-dotnet！