.NET Core使用App.Metrics監控消息隊列(一)：初探

1、簡介

App Metrics是一個開放源代碼和跨平臺的.NET庫，用於記錄應用程序中的指標。App Metrics能夠在.NET Core或也支持.NET 4.5.2的完整.NET框架上運行。

App Metrics經過在內存中進行採樣和聚合，並提供可擴展性點以指定間隔將指標刷新到存儲庫中，從而抽象化了Metrics的基礎存儲庫，例如InfluxDB，Prometheus，Graphite，Elasticsearch等。

App Metrics提供了各類度量標準類型來度量事物，例如請求率，計算一段時間內的用戶登陸數，度量執行數據庫查詢所花費的時間，度量可用內存的數量等等。支持的指標類型包括Apdex，儀表，計數器，儀表，直方圖和計時器。

App Metrics還提供了運行情況檢查系統，使您能夠經過用戶定義的檢查來監視應用程序的運行情況。

使用App Metrics，能夠：

• 捕獲任何類型的.NET應用程序中的應用程序指標，例如Windows Service，MVC Site，Web API等
• 自動測量MVC或Web API項目中每一個端點的性能和錯誤
• 使用OAuth2保護API時，自動衡量每一個客戶端的請求率和錯誤率
• 選擇保存捕獲的指標的位置以及但願用來可視化這些指標的儀表板
• 經過特定於TSDB的報告擴展支持基於推和拉的指標收集，並經過HTTP以要求的格式公開指標
• 支持以所需格式將指標推送到自定義HTTP端點
• 支持以所需格式將指標寫入文件以供指標代理收集、

 

更多使用方式直接訪問官網：https://www.app-metrics.io/

 

2、實際業務場景

上面介紹了App.Metrics以及它支持的場景，可是讀完你必定會以爲很抽象，沒錯我也同樣。若是不是帶着實際的業務場景去看這些東西，其實仍是有點雲裏霧裏的。在實際的業務中咱們一般會把它用於兩個方面，一方面是包括CPU、內存在內的對系統級別的總體監控，園子裏有不少文章都作了demo供你們參考，你們能夠搜一下。另一方面是經過埋點的方式統計相關數據，後端一般使用InfluxDB做爲數據庫，並使用Grafana或者Prometheus來對數據進行展現。

本篇將介紹的使用方式是第二鍾，經過埋點的方式來對消息隊列進行統計，統計的數據包括 隊列數量、每一個隊列當前消息數量（已消費、未消費），以及消息的生成和發佈速率。

最後的樣子大致就是下面這個樣子：

 

3、InfluxDB 

在使用App.Metrics以前，咱們須要先準備好數據庫，也就是InfluxDB，首先快速瞭解一下InfluxDB是什麼：

InfluxDB 是用Go語言編寫的一個開源分佈式時序、事件和指標數據庫，無需外部依賴。

相似的數據庫有Elasticsearch、Graphite等。

其主要特點功能

1）基於時間序列，支持與時間有關的相關函數（如最大，最小，求和等）

2）可度量性：你能夠實時對大量數據進行計算

3）基於事件：它支持任意的事件數據

InfluxDB的主要特色

1）無結構（無模式）：能夠是任意數量的列

2）可拓展的

3）支持min, max, sum, count, mean, median 等一系列函數，方便統計

4）原生的HTTP支持，內置HTTP API

5）強大的類SQL語法

6）自帶管理界面，方便使用

 

Influx包含如下屬性：

database: 數據庫名，在 InfluxDB 中能夠建立多個數據庫，不一樣數據庫中的數據文件是隔離存放的，存放在磁盤上的不一樣目錄。

retention policy: 存儲策略，用於設置數據保留的時間，每一個數據庫剛開始會自動建立一個默認的存儲策略 autogen，數據保留時間爲永久，以後用戶能夠本身設置，例如保留最近2小時的數據。插入和查詢數據時若是不指定存儲策略，則使用默認存儲策略，且默認存儲策略能夠修改。InfluxDB 會按期清除過時的數據。

measurement: 測量指標名，例如 cpu_usage 表示 cpu 的使用率。

tag sets: tags 在 InfluxDB 中會按照字典序排序，不論是 tagk 仍是 tagv，只要不一致就分別屬於兩個 key，例如 host=server01,region=us-west 和 host=server02,region=us-west 就是兩個不一樣的 tag set。

field name: 例如上面數據中的 value 就是 fieldName，InfluxDB 中支持一條數據中插入多個 fieldName，這實際上是一個語法上的優化，在實際的底層存儲中，是看成多條數據來存儲。

timestamp: 每一條數據都須要指定一個時間戳，在 TSM 存儲引擎中會特殊對待，覺得了優化後續的查詢操做。

2）Point

InfluxDB 中單條插入語句的數據結構，series + timestamp 能夠用於區別一個 point，也就是說一個 point 能夠有多個 field name 和 field value。

3）Series

series 至關因而 InfluxDB 中一些數據的集合，在同一個 database 中，retention policy、measurement、tag sets 徹底相同的數據同屬於一個 series，同一個 series 的數據在物理上會按照時間順序排列存儲在一塊兒。

series 的 key 爲 measurement + 全部 tags 的序列化字符串，這個 key 在以後會常常用到。

 

4、搭建InfuxDB+Grafana 

OK，這篇是一個DEMO演示篇，因此咱們使用Dokcer快速的建立InfluxDB和Grafana:

docker run -d -p 8083:8083 -p 8086:8086 --expose 8090 --expose 8099 tutum/influxdb

docker run -d --name=grafana -p 3000:3000 grafana/grafana

 

運行成功以後咱們分別能夠訪問8083端口的InfluxDB和3000端口的Grafana：

 

 

 

 

 

 

咱們首先給InfluxDB添加一個用戶：

 

 

 添加完成後配置一下Grafana：

 

 

 

4、.NET CORE使用App.Metrics

這裏咱們使用.net core控制檯項目來演示（API項目例子已經有不少了，可是控制檯項目沒看到），新建一個控制檯項目 AppMetricsPractice：

經過NuGet引用App.Metrics和App.Metrics.Reporting.InfluxDB

 

 

 

 

 

 而後咱們就能夠愉快的使用了，簡單使用能夠以下：

static void Main(string[] args)
        {
            var metrics = new MetricsBuilder().Report
                .ToInfluxDb("http://47.99.92.76:8086", "metricsdatabase")
                .Build();


            var counter = new CounterOptions { Name = "my_counter", MeasurementUnit = Unit.Calls };
            metrics.Measure.Counter.Increment(counter,"MqQueueNmae");

            var task = Task.Run(async () =>
            {
                await Task.WhenAll(metrics.ReportRunner.RunAllAsync());
            });

            task.Wait();


            Console.Read();
        }

使用方式在官網有簡介，這裏介紹一下，ToInfluxDb（influxDB url,InfluxDB databaseName）,這裏是InfluxDB的地址和數據庫名稱，若是沒有改數據庫，會自動建立。

以上寫法是簡寫，固然咱們能夠詳細的控制InfluxDB的屬性，經過如下寫法：

            var metrics = new MetricsBuilder()
                .Report.ToInfluxDb(
                    options =>
                    {
                        options.InfluxDb.BaseUri = new Uri("http://47.99.92.76:8086");
                        options.InfluxDb.Database = "metricsdatabase";
                        options.InfluxDb.Consistenency = "consistency";
                        options.InfluxDb.UserName = "admin";
                        options.InfluxDb.Password = "password";
                        options.InfluxDb.RetentionPolicy = "rp";
                        options.InfluxDb.CreateDataBaseIfNotExists = true;
                        options.HttpPolicy.BackoffPeriod = TimeSpan.FromSeconds(30);
                        options.HttpPolicy.FailuresBeforeBackoff = 5;
                        options.HttpPolicy.Timeout = TimeSpan.FromSeconds(10);
                        options.MetricsOutputFormatter = new MetricsInfluxDbLineProtocolOutputFormatter();
                        options.Filter = filter;
                        options.FlushInterval = TimeSpan.FromSeconds(20);
                    })
                .Build();

 

Option	Description
MetricsOutputFormatter	向InfluxDB報告指標時使用的格式化程序。
Filter	該過濾器僅用於爲此報告者過濾指標。
FlushInterval	向InfluxDB報告指標之間的延遲。
InfluxDb.Database	報告指標的InfluxDB數據庫。
InfluxDb.BaseUri	InfluxDB服務器的URI。
InfluxDb.UserName	使用基自己份驗證與InfluxDB進行身份驗證時的用戶名。
InfluxDb.Password	使用基自己份驗證與InfluxDB進行身份驗證時使用的密碼。
InfluxDb.Consistenency	要使用的InfluxDB數據庫一致性級別。
InfluxDb.RetentionPolicy	InfluxDB數據庫保留策略以向其寫入指標。
InfluxDb.CreateDataBaseIfNotExists	若是指定的influxdb數據庫不存在，將嘗試建立該數據庫。
HttpPolicy.BackoffPeriod	TimeSpan當指標沒法向指標入口端點報告時，從後退。
HttpPolicy.FailuresBeforeBackoff	指標未能向指標入口端點報告時，在回退以前的失敗次數。
HttpPolicy.Timeout	嘗試向度量標準入口端點報告度量標準時的HTTP超時持續時間。

 

而後咱們要存儲一個Counter類型的數據，App.Metrics裏有主要有6種數據類型：Counter、Gauge、Histograms 、Meter 、Timer 、Apdex。咱們本篇主要使用Counter和Gauge這兩種數據類型，

CounterOptions種的Name是數據表名，MeasurementUnit是測量的內容的描述。

metrics.Measure.Counter.Increment(counter,"MqQueueNmae");  會往把「my_counter」表裏的value + 1，實際就是對value加加減減，大體以下：

 

 同時還會建立一張名爲my_counter__items的表，同時爲一個字段爲「MqQueueNmae」的value+1，以下：

 

 

多了幾個字段，經過這個咱們能夠用來對不一樣的消息度列Queue進行統計，而第一張表則當作一張當前消費消息的統計表。

            var task = Task.Run(async () =>
            {
                await Task.WhenAll(metrics.ReportRunner.RunAllAsync());
            });

            task.Wait();

這句代碼是指將當前的統計數據報告到InfluDB，這段代碼必定要在最後，它會將數據發送到全部已註冊的存儲端，好比你同時註冊了InfluxDB和Prometheus，那麼數據會同時發送到這兩個存儲端。

執行完成後建立的兩張表以下：

 

 

而後咱們就能夠去Granfan裏自定義統計圖了，比較簡單，你們能夠本身研究一下，大體以下：

 

 

下一篇將會把這一套集成到實際項目中，用來監控消息隊列系統，這一篇只是瞭解，等我明天寫能夠直接用於生產的！