Metrics.net＋influxdb＋grafana 构建WebAPI的自动化监控和预警

前言

这次主要分享通过Metrics.net + influxdb + grafana 构建WebAPI的自动化监控和预警方案。通过执行耗时，定位哪些接口拖累了服务的性能；通过请求频次，设置适当的限流和熔断机制，拦截非法或不合理的请求，保障服务的可用性。

InfluxDB

官网：https://www.influxdata.com/

按照官方的说法，InfluxDB是一个开源分布式时序、事件和指标数据库。使用 Go 语言编写，无需外部依赖。其设计目标是实现分布式和水平伸缩扩展。

下载地址：https://portal.influxdata.com/downloads，解压后的目录如下

打开配置文件，设置数据存储路径

[data] # The directorywherethe TSM storage engine stores TSM files. #dir ="/var/lib/influxdb/data"dir ="C:/Users/001wa/Desktop/software/influxdb-1.2.2-1/data"# The directorywherethe TSM storage engine stores WAL files. #wal-dir ="/var/lib/influxdb/wal"wal-dir ="C:/Users/001wa/Desktop/software/influxdb-1.2.2-1/data"

开启管理界面

[admin] # Determines whether the admin serviceisenabled. enabled =true# Thedefaultbind address used by the admin service. bind-address =":8083"

cmd到当前目录，使用配置文件influxdb.conf启动服务后，可以查看管理页面http://127.0.0.1:8083/

至此，服务启动成功。

创建数据库并改变默认策略，并创建具有管理员权限的账户

CREATE DATABASE"db_metrics"CREATE RETENTION POLICY"rp_metrics"ON"db_metrics"DURATION 10w REPLICATION1DEFAULT

CREATE USER "admin" WITH PASSWORD 'admin' WITH ALL PRIVILEGES

Metrics.Net

现有多个Metrics及其扩展的版本：

https://github.com/etishor/Metrics.NET 该版本的作者据说去天堂了，期望天堂里没有程序员这个职业。

https://github.com/davidB/metrics-influxdb 这个扩展支持的Influxdb版本太低，高版本会报异常，无奈放弃。

https://github.com/Recognos/Metrics.NET这个版本每个时间周期都会向数据源推数据，如果这段时间内没有数据则默认用上个周期的数据，并且数据会累计，导致重复，不便于统计和展示。

https://github.com/Recognos/Metrics.NET.InfluxDB这个版本的扩展不错。

最终选择后面两个，并对源码做了一点扩展和二次开发，基础SDK主要封装Metrics的基础操作和修复上述重复、累计问题，并注册全局的环境、主机的自定义Tags。

Metric.Config.WithReporting(report => report .WithInfluxDbMyHttp(host, port, database, userName, password,null,null,

TimeSpan.FromSeconds(intervalSeconds),null, configFunc => configFunc .WithConverter(newDefaultConverter().

WithGlobalTags($"env=,host=")) .WithFormatter(newDefaultFormatter().

WithLowercase(true)) .WithWriter(newInfluxdbHttpWriter(configFunc, batchSize))));

之后在基础sdk上扩展一个用于统计webapi接口耗时和频次的sdk。

//////WebAPI接口过滤器//////记录接口耗时、频次，记录到Metrics///publicclassMetricsFilterAttribute : ActionFilterAttribute

主要采用Histogram，并自定义Tags便于Grafana的筛选

if(stopWatch !=null) { stopWatch.Stop();

vartags =newstring[] { $"method={

actionExecutedContext.Request.Method.ToString()}"};

varmetricsName = FormatMetricsName(

actionExecutedContext.ActionContext.ActionDescriptor);

//build and update histogramvarhistogram = GetOrAddHistogram(metricsName, tags); histogram.Update(stopWatch.ElapsedMilliseconds); }

WebAPI引用后，要注册全局的过滤器

config.Filters.Add(newMetricsFilterAttribute());Grafana

Grafana是一个非常好看的监控界面，从这里下载：https://grafana.com/grafana/download

启动服务，打开登陆页面http://localhost:3000，使用默认账号登陆。

这里主要关注数据源的配置和图表的画法，不再详述用户分组权限的管理和自动化预警，想了解更多可以参考官方文档：http://docs.grafana.org/guides/getting_started/

首先添加数据源，设置数据源的类型、地址、数据库、通信方式等。

之后，自定义模板，将自定义的Tags作为筛选项，并设置数据源、筛选条件。

最终的效果为：

接下来，自定义图表

设置标题

选择自己的数据库和查询字段，比如采用Histrogram直方图记录单位时间内的执行次数和耗时分布

因为耗时和访问次数属于不同的维度，这里要设置两个Y坐标

显示一些聚合数据

设置我们要展示图形格式

最终效果为

熔断

为了保证单个接口或服务的可用性，通常针对单个用户账户、单个调用方ip在某个时间段内的访问频次进行限制，拦截恶意的请求，保障服务的可用性。

可以在Grafana中设置预警阈值，直接调用接口，对用户或ip进行访问拦截等。

后语

这篇是线上服务的可用性保障方案的其中一篇，其它的内容会后续补充：

1.对Web、H5、App相关页面进行埋点，统计用户访问的PV、UV、停留时间、转化率等。

2.VSAnalyseTool本地调试分析接口的耗时、内存、CPU的使用情况，直接定位问题、优化代码。

接口性能分析与优化

3.SoapUI对接口进行并行压力测试，针对性改善接口性能。

4.Metrics.net + influxdb + grafana对API进行埋点。

5.完善日志系统，记录请求和响应及耗时，标识一次完整的请求，便于查找和定位问题。

6.对EntityFramework进行轻度包装，支持AsNoTracking、自动nolock、记录SQL执行耗时、读写分离等。

7.zabbix监控服务器的内存、线程、CPU Average、CPU Load、IO等，设置阈值、及时预警，保障线上的可用性。

8. WinDbg分析线上服务异常时的内存转储文件，排查大对象、高频回收、线程耗时、死锁等问题。

高CPU、数据库无法读写的真凶

Windbg DUMP分析（原创汇总）

记一次内存泄漏DUMP分析