杂谈

服务网格可观测性之平台化监控报警

一.项目背景

近期,汽车之家正在加速云原生服务网格化改造,以进一步提高业务系统的可扩展性和稳定性。目前汽车之家看选业务、资讯业务、买用业务等多个业务线已经陆续接入服务网格,累计接入应用数量200+、网格流量每日15亿+。 

服务网格(Istio)以其强大的功能和扩展能力,为应用提供了更好的服务治理和可观测能力。服务的可观测性对于业务方以及运维来说都至关重要。Istio网格提供了丰富的监控和追踪工具,使得我们可以实时地监控服务的状态、性能指标和日志数据。

我们在可观测性体系建设过程中使用了Opentelemetry、Jaeger、Prometheus、Grafana等插件以及为应用定制可观测性基础镜像,从而实现了业务侧接入服务网格便可自动接入可观测性体系,实现网格进出流量、源站进出流量、服务整体性能[QPS响应时间等]、源站性能[接口QPS、响应时间、TP99等]、链路追踪等,而不需要进行额外开发与配置。至此我们可以轻松地进行服务调用链追踪和指标监控,帮助快速定位问题并提高系统的稳定性和性能。以下是可观测性部分截图:

1.1全链路

全链路展示-图1全链路展示-图1

1.2指标大盘

网格全局流量大盘

网格全局流量大盘展示-图2网格全局流量大盘展示-图2


网格应用级流量大盘

网格应用级进流量大盘展示--图03网格应用级进流量大盘展示--图03


网格应用级出流量大盘展示--图04网格应用级出流量大盘展示--图04


源站应用级大盘

服务源站进流量大盘展示--图05服务源站进流量大盘展示--图05


服务源站出流量大盘展示-图06服务源站出流量大盘展示-图06


1.3异常报警

异常报警钉钉展示-图07异常报警钉钉展示-图07

可观测体系中“指标大盘系统”与“异常报警系统”我们采用了Opentelemetry+Prometheus+Grafana 的技术选型。 

本篇文章我们将主要描述“异常报警系统”的技术方案。在“异常报警系统”的建设过程中,我们面临了两类Prometheus Metrics数据的处理。首先是来自Istio架构本身的Metrics数据,其次是应用源站产生的Metrics数据,例如:进出流量等关键指标。作为业务方,我们希望能够快速构建一个独立的报警系统来监控这些数据,并及时发现和响应异常情况。尽管运维侧可能已经提供了Prometheus Alertmanager,但考虑到独立性和灵活性的需求,我们选择了使用“Grafana Alert 警报模块”来实现自主报警管理。

二. Grafana 警报模块介绍

grafana 8.0 以后添加了新的警报模块"unified_alerting",以下简称为“统一警报模块”。

“统一警报模块” 是一个基于 Grafana 的插件,它能够轻松地创建和管理报警规则,并将报警发送到多个渠道,例如电子邮件、Slack 、钉钉、webhook等。这个工具的主要特点包括:

  1. 可视化警报配置:“统一警报模块” 提供了一个可视化界面,让用户可以方便地创建和管理报警规则。您可以通过简单地设置触发条件、定义报警接收者以及报警通知方式,轻松实现警报功能。
  2. 多数据源支持:“统一警报模块” 警报规则可以配置多种数据源作为数据来源,比如:prometheus、mysql、es等。
  3. 多维度警报:警报规则可以为每个警报规则创建多个单独的警报实例(称为多维警报),使你能够强大而灵活地通过单个警报来了解整个系统。
  4. 多种报警通知方式:“统一警报模块” 支持多种报警通知方式,包括电子邮件、Slack、PagerDuty 等。根据实际需求选择适合您的报警通知方式。
  5. 报警历史记录:“统一警报模块” 记录每次触发的报警事件,并提供报警历史记录查询功能。通过查看历史记录,您可以更好地了解您的系统状态并进行优化。
  6. 自定义报警模板:“统一警报模块” 允许用户自定义报警模板,以适应不同场景下的报警需求。通过自定义警报模板,可以使报警信息更加精准和有效。
  7. 抑制警报:抑制警报允许您停止接收来自一个或多个警报规则的持久通知。您还可以根据特定条件部分暂停警报。比如:使用抑制警报时间段设置,您可以指定不希望生成或发送新通知的时间间隔。您还可以将警报通知冻结在重复时间段内,例如在维护期间。

2.1主要概念

下图向您概述了Grafana警报的工作原理,并向您介绍了一些关键概念,这些概念一起工作,形成了我们灵活而强大的警报引擎的核心。

概念架构-图08概念架构-图08


  1. Alert rules [警报规则]  设置评估标准,该标准确定警报实例是否会背触发。警报规则包括一个或多个查询和表达式、条件、评估频率以及满足条件的持续时间(可选)。
  2. Labels[标签]    将警报规则及其实例与通知策略(Notification policies)和静默(Silences)匹配。它们还可以用于按严重程度对警报进行分组。
  3. Notification policies[通知策略]    通过配置“通知策略” 可以实现警报的通知时间以及匹配具体的警报规则。每个“通知策略”通过一组标签匹配器来匹配警报规则。警报的"联络点"也是在此进行关联。
  4. Contact points[联络点]    定义警报触发时如何通知联系人。支持多种通讯工具[dingding、email、webhook等],以确保警报到达您的团队。

2.2 警报工作原理

下图向您概述了"统一警报模块"工作原理,并向您介绍了一些关键概念,这些概念一起工作,形成了我们灵活而强大的警报引擎的核心。

工作原理-图09工作原理-图09

你可以直接在Grafana UI中创建警报资源(警报规则,通知策略等),如下图所示:

告警规则示例-图10告警规则示例-图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多维报警示例-图11

grafana管理的警报实例都可以处于Normal、Pending、Alerting、No Data、Error状态。

► 2.2.3 Notification policy[通知策略]

每个通知策略都包含一组标签匹配器[labels matcher],以指示它负责哪些警报规则或实例;

通知策略-图12通知策略-图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:9094

3.2案例说明

下面是此案例的数据流图:

数据流图-图13数据流图-图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数据源-图14

► 3.3.2 配置警报规则

配置报警规则-图15配置报警规则-图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添加标签-图16

配置标签 name=vehicle_service-rt99 ,此标签为通知策略匹配关联。

► 3.3.3 配置联络点

配置联络点-图17配置联络点-图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配置消息模板-图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配置通知策略-图19

通过Labels Matcher 匹配 name=vehicle_service-rt99 的警报规则,并通过 contact point = vehicle_service-rt99-webhook-point01 的联络点进行报警。

► 3.3.6 配置静默规则

配置静默规则-图20配置静默规则-图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/]定制自己的告警系统.

本页面仅提供《服务网格可观测性之平台化监控报警》的在线阅读查看,您观看的《服务网格可观测性之平台化监控报警》内容为网络转载,如果您觉得《服务网格可观测性之平台化监控报警》侵犯了您的权益以及对您造成影响,请联系我们进行删除。