在前面的系列博文中，我們說自定義業務計數器步驟：
- 分析業務，規劃好監控跟蹤指標
- 定義指標收集器
- 侵入編程(儘量在開發時分離業務實現與監控指票的收集代碼)收集指標
- 開發grafana展示模板，完成展示
結合《asp.net core監控—引入Prometheus》二，三，四，五4種模版的demo，來較爲深入分析瞭解一下這些步驟。
本系列是Prometheus和Grafan組合，這個組合擅長展示系統的實時跟蹤數據，如果是統計數據，它們不一定是最佳選擇。
1. 分析業務，規劃好監控跟蹤指標
這一點是最難的，首先要了解自己的項目解決的主要問題是什麼，比如商城第一要務是賣東西，單位時間內賣了多少，賣了多錢，是比較重要的，再考慮相對次要的問題，比如單位時間內什麼東西賣的多，單位時間內用戶的增加量等信息，羅馬不是一天建成的，建議先從重要的開始，逐漸在構建自己的監控跟蹤系統。
2.定義指標收集器
本系列博文中說到Prometheus四種類型的收集器，按照規劃好的監控指標，選擇適當的使用，一般情況下Counter（計數器）、Gauge（儀表盤）直觀，通俗易懂，Histogram（直方圖）、Summary（摘要）比較抽像，但它們更能從宏觀上展示業務狀況，統計學上更科學。
3.侵入編程(儘量在開發時分離業務實現與監控指票的收集代碼)收集指標
這部分我們在demo中有做分享，可能不是最好的解決方案，這部分可能要根據每個項目的架構來處理，努力把類似監控，日誌，跟蹤等非業務功能與業務代碼區分開來，減少耦合。另一方便，有一些監控數據對業務系統的耦合是比較緊的，比如《asp.net core監控—引入Prometheus（三)》的Gauge（儀表盤）中，展示的是訂單每個階段的數量，其實是不準確的，因爲當我們系統重啓時，這些值就會置零，如果修改代碼，每次啓動系統，從數據庫裏查詢出訂單各個階段的數量，來初始化儀表盤，表面上是可以的，但如果系統是分佈式部署，就會引來一個問題，每個節點或Pod都有一份數據，當用Grafana集中展示時，就要把節點累加，造成數據重複，系統運行後，每次下單，支付，發貨，觸發的是單節點儀表盤上的數值變化，這樣，運行一段時間就會造成數據即不是倍數關係，也不是增量關係；其實如果我們仔細分析的話，每個訂單實時的量不適合這種在應用中用加減來對外吐值，可以換一個數據庫或緩存的數據源來查詢展示，俗話說，不能在一個樹上吊死，我們要利用grafana不同的面板數據源都是獨立的這個特點，分別對待。
4.開發grafana展示模板，完成展示
這是個技術活了，首先要熟悉grafana的使用了，grfafan的相關的文章還不少；在grafana中，不同的數據源取數據的方式不盡相同，這個是學習點，還有grfana的一些函數也是很好的選擇，自動提示引入函數的功能能讓我們配置起來更簡便，還有不同的面板類型，有很多的屬性，能給我們的圖表錦上添花，多探索，多琢磨。
《asp.net core監控—引入Prometheus》的系列到這篇就完成了，僅把自己的粗略認識分享給大家，歡迎指正！