基于SkyWalking的分布式跟踪系统 - 异常告警

简介: 通过前面2篇文章我们搭建了SW的基础环境,监控了微服务,能了解所有服务的运行情况。但是当出现服务响应慢,接口耗时严重时我们需要立即定位到问题,这就需要我们今天的主角--监控告警,同时此篇也是SW系列的最后一篇。

UI参数


首先我们认识一下SW DashBoard上的几个关键参数,如下图所示


1.jpg


告警配置


告警流程


skywalking发送告警的基本原理是每隔一段时间轮询skywalking-collector收集到的链路追踪的数据,再根据所配置的告警规则(如服务响应时间、服务响应时间百分比)等,如果达到阈值则发送响应的告警信息。发送告警信息是以线程池异步的方式调用webhook接口完成,(具体的webhook接口可以使用者自行定义),从而开发者可以在指定的webhook接口中自行编写各种告警方式,钉钉告警、邮件告警等等。


规则配置


告警的核心由一组规则驱动,这些规则定义在 config/alarm-settings.yml,打开之后如下所示:


2.png


告警规则的定义分为两部分。


  • 告警规则。它们定义了应该如何触发度量警报,应该考虑什么条件。


  • [网络钩子](#Webhook}。当警告触发时,哪些服务终端需要被告知。


告警规则主要有以下几点


Rule name。 在告警信息中显示的唯一名称。必须以_rule结尾。


Metrics name。  也是oal脚本中的度量名。


Include names。 其下的实体名称都在此规则中。比如服务名,终端名。


Threshold。 阈值。


OP。  操作符, 支持 >, <, =。


Period.。  多久检查一次当前的指标数据是否符合告警规则这是一个时间窗口,与后端部署环境时间相匹配。


Count。  在一个Period窗口中,如果values超过Threshold值(按op),达到Count值,需要发送警报。


Silence period。 在时间N中触发报警后,在TN -> TN + period这个阶段不告警。默认情况下,它和Period一样,这意味着相同的告警(在同一个Metrics name拥有相同的Id)在同一个Period内只会触发一次


Webhook


SkyWalking 的告警 Webhook 要求对等方是一个 Web 容器. 告警的消息会通过 HTTP 请求进行发送, 请求方法为 POST, Content-Type 为 application/json, JSON 格式基于 List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage, 包含以下信息.


scopeId. 所有可用的 Scope 请查阅 org.apache.skywalking.oap.server.core.source.DefaultScopeDefine.


name. 目标 Scope 的实体名称.


id0. Scope 实体的 ID.


id1. 未使用.alarmMessage. 报警消息内容.


startTime. 告警时间, 位于当前时间与 UTC 1920/1/1 之间.


[{
"scopeId": 1,
"name": "serviceA",
"id0": 12,
"id1": 0,
"alarmMessage": "alarmMessage xxxx",
"startTime": 1560524171000}, {
"scopeId": 1,
"name": "serviceB",
"id0": 23,
"id1": 0,
"alarmMessage": "alarmMessage yyy",
"startTime": 1560524171000}]


代码实战


编写实体类用于接收sw告警消息


@DatapublicclassSwAlarmVO {
privateintscopeId;
privateStringname;
privateintid0;
privateintid1;
privateStringalarmMessage;
privatelongstartTime;
}


编写webhook接口


@RestController@RequestMapping("sw")
@Log4j2publicclassAlarmController {
@PostMapping("/alarm")
publicvoidalarm(@RequestBodyList<SwAlarmVO>alarmList){
log.info("skywalking alarm message:{}",alarmList);
//todo doalarm    }
}


  • 修改告警配置,开放webhook接口


  • 为了模拟请求调用慢,我们在代码中使用Thread.sleep(1000)增加接口耗时,然后等待webhoook接口告警响


3.png


告警详细信息如下:


[SwAlarmVO(scopeId = 2, name = dubbo - consumer - pid: 13812 @ jianzhang11, id0 = 28, id1 = 0, alarmMessage = Response time of service instance dubbo - consumer - pid: 13812 @ jianzhang11 is more than 1000ms in 2 minutes of last 10 minutes, startTime = 1573122018755), SwAlarmVO(scopeId = 2, name = dubbo - provider2 - pid: 14108 @ jianzhang11, id0 = 25, id1 = 0, alarmMessage = Response time of service instance dubbo - provider2 - pid: 14108 @ jianzhang11 is more than 1000ms in 2 minutes of last 10 minutes, startTime = 1573122018755)]


说明webhook能正常接收到sw的告警信息,后续的消息通知直接定制开发即可。

目录
相关文章
|
11月前
|
Kubernetes 大数据 调度
Airflow vs Argo Workflows:分布式任务调度系统的“华山论剑”
本文对比了Apache Airflow与Argo Workflows两大分布式任务调度系统。两者均支持复杂的DAG任务编排、社区支持及任务调度功能,且具备优秀的用户界面。Airflow以Python为核心语言,适合数据科学家使用,拥有丰富的Operator库和云服务集成能力;而Argo Workflows基于Kubernetes设计,支持YAML和Python双语定义工作流,具备轻量化、高性能并发调度的优势,并通过Kubernetes的RBAC机制实现多用户隔离。在大数据和AI场景中,Airflow擅长结合云厂商服务,Argo则更适配Kubernetes生态下的深度集成。
1261 34
|
7月前
|
存储 算法 安全
“卧槽,系统又崩了!”——别慌,这也许是你看过最通俗易懂的分布式入门
本文深入解析分布式系统核心机制:数据分片与冗余副本实现扩展与高可用,租约、多数派及Gossip协议保障一致性与容错。探讨节点故障、网络延迟等挑战,揭示CFT/BFT容错原理,剖析规模与性能关系,为构建可靠分布式系统提供理论支撑。
347 2
|
7月前
|
机器学习/深度学习 算法 安全
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
246 3
|
9月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
401 1
分布式新闻数据采集系统的同步效率优化实战
|
人工智能 前端开发 物联网
【05】20250416优雅草星云物联网AI智控系统从0开发鸿蒙端适配-deveco studio-增加告警中心相关卡片页面WarningCardWidget相关-增加Canvas 绘制折线图-Canvas 绘制柱状图-首页-优雅草卓伊凡
【05】20250416优雅草星云物联网AI智控系统从0开发鸿蒙端适配-deveco studio-增加告警中心相关卡片页面WarningCardWidget相关-增加Canvas 绘制折线图-Canvas 绘制柱状图-首页-优雅草卓伊凡
305 0
【05】20250416优雅草星云物联网AI智控系统从0开发鸿蒙端适配-deveco studio-增加告警中心相关卡片页面WarningCardWidget相关-增加Canvas 绘制折线图-Canvas 绘制柱状图-首页-优雅草卓伊凡
|
存储 运维 安全
盘古分布式存储系统的稳定性实践
本文介绍了阿里云飞天盘古分布式存储系统的稳定性实践。盘古作为阿里云的核心组件,支撑了阿里巴巴集团的众多业务,确保数据高可靠性、系统高可用性和安全生产运维是其关键目标。文章详细探讨了数据不丢不错、系统高可用性的实现方法,以及通过故障演练、自动化发布和健康检查等手段保障生产安全。总结指出,稳定性是一项系统工程,需要持续迭代演进,盘古经过十年以上的线上锤炼,积累了丰富的实践经验。
1254 7
|
存储 分布式计算 Hadoop
基于Java的Hadoop文件处理系统:高效分布式数据解析与存储
本文介绍了如何借鉴Hadoop的设计思想,使用Java实现其核心功能MapReduce,解决海量数据处理问题。通过类比图书馆管理系统,详细解释了Hadoop的两大组件:HDFS(分布式文件系统)和MapReduce(分布式计算模型)。具体实现了单词统计任务,并扩展支持CSV和JSON格式的数据解析。为了提升性能,引入了Combiner减少中间数据传输,以及自定义Partitioner解决数据倾斜问题。最后总结了Hadoop在大数据处理中的重要性,鼓励Java开发者学习Hadoop以拓展技术边界。
522 7
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
812 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
849 4
|
机器学习/深度学习 人工智能 分布式计算
【AI系统】分布式通信与 NVLink
进入大模型时代后,AI的核心转向大模型发展,训练这类模型需克服大量GPU资源及长时间的需求。面对单个GPU内存限制,跨多个GPU的分布式训练成为必要,这涉及到分布式通信和NVLink技术的应用。分布式通信允许多个节点协作完成任务,而NVLink则是一种高速、低延迟的通信技术,用于连接GPU或GPU与其它设备,以实现高性能计算。随着大模型的参数、数据规模扩大及算力需求增长,分布式并行策略,如数据并行和模型并行,变得至关重要。这些策略通过将模型或数据分割在多个GPU上处理,提高了训练效率。此外,NVLink和NVSwitch技术的持续演进,为GPU间的高效通信提供了更强的支持,推动了大模型训练的快
636 0