服务网格可观测性之平台化监控报警
一.项目背景
近期，汽车之家正在加速云原生服务网格化改造，以进一步提高业务系统的可扩展性和稳定性。目前汽车之家看选业务、资讯业务、买用业务等多个业务线已经陆续接入服务网格，累计接入应用数量200+、网格流量每日15亿+。
服务网格（Istio）以其强大的功能和扩展能力，为应用提供了更好的服务治理和可观测能力。服务的可观测性对于业务方以及运维来说都至关重要。Istio网格提供了丰富的监控和追踪工具，使得我们可以实时地监控服务的状态、性能指标和日志数据。
我们在可观测性体系建设过程中使用了Opentelemetry、Jaeger、Prometheus、Grafana等插件以及为应用定制可观测性基础镜像，从而实现了业务侧接入服务网格便可自动接入可观测性体系，实现网格进出流量、源站进出流量、服务整体性能[QPS响应时间等]、源站性能[接口QPS、响应时间、TP99等]、链路追踪等，而不需要进行额外开发与配置。至此我们可以轻松地进行服务调用链追踪和指标监控，帮助快速定位问题并提高系统的稳定性和性能。以下是可观测性部分截图：
1.1全链路
全链路展示-图1
1.2指标大盘
网格全局流量大盘
网格全局流量大盘展示-图2
网格应用级流量大盘
网格应用级进流量大盘展示--图03
网格应用级出流量大盘展示--图04
源站应用级大盘
服务源站进流量大盘展示--图05
服务源站出流量大盘展示-图06
1.3异常报警
异常报警钉钉展示-图07
可观测体系中“指标大盘系统”与“异常报警系统”我们采用了Opentelemetry+Prometheus+Grafana 的技术选型。
本篇文章我们将主要描述“异常报警系统”的技术方案。在“异常报警系统”的建设过程中，我们面临了两类Prometheus Metrics数据的处理。首先是来自Istio架构本身的Metrics数据，其次是应用源站产生的Metrics数据，例如：进出流量等关键指标。作为业务方，我们希望能够快速构建一个独立的报警系统来监控这些数据，并及时发现和响应异常情况。尽管运维侧可能已经提供了Prometheus Alertmanager，但考虑到独立性和灵活性的需求，我们选择了使用“Grafana Alert 警报模块”来实现自主报警管理。
二. Grafana 警报模块介绍
grafana 8.0 以后添加了新的警报模块"unified_alerting",以下简称为“统一警报模块”。
“统一警报模块” 是一个基于 Grafana 的插件，它能够轻松地创建和管理报警规则，并将报警发送到多个渠道，例如电子邮件、Slack 、钉钉、webhook等。这个工具的主要特点包括：
- 可视化警报配置：“统一警报模块” 提供了一个可视化界面，让用户可以方便地创建和管理报警规则。您可以通过简单地设置触发条件、定义报警接收者以及报警通知方式，轻松实现警报功能。
- 多数据源支持：“统一警报模块” 警报规则可以配置多种数据源作为数据来源，比如：prometheus、mysql、es等。
- 多维度警报：警报规则可以为每个警报规则创建多个单独的警报实例（称为多维警报），使你能够强大而灵活地通过单个警报来了解整个系统。
- 多种报警通知方式：“统一警报模块” 支持多种报警通知方式，包括电子邮件、Slack、PagerDuty 等。根据实际需求选择适合您的报警通知方式。
- 报警历史记录：“统一警报模块” 记录每次触发的报警事件，并提供报警历史记录查询功能。通过查看历史记录，您可以更好地了解您的系统状态并进行优化。
- 自定义报警模板：“统一警报模块” 允许用户自定义报警模板，以适应不同场景下的报警需求。通过自定义警报模板，可以使报警信息更加精准和有效。
- 抑制警报：抑制警报允许您停止接收来自一个或多个警报规则的持久通知。您还可以根据特定条件部分暂停警报。比如：使用抑制警报时间段设置，您可以指定不希望生成或发送新通知的时间间隔。您还可以将警报通知冻结在重复时间段内，例如在维护期间。
2.1主要概念
下图向您概述了Grafana警报的工作原理，并向您介绍了一些关键概念，这些概念一起工作，形成了我们灵活而强大的警报引擎的核心。
概念架构-图08
- Alert rules [警报规则] 设置评估标准，该标准确定警报实例是否会背触发。警报规则包括一个或多个查询和表达式、条件、评估频率以及满足条件的持续时间(可选)。
- Labels[标签] 将警报规则及其实例与通知策略(Notification policies)和静默(Silences)匹配。它们还可以用于按严重程度对警报进行分组。
- Notification policies[通知策略] 通过配置“通知策略” 可以实现警报的通知时间以及匹配具体的警报规则。每个“通知策略”通过一组标签匹配器来匹配警报规则。警报的"联络点"也是在此进行关联。
- Contact points[联络点] 定义警报触发时如何通知联系人。支持多种通讯工具[dingding、email、webhook等]，以确保警报到达您的团队。
2.2 警报工作原理
下图向您概述了"统一警报模块"工作原理，并向您介绍了一些关键概念，这些概念一起工作，形成了我们灵活而强大的警报引擎的核心。
工作原理-图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 “统一警报模块”的使用。
三. Grafana 警报实战
3.1安装
参考：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:90943.2案例说明
下面是此案例的数据流图：
数据流图-图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.0
http_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.0
http_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.0
http_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.0
http_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.0
http_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.0
http_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.0
http_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案例配置说明
► 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/]定制自己的告警系统.
猜你喜欢
