一, 简介
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/
二, 实际业务场景
上面介绍了 App.Metrics 以及它支持的场景, 但是读完你一定会觉得很抽象, 没错我也一样. 如果不是带着实际的业务场景去看这些东西, 其实还是有点云里雾里的. 在实际的业务中我们通常会把它用于两个方面, 一方面是包括 CPU, 内存在内的对系统级别的整体监控, 园子里有很多文章都做了 demo 供大家参考, 大家可以搜一下. 另外一方面是通过埋点的方式统计相关数据, 后端通常使用 InfluxDB 作为数据库, 并使用 Grafana 或者 Prometheus 来对数据进行展示.
本篇将介绍的使用方式是第二钟, 通过埋点的方式来对消息队列进行统计, 统计的数据包括 队列数量, 每个队列当前消息数量 (已消费, 未消费), 以及消息的生成和发布速率.
最后的样子大体就是下面这个样子:
三, 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 在之后会经常用到.
四, 搭建 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:
四,.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 里自定义统计图了, 比较简单, 大家可以自己研究一下, 大致如下:
下一篇将会把这一套集成到实际项目中, 用来监控消息队列系统, 这一篇只是了解, 等我明天写可以直接用于生产的!
来源: https://www.cnblogs.com/weiBlog/p/11717324.html