智能巡检告警配置最佳实践

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000 次 1年
文件存储 NAS,50GB 3个月
简介: 智能异常分析的检测结果通过 SLS 告警功能输出到用户配置的通知渠道。在智能巡检场景中,单个任务往往会巡检大量的实体对象,涉及到的对象规则很多,我们通过SLS新版告警可以实现较好的对于巡检事件的管理。

智能异常分析的检测结果通过 SLS 告警功能输出到用户配置的通知渠道。在智能巡检场景中,单个任务往往会巡检大量的实体对象,涉及到的对象规则很多,我们通过SLS新版告警可以实现较好的对于巡检事件的管理。

巡检事件基础结构

在这里,我们先简单看下巡检任务的基本逻辑:

对于单个巡检作业而言,内部包含N个实体的巡检,每个巡检实体对应一个巡检模型,其中任意一个异常事件产生后,都会通过告警系统通知到用户,因此我们需要有能力通过不同的方式将结果进行分发和管理。

我们先看下巡检事件的基础结构,具体的内置模板如下所示:

## 数据源
+ Project: ${results[0].project}
+ LogStore: ${results[0].store}
##  异常对象
+ Entity: ${labels}
## 异常程度
+ Score: ${annotations.anomaly_score}
## 异常时序图
![image](${annotations.__plot_image__})
[[数据详情](${query_url})]
[[作业详情](${alert_url})]
[[确认](${annotations.__ensure_url__})]
[[误报](${annotations.__mismatch_url__})]

我们一起来看下具体的告警消息的样例,接下来我们所有的描述都会根据对应的如下结果进行描述。

{
"results": [
    {
"store_type": "log",
"region": "cn-chengdu",
"project": "sls-ml-demo",
"store": "machine_metric_logtail",
"start_time": 1641361140,
"end_time": 1641361200    }
  ],
"labels": {
"ip": "192.168.1.5",
"name": "load_avg"  },
"annotations": {
"__ensure_url__": "$url_path",
"__mismatch_url__": "$url_path",
"__plot_image__": "$url_path",
"alert_msg_type": "ml_anomaly_msg",
"anomaly_score": "0.8000",
"anomaly_type_id": "1",
"anomaly_type_name": "STAB_TYPE",
"job_id": "29030-2bbf5beba0110fa869339708a8217b67",
"model_id": "9c0f0d5ad4879eb75237e2ec8494f5f1",
"title": "metric-logtail-sql"  },
"severity": 8,
"drill_down_url": "$url_path"}


典型场景配置

场景一

目标:过滤特定实体的异常

操作步骤

  • 寻找到某个巡检任务的【行动策略ID】,这里要根据用户自己的实际配置来确定,具体的路径如下:

  • 在行动策略中,添加对应的条件

  • 根据上述提供的告警字段而言,我们假设目前只将【标签】中字段为【ip】且值为【192.168.1.5】的告警消息发送到特定的【钉钉机器人】中

场景二

目标:过滤特定分数的异常

操作步骤

  • 找到特定的【行动策略ID】,添加【条件】
  • 配置【异常分数】超过【0.9】分数以上的告警到特定的渠道
  • 【名称】- anomaly_score
  • 【正则】- ^((1\.0*)|(0\.9[0-9]*))$

场景三

目标:过滤特定实体的特定分数的异常

操作步骤

  • 找到特定的【行动策略ID】,添加【条件】
  • 配置【特定实体】的【异常分数】超过【0.9】分数以上的告警到特定的渠道
  • 【标注】的名称设置为 anomaly_score,【正则】- ^((1\.0*)|(0\.9[0-9]*))$
  • 【标签】的名称设置为 ip,对应的实体内容是 192.168.1.5

场景四

目标:过滤特定异常类型的异常

操作步骤

  • 找到特定的【行动策略ID】,添加【条件】
  • 配置【特定异常形态】

场景五

目标:根据巡检事件和根因事件类型进行分发

操作步骤

  • 找到特定的【行动策略ID】,添加【条件】
  • 配置【智能告警的事件类型】
  • 配置【标注】alert_msg_type,对应的值是 ml_anomaly_msg (这个字段表示的是智能巡检的告警)


参考资料

相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
目录
相关文章
|
14天前
|
机器学习/深度学习 人工智能 运维
运维告警别乱飞了!AI智能报警案例解析
运维告警别乱飞了!AI智能报警案例解析
91 0
|
6月前
|
运维 Prometheus 监控
基于阿里云可观测产品构建企业级告警体系的通用路径与最佳实践
本文围绕企业级告警体系构建展开,探讨了监控与告警在系统稳定性中的重要作用。通过梳理监控对象、分析指标、采集数据及配置规则等环节,提出告警体系建设的通用流程,并针对多平台告警、误报、告警风暴等问题提供解决思路。结合阿里云可观测产品,分享了某电商企业的实践案例,展示了如何通过标签规范、日志标准和统一管理平台实现高效告警处置,为构建全面且实用的告警体系提供了参考指南。
470 1
|
4月前
|
编解码 监控 算法
CDN+OSS边缘加速实践:动态压缩+智能路由降低30%视频流量成本(含带宽峰值监控与告警配置)
本方案通过动态压缩、智能路由及CDN与OSS集成优化,实现视频业务带宽成本下降31%,首帧时间缩短50%,错误率降低53%。结合实测数据分析与架构创新,有效解决冷启动延迟、跨区域传输及设备适配性问题,具备快速投入回收能力。
228 0
|
11月前
|
Prometheus 运维 监控
智能运维实战:Prometheus与Grafana的监控与告警体系
【10月更文挑战第26天】Prometheus与Grafana是智能运维中的强大组合,前者是开源的系统监控和警报工具,后者是数据可视化平台。Prometheus具备时间序列数据库、多维数据模型、PromQL查询语言等特性,而Grafana支持多数据源、丰富的可视化选项和告警功能。两者结合可实现实时监控、灵活告警和高度定制化的仪表板,广泛应用于服务器、应用和数据库的监控。
980 3
|
7月前
|
Prometheus Kubernetes 监控
Kubernetes监控:Prometheus与AlertManager结合,配置邮件告警。
完成这些步骤之后,您就拥有了一个可以用邮件通知你的Kubernetes监控解决方案了。当然,所有的这些配置都需要相互照应,还要对你的Kubernetes集群状况有深入的了解。希望这份指南能帮助你创建出适合自己场景的监控系统,让你在首次发现问题时就能做出响应。
324 22
|
7月前
|
运维 监控 前端开发
Zabbix告警分析新革命:DeepSeek四大创新场景助力智能运维
面对日益复杂的IT环境,高效分析监控数据并快速响应成为运维的关键挑战。本文深入探讨了DeepSeek与Zabbix结合的创新应用,包括一键式智能告警分析、Zabbix文档知识库助手及钉钉告警增强功能。通过部署指南和实用脚本,展示了如何提升故障排查效率,为运维工程师提供高效解决方案。
630 5
|
Prometheus 监控 Cloud Native
【监控】prometheus传统环境监控告警常用配置
【监控】prometheus传统环境监控告警常用配置
【监控】prometheus传统环境监控告警常用配置
|
8月前
|
人工智能 运维 监控
Zabbix告警分析新纪元:本地DeepSeek大模型实现智能化告警分析
本文由Zabbix中国峰会演讲嘉宾张世宏撰写,介绍如何通过集成Zabbix监控系统与深度求索(DeepSeek)AI助手,构建智能化告警处理方案。该方案利用Webhook机制传递告警信息,借助DeepSeek的智能分析能力,帮助运维团队快速识别问题根源并提供解决方案。文章详细描述了技术架构、环境搭建、Webhook配置及实际案例,展示了AI在运维领域的应用前景和优势。
1089 0
|
7月前
|
运维 Prometheus 监控
基于阿里云可观测产品构建企业级告警体系的通用路径与最佳实践
基于阿里云可观测产品构建企业级告警体系的通用路径与最佳实践
261 1

热门文章

最新文章