Metrics.net + influxdb + grafana 构建WebAPI的自动化监控和预警
前言
這次主要分享通過Metrics.net + influxdb + grafana 構建WebAPI的自動化監控和預警方案。通過執行耗時,定位哪些接口拖累了服務的性能;通過請求頻次,設置適當的限流和熔斷機制,攔截非法或不合理的請求,保障服務的可用性。
InfluxDB
官網:https://www.influxdata.com/
按照官方的說法,InfluxDB是一個開源分布式時序、事件和指標數據庫。使用 Go 語言編寫,無需外部依賴。其設計目標是實現分布式和水平伸縮擴展。
?
下載地址:https://portal.influxdata.com/downloads,解壓后的目錄如下
?
?打開配置文件,設置數據存儲路徑
開啟管理界面
[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 DEFAULTCREATE 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 histogramvar 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.對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分析
相關文章:
ASP.NET Core之跨平臺的實時性能監控
.Net Core 2.0+ InfluxDB+Grafana+App Metrics 實現跨平臺的實時性能監控
應用程序的8個關鍵性能指標以及測量方法
使用Metrics監控應用程序的性能
下一個計劃 : .NET/.NET Core應用性能管理
Ocelot監控
Ocelot 集成Butterfly 實現分布式跟蹤
Ocelot中使用Butterfly實踐
原文:https://www.cnblogs.com/LoveOfPrince/p/8538621.html
.NET社區新聞,深度好文,歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的Metrics.net + influxdb + grafana 构建WebAPI的自动化监控和预警的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 拥抱.NET Core系列:Memory
- 下一篇: EF Core 2.1路线图:视图、GR