前言
这次主要分享通过 Metrics.net + influxdb + grafana 构建 webAPI 的自动化监控和预警方案通过执行耗时, 定位哪些接口拖累了服务的性能; 通过请求频次, 设置适当的限流和熔断机制, 拦截非法或不合理的请求, 保障服务的可用性
InfluxDB
官网: https://www.influxdata.com/
按照官方的说法, InfluxDB 是一个开源分布式时序事件和指标数据库使用 Go 语言编写, 无需外部依赖其设计目标是实现分布式和水平伸缩扩展
下载地址: https://portal.influxdata.com/downloads, 解压后的目录如下
打开配置文件, 设置数据存储路径
- [data]
- # The directory where the TSM storage engine stores TSM files.
- #dir = "/var/lib/influxdb/data"
- dir = "C:/Users/001wa/Desktop/software/influxdb-1.2.2-1/data"
- # The directory where the 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 service is enabled.
- enabled = true
- # The default bind 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 REPLICATION 1 DEFAULT
- 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(new DefaultConverter().WithGlobalTags($"env={environment},host={Dns.GetHostName()}"))
- .WithFormatter(new DefaultFormatter().WithLowercase(true))
- .WithWriter(new InfluxdbHttpWriter(configFunc, batchSize))));
之后在基础 sdk 上扩展一个用于统计 webapi 接口耗时和频次的 sdk
- /// <summary>
- /// WebAPI 接口过滤器
- ///
- /// 记录接口耗时频次, 记录到 Metrics
- /// </summary>
- public class MetricsFilterAttribute : ActionFilterAttribute
主要采用 Histogram, 并自定义 Tags 便于 Grafana 的筛选
- if (stopWatch != null)
- {
- stopWatch.Stop();
- var tags = new string[] { $"method={actionExecutedContext.Request.Method.ToString()}" };
- var metricsName = FormatMetricsName(actionExecutedContext.ActionContext.ActionDescriptor);
- //build and update histogram
- var histogram = GetOrAddHistogram(metricsName, tags);
- histogram.Update(stopWatch.ElapsedMilliseconds);
- }
WebAPI 引用后, 要注册全局的过滤器
- config.Filters.Add(new MetricsFilterAttribute());
- Grafana
Grafana 是一个非常好看的监控界面, 从这里下载: https://grafana.com/grafana/download
启动服务, 打开登陆页面 http://localhost:3000, 使用默认账号登陆
这里主要关注数据源的配置和图表的画法, 不再详述用户分组权限的管理和自动化预警, 想了解更多可以参考官方文档: http://docs.grafana.org/guides/getting_started/
首先添加数据源, 设置数据源的类型地址数据库通信方式等
之后, 自定义模板, 将自定义的 Tags 作为筛选项, 并设置数据源筛选条件
最终的效果为:
接下来, 自定义图表
设置标题
选择自己的数据库和查询字段, 比如采用 Histrogram 直方图记录单位时间内的执行次数和耗时分布
因为耗时和访问次数属于不同的维度, 这里要设置两个 Y 坐标
显示一些聚合数据
设置我们要展示图形格式
最终效果为
熔断
为了保证单个接口或服务的可用性, 通常针对单个用户账户单个调用方 ip 在某个时间段内的访问频次进行限制, 拦截恶意的请求, 保障服务的可用性
可以在 Grafana 中设置预警阈值, 直接调用接口, 对用户或 ip 进行访问拦截等
后语
这篇是线上服务的可用性保障方案的其中一篇, 其它的内容会后续补充:
1. 对 WebH5App 相关页面进行埋点, 统计用户访问的 PVUV 停留时间转化率等
2.VSAnalyseTool 本地调试分析接口的耗时内存 CPU 的使用情况, 直接定位问题优化代码
接口性能分析与优化
3.SoapUI 对接口进行并行压力测试, 针对性改善接口性能
4.Metrics.net + influxdb + grafana 对 API 进行埋点
5. 完善日志系统, 记录请求和响应及耗时, 标识一次完整的请求, 便于查找和定位问题
6. 对 EntityFramework 进行轻度包装, 支持 AsNoTracking 自动 nolock 记录 SQL 执行耗时读写分离等
7.zabbix 监控服务器的内存线程 CPU AverageCPU LoadIO 等, 设置阈值及时预警, 保障线上的可用性
8. WinDbg 分析线上服务异常时的内存转储文件, 排查大对象高频回收线程耗时死锁等问题
高 CPU 数据库无法读写的真凶
Windbg DUMP 分析 (原创汇总)
记一次内存泄漏 DUMP 分析
来源: https://www.cnblogs.com/LoveOfPrince/p/8538621.html