中興AX5400Pro+上手體驗：再升級 雙2.5G網口+USB 3.0這次全都有
2021年11月的時候，中興先后發布了兩款路由器產品，中興AX5400和中興AX5400 Pro，從產品命名上就不難看出這是隸屬于同一系列的，但在外觀設計上這兩款產品可以說是完全沒一點關系
近期，汽車之家正在加速云原生服務網格化改造，以進一步提高業務系統的可擴展性和穩定性。目前汽車之家看選業務、資訊業務、買用業務等多個業務線已經陸續接入服務網格，累計接入應用數量200+、網格流量每日15億+。
服務網格（Istio）以其強大的功能和擴展能力，為應用提供了更好的服務治理和可觀測能力。服務的可觀測性對于業務方以及運維來說都至關重要。Istio網格提供了豐富的監控和追蹤工具，使得我們可以實時地監控服務的狀態、性能指標和日志數據。
我們在可觀測性體系建設過程中使用了Opentelemetry、Jaeger、Prometheus、Grafana等插件以及為應用定制可觀測性基礎鏡像，從而實現了業務側接入服務網格便可自動接入可觀測性體系，實現網格進出流量、源站進出流量、服務整體性能[QPS/響應時間等]、源站性能[接口QPS、響應時間、TP99等]、鏈路追蹤等，而不需要進行額外開發與配置。至此我們可以輕松地進行服務調用鏈追蹤和指標監控，幫助快速定位問題并提高系統的穩定性和性能。以下是可觀測性部分截圖：
全鏈路展示-圖1
網格全局流量大盤
網格全局流量大盤展示-圖2
網格應用級流量大盤
網格應用級進流量大盤展示--圖03
網格應用級出流量大盤展示--圖04
源站應用級大盤
服務源站進流量大盤展示--圖05
服務源站出流量大盤展示-圖06
異常報警釘釘展示-圖07
可觀測體系中“指標大盤系統”與“異常報警系統”我們采用了Opentelemetry+Prometheus+Grafana 的技術選型。
本篇文章我們將主要描述“異常報警系統”的技術方案。在“異常報警系統”的建設過程中，我們面臨了兩類Prometheus Metrics數據的處理。首先是來自Istio架構本身的Metrics數據，其次是應用源站產生的Metrics數據，例如：進出流量等關鍵指標。作為業務方，我們希望能夠快速構建一個獨立的報警系統來監控這些數據，并及時發現和響應異常情況。盡管運維側可能已經提供了Prometheus Alertmanager，但考慮到獨立性和靈活性的需求，我們選擇了使用“Grafana Alert 警報模塊”來實現自主報警管理。
grafana 8.0 以后添加了新的警報模塊"unified_alerting",以下簡稱為“統一警報模塊”。
“統一警報模塊” 是一個基于 Grafana 的插件，它能夠輕松地創建和管理報警規則，并將報警發送到多個渠道，例如電子郵件、Slack 、釘釘、webhook等。這個工具的主要特點包括：
下圖向您概述了Grafana警報的工作原理，并向您介紹了一些關鍵概念，這些概念一起工作，形成了我們靈活而強大的警報引擎的核心。
概念架構-圖08
下圖向您概述了"統一警報模塊"工作原理，并向您介紹了一些關鍵概念，這些概念一起工作，形成了我們靈活而強大的警報引擎的核心。
工作原理-圖09
你可以直接在Grafana UI中創建警報資源(警報規則，通知策略等)，如下圖所示：
告警規則示例-圖10
? 2.2.1 Alert rules [警報規則]
可以為你的警報規則添加摘要/注釋[Summary and annotations]，為報警提供額外的信息。還可以添加標簽，通過此標簽可以配置路由規則。標簽將警報規則與通知策略相關聯，因此您可以輕松管理哪個策略應處理哪些警報以及誰應該收到通知。
一個警報規則可以產生多個警報實例,詳見【**Alert instances[警報實例]**】。
創建警報規則后，它們會經歷各種狀態轉換。狀態一般為：Normal, Pending, Firing 。例如，如果一個警報實例正在觸發[firing]，則警報規則的狀態也將是觸發[firing]。
? 2.2.2 Alert instances[警報實例]
對于grafana管理的警報規則，可以根據一個警報規則創建多個警報實例(也稱為多維警報)。它可以幫你在單個表達式中觀察多個實例。比如：
比如：
sum by(cpu) ( rate(node_cpu_seconds_total{mode!="idle"}[1m]) )使用此表達式的“警報規則”將創建與第一次求值后觀察到的CPU數量相同數量的“警報實例”，從而為每個CPU都生成一條報警實例。
多維報警示例-圖11
grafana管理的警報實例都可以處于Normal、Pending、Alerting、No Data、Error狀態。
? 2.2.3 Notification policy[通知策略]
每個通知策略都包含一組標簽匹配器[labels matcher]，以指示它負責哪些警報規則或實例；
通知策略-圖12
可以添加聯絡點[Contact point]來配置警報規則觸發后通知的渠道[dingding、email、webhook等]；還可以配置靜默時間[Mute timings]用來配置報警觸發后通知的時間，比如：凌晨1點到5點不發送報警信息。
? 2.2.4 Message templates[消息模板]
為通知消息創建可重用的自定義模板，并在聯絡點[Contact point]中使用它們。模板語法以Go templating system [https://pkg.go.dev/text/template]為基礎。
? 2.2.5 Silences and mute timings[靜默與靜音時間]
Sliences: 添加靜默配置可在一段時間內停止某個告警規則的通知。是一種快速而有效的方法，可以將不必要的告警暫停，從而避免不必要的干擾和誤報。例如，在系統維護期間，可以將某些告警規則設置為靜音以減少通知，也可以在進行緊急修復時暫停某些告警。
Mute timings：指定了通知被禁止的時間段，這些時間段可以是重復的，例如，每周五晚上。這種方式適用于計劃的活動或預定的維護窗口，其中需要在一段時間內暫停特定的告警通知。
下面章節將通過一個具體案例展示grafana “統一警報模塊”的使用。
參考：https://grafana.com/docs/grafana/latest/setup-grafana/installation/
開啟"統一警報模塊"
#################################### Unified Alerting ####################[unified_alerting]#開啟統一報警模塊enabled = true配置"統一警報模塊"高可用
#################################### Unified Alerting ####################[unified_alerting]#開啟統一報警模塊enabled = true#監聽地址/主機名和端口，用于接收其他Grafana實例的統一警報消息。ha_listen_address = "${POD_IP}:9094"#監聽地址/主機名和端口，用于接收其他Grafana實例的統一警報消息。ha_advertise_address = "${POD_IP}:9094"#以“主機：端口”的格式列出初始實例（逗號分隔），這些實例將組成HA集群。配置此設置將啟用警報的高可用模式。#注: 此pod申請固定IP，也可以將grafna部署為statefulset模式。ha_peers = 10.23.2.32:9094,10.23.2.33:9094,10.23.2.34:9094下面是此案例的數據流圖：
數據流圖-圖13
此案例中聯絡點為webhook實現方式，采用webhook方式定制自己的webhook服務可以更靈活的配置報警消息的發送策略，比如：配置多渠道的發送機制[釘釘+短信+郵件]、可通過服務名稱匹配到具體的應用相關人。
報警規則
計算服務名稱為"vehicle_service"的服務所提供的所有接口響應時間，對5分鐘內99百分位大于70ms的接口進行分組報警。Metrics數據格式
http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="0.0", service="vehicle_service"} 0.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="5.0", service="vehicle_service"} 102356.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="10.0", service="vehicle_service"} 136099.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="25.0", service="vehicle_service"} 163764.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="50.0", service="vehicle_service"} 175603.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="75.0", service="vehicle_service"} 179163.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="100.0", service="vehicle_service"} 180891.0http_server_duration_bucket{http_method="GET", http_route="/v1/app/getVehicleList", http_status_code="200", instance="10.29.2.9:9464", le="250.0", service="vehicle_service"} 182806.0數據說明：此Metrics數據描述了HTTP 服務的響應時間分布數據，通過這些 metrics 數據可以得到該 HTTP 接口在不同響應時間區間的請求數量，以及每個區間的響應時間度量值。例如，在此數據中，le=5.0 的 bucket 中有 102356 次請求，對應的響應時間在 0 到 5 秒之間，le=250.0 的 bucket 中有 182806 次請求，對應的響應時間在 0 到 250 秒之間。
下面將演示通過Grafana “統一警報模塊”實現上面的報警規則：
? 3.3.1 配置prometheus數據源
數據源-圖14
? 3.3.2 配置警報規則
配置報警規則-圖15
配置表達式：
round(histogram_quantile(0.99, sum(irate(http_server_duration_bucket{service=~"vehicle_service",http_route!="/**",http_status_code="200"}[5m])) by (service,http_route,http_method,http_status_code, le)) > 60,0.01)
添加標簽-圖16
配置標簽 name=vehicle_service-rt99 ，此標簽為通知策略匹配關聯。
? 3.3.3 配置聯絡點
配置聯絡點-圖17
webhook URL：
http://alert-webhook.zhijiajishu.com/mc/multiMessage?serviceName=vehicle_service&channels=dingding此webhook接口實現的功能為：接收到alert請求以后，通過serviceName匹配到相應的應用相關人，并通過釘釘的方式進行報警消息發送。
更多webhook參數可以參照：https://grafana.com/docs/grafana-cloud/alerting-and-irm/alerting/alerting-rules/manage-contact-points/webhook-notifier/
? 3.3.4 配置消息模板
配置消息模板-圖18
模板內容：
{{ define "vehicle_service_rt99_tpl" }}{{ if .Alerts.Firing -}}{{ range .Alerts.Firing }}{{ .Labels.service }} ## 報警詳情：應用名[{{ .Labels.service }}] 接口 [{{ .Labels.http_route }}],5分鐘內接口平均響應時間為[{{.Values.B}}] 超過閾值[70ms].{{ end }}{{- end }}{{ if .Alerts.Resolved -}}{{- range .Alerts.Resolved }}{{ .Labels.service }} ## 報警詳情[恢復]：應用名[{{ .Labels.service }}] 接口 [{{ .Labels.http_route }}],5分鐘內接口平均響應時間為[{{.Values.B}}] 超過閾值[70ms].{{- end }}{{- end }}{{- end }}? 3.3.5 配置通知策略
配置通知策略-圖19
通過Labels Matcher 匹配 name=vehicle_service-rt99 的警報規則，并通過 contact point = vehicle_service-rt99-webhook-point01 的聯絡點進行報警。
? 3.3.6 配置靜默規則
配置靜默規則-圖20
? 3.3.7 警報消息
[AutoMesh報警] CarAPI 99%請求的的平均處理時間超閾值報警報警詳情：應用名[vehicle_service] 接口 [/v1/app/getVehicleList],5分鐘內接口平均響應時間為[79.79] 超過閾值[70ms].報警詳情：應用名[vehicle_service] 接口 [/v1/app/getVehicleDetails],5分鐘內接口平均響應時間為[84.84] 超過閾值[70ms].報警詳情：應用名[vehicle_service] 接口 [/v1/app/updateVehicleInfo],5分鐘內接口平均響應時間為[82.62] 超過閾值[70ms].報警詳情：應用名[vehicle_service] 接口 [/v1/app/countVehicles],5分鐘內接口平均響應時間為[91.49] 超過閾值[70ms].通過本篇文章，大家應該可以了解了Grafana 警報模塊的工作原理以及具體使用方式。如果想更深入的了解grafana 的警報模塊的更多功能還應該閱讀官方文檔。另：如果不用使用Grafana UI配置相關警報規則，大家還可以通過Grafana 提供的API[https://grafana.com/docs/grafana/latest/developers/http_api/]定制自己的告警系統.
本文鏈接：http://www.tebozhan.com/showinfo-26-10646-0.html服務網格可觀測性之平臺化監控報警
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號