asp.net core監控—引入Prometheus（六）

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

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》的系列到這篇就完成了，僅把本身的粗略認識分享給你們，歡迎指正！