在前面的系列博文中，我們說自定義業務計數器步驟：

1、分析業務，規劃好監控跟蹤指標

2、定義指標收集器

3、侵入編程(盡量在開發時分離業務實現與監控指票的收集代碼)收集指標

4、開發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》的系列到這篇就完成了，僅把自己的粗略認識分享給大家，歡迎指正！

總結

以上是生活随笔為你收集整理的asp.net core监控—引入Prometheus（六）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。