惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
T
Tenable Blog
Webroot Blog
Webroot Blog
L
Lohrmann on Cybersecurity
S
Securelist
S
Schneier on Security
NISL@THU
NISL@THU
Know Your Adversary
Know Your Adversary
C
Cybersecurity and Infrastructure Security Agency CISA
T
The Exploit Database - CXSecurity.com
L
LINUX DO - 热门话题
C
CXSECURITY Database RSS Feed - CXSecurity.com
O
OpenAI News
I
Intezer
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
TaoSecurity Blog
TaoSecurity Blog
S
Secure Thoughts
Application and Cybersecurity Blog
Application and Cybersecurity Blog
P
Privacy International News Feed
H
Hacker News: Front Page
N
Netflix TechBlog - Medium
M
MIT News - Artificial intelligence
博客园 - Franky
PCI Perspectives
PCI Perspectives
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Microsoft Azure Blog
Microsoft Azure Blog
MongoDB | Blog
MongoDB | Blog
L
LangChain Blog
P
Proofpoint News Feed
S
Security Affairs
WordPress大学
WordPress大学
The Last Watchdog
The Last Watchdog
S
SegmentFault 最新的问题
小众软件
小众软件
F
Full Disclosure
博客园 - 叶小钗
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
T
The Blog of Author Tim Ferriss
Simon Willison's Weblog
Simon Willison's Weblog
P
Palo Alto Networks Blog
Security Latest
Security Latest
P
Proofpoint News Feed
月光博客
月光博客
T
Tailwind CSS Blog
Scott Helme
Scott Helme
Hacker News - Newest:
Hacker News - Newest: "LLM"
Google Online Security Blog
Google Online Security Blog
T
Threat Research - Cisco Blogs
Help Net Security
Help Net Security
Project Zero
Project Zero

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
智能化监控告警系统:基于物联网移动网络通信服务平台的设计与实现
产品@Devin · 2023-05-11 · via 人人都是产品经理

监控告警系统是一款用于实时监控各类设备和系统状态的工具,通过采集、分析和处理数据,生成有价值的指标和警报信息,并向管理员发送通知,确保系统稳定运行。本文作者对智能化监控告警系统进行了详细的分析,一起来看一下吧。

一、系统概述

监控告警系统是一款用于实时监控各类设备和系统状态的工具,通过采集、分析和处理数据,生成有价值的指标和警报信息,并向管理员发送告警通知,帮助管理员及时发现和解决问题,确保系统稳定运行。

  • 保持系统稳定:监控告警系统需要实时监控系统运行状态,并能够及时发现问题和异常情况,及时发出告警通知并迅速响应异常,以便管理员采取及时措施。
  • 优化运营策略:监控告警系统支持对各项运营指标进行监控以及分析,帮助运营人员及时调整运营策略,提高运营工作效率。例如通过监控设备的流量使用情况,合理调整不同套餐的限速策略,避免出现用户薅羊毛行为导致的流量浪费;
  • 改善服务质量:监控告警系统支持对设备和系统状态的数据进行采集和分析,生成有价值的指标和警报信息,及时发现并解决问题,避免用户受到影响,提高用户体验。例如通过监控设备的故障率,当出现大规模的设备故障时,能第一时间介入解决问题,避免设备故障导致用户无法使用服务。
  • 实现成本控制:监控告警系统支持对成本相关指标进行监控以及分析,帮助运营人员掌握SIM卡资源的使用情况,有效地控制成本。例如,通过监控 SIM 卡库存情况,合理调整采购 SIM 卡策略,避免库存过高或过低带来的损失。
  • 性能和可扩展性:监控告警系统需要具有良好的性能和可扩展性,以应对大量数据的处理和分析。
  • 安全和风险管理:监控告警系统需要具备安全和风险管理机制,以保证数据的机密性和完整性。同时需要进行备份和恢复策略的设计,以应对系统出现故障的情况。

二、功能模块

系统主要包括数据采集模块、数据分析模块、告警通知模块、告警处理模块、数据展示模块、管理界面模块等多个功能模块。

  • 数据采集模块:负责采集各个模块的数据,包括但不限于平台系统、SIM卡、设备等产生的数据。采集的数据会存储到对应的数据库中,供后续分析使用。
  • 数据分析模块:负责对采集到的数据进行处理、分析和计算,从而得出有价值的指标和警报信息。数据处理模块包括数据分析、告警规则和算法等子模块。
  • 告警通知模块:负责向管理员发送数据分析模块生成的警报通知,包括短信、邮件、即时消息等多种形式。管理员可以根据自己的需求,选择接收告警通知的方式。
  • 告警处理模块:负责记录告警信息的处理情况,包括告警信息是否已经被处理,处理结果如何等。管理员在收到告警通知后,采取措施解决问题,并将处理情况记录,以便后续分析和跟踪。
  • 数据展示模块:负责将监控数据以及分析结果以Dashboard的形式展示出来,帮助管理员更直观地了解系统运行状况。例如,管理员可以通过数据展示模块查看在线设备数的历史趋势,以便更好地调整运营策略。
  • 管理界面模块:提供监控告警系统的管理界面,管理员可以通过该界面进行系统配置、警报设置、数据查看等操作。管理员可以在该界面中设置预警阈值等参数,用于数据分析模块的判断标准。

三、数据采集以及存储

数据采集和存储是监控告警系统中非常重要的环节。一方面,数据的质量和及时性决定了监控告警系统的准确度和实时性;另一方面,数据的存储和处理能力也会对系统的性能和可扩展性产生重大影响。

1. 数据采集

在监控告警系统中,需要采集各个业务系统、设备、应用程序以及核心指标的数据,包括但不限于服务器负载、网络延迟、存储空间、设备故障率、用户访问量等。数据采集的方式可以通过定时轮询、推送通知等多种方式进行。

一种常见的数据采集方式是通过轮询获取各个监控对象的数据。轮询方式通常会周期性地向监控对象发送请求,并获取相应的数据。通过这种方式,可以快速、准确地获取监控对象的数据,但同时也会增加系统的负载和网络流量。

另一种数据采集方式是通过推送通知的方式获取数据。在这种方式下,监控对象会主动将自己的状态信息推送给监控告警系统,监控告警系统只需要监听推送通知并接收数据即可。这种方式能够实现实时数据采集,避免了轮询方式下可能存在的延迟和不准确性。

2. 数据存储

采集到的数据需要进行存储,以便后续的数据分析和指标生成。监控告警系统通常会采用分布式存储方案,以保证数据的高可靠性和高可用性。常见的分布式存储方案包括主从架构、集群架构等。

主从架构一般是指将数据存储在主节点上,然后通过从节点对数据进行备份和冗余。主节点和从节点之间通过数据同步机制进行数据同步,保证数据的可靠性和一致性。主从架构方案适用于数据量比较小的场景,相比于集群架构,主从架构的实现成本更低。

集群架构则是将数据存储在多个节点上,每个节点都可以读写数据。在数据写入时,系统会将数据分散到不同的节点上,以提高数据写入的性能和可扩展性。集群架构适用于数据量较大或读写请求较为频繁的场景,但相对于主从架构,其实现成本更高。

此外,为了提高系统性能和查询效率,监控告警系统还可以采用数据分片、索引优化等技术进行优化。数据分片可以将数据划分为多个部分,分别存储到不同的节点中,从而提高数据的并发读写能力和可扩展性。索引优化则可以通过建立适当的索引结构,加快数据的查询速度和准确性。

四、指标生成以及警报信息

在监控告警系统中,指标生成和警报信息是核心功能之一。通过采集和存储的数据,系统需要对其进行分析和计算,生成各种监控指标,并及时发出警报信息,提醒相关人员进行处理和调整。

1. 数据分析

数据分析模块的主要任务是对采集到的数据进行处理和分析,以便生成相应的监控指标和监控报告。在数据分析的过程中,需要考虑如下几个方面:

  1. 数据分析算法和模型的选择:根据不同的监控对象和指标,采用不同的算法和模型进行处理。例如,对于网络延迟和丢包率等指标,可以采用线性回归、异常检测等算法来进行分析和处理。
  2. 实时分析和计算:根据预设的规则和算法对采集到的数据进行实时分析和计算,并将生成的指标和警报信息存储到相应的数据库中,以供后续查询和使用。例如,对于可分配卡数和已分配卡数等卡库存相关指标,需要进行实时计算统计,避免出现卡库存不足导致的服务故障;
  3. 可视化和报告生成:为了能让用户进行更加直观和方便的数据分析和决策,需要将分析结果以可视化的形式展示出来。例如,对于故障设备率和故障设备数等指标,可以按照时间线使用折线趋势图来进行展示。

2. 指标生成

指标生成模块通常会从存储的数据中,提取出关键的业务指标和监控指标,并将其计算、转换、聚合等操作,生成新的指标数据。监控指标可以分为系统级别指标、应用级别指标以及业务定制化指标:

  1. 系统级别指标包括CPU利用率、内存利用率、磁盘空间利用率等,可以帮助管理员全面了解系统的状态和性能。
  2. 应用级别指标则更加细化,如某个应用程序的响应时间、访问量等,可以帮助开发人员对应用程序进行优化和调整。
  3. 业务定制化指标通常与业务的核心流程和关键性能指标相关,可以根据需求进行定制化,以满足不同用户的监控需求,如卡库存、采购成本、订单量、故障设备率等等。这些指标对于业务决策非常关键,可以帮助业务人员快速发现问题,及时调整业务策略,提高业务效率和盈利能力。

3. 警报信息

警报信息则是根据指标生成模块生成的监控指标进行判断和计算,及时发出警报信息,提醒相关人员进行处理和调整。

根据警报信息的类型和严重程度,可以分为三种:普通告警、严重告警和紧急告警。系统可以根据不同的告警级别进行灵活配置,如设置普通告警无需处理,但需要记录日志;严重告警需要及时通知相关人员,以便进行处理;紧急告警需要立即采取措施,以避免损失。

五、算法与规则设计

为了能快速、准确地检测到异常情况,及时发出警报,需要设计各种算法与规则,用于对采集到的监控数据进行分析、计算和判断,从而生成指标和告警信息。

1. 异常检测算法

异常检测算法是指对采集到的监控数据进行处理和计算的算法,识别出异常情况,主要用于监测设备、传感器和其他IOT节点的状态和性能。常见的异常检测算法包括:

  1. 基于统计的异常检测算法:该算法基于统计学原理,将各种监控指标进行分析和比较,识别出与正常情况不符的数据点。例如,可以计算在线故障设备的历史数据平均值和标准差,然后使用均值加减3倍标准差作为异常检测的阈值,超过该阈值的数据点将被视为异常数据。
  2. 基于机器学习的异常检测算法:该算法利用机器学习技术对监控数据进行分析和建模,从而识别出与正常情况不符的模式和规律。例如,可以使用聚类算法对监控数据进行分类,然后使用异常检测算法对每个类别的数据进行分析和比较,识别出异常数据。
  3. 基于规则的异常检测算法:该算法通过预先定义一组规则,对监控数据进行检测和分析,识别出与规则不符的数据点。例如,可以定义规则检测设备不可用时长数据是否超过了阈值,如果超过了就视为异常数据。

2. 告警规则设置

告警规则需要结合业务需求,通过对监控指标进行分析和比对,判断当前状态是否正常,并生成相应的告警信息的规则。告警规则需要考虑多个因素,如监控指标的变化趋势、阈值设定、告警级别、告警通知方式等。常用的告警规则有:

  1. 阈值告警规则:该规则根据监控指标的阈值来触发警报,例如,当可分配SIM卡数低于阈值时,就会触发警报,并通知相关人员和部门。
  2. 持续时间告警规则:该规则根据监控指标的持续时间来触发警报,例如,当在线设备故障率超过了阈值,并持续5分钟以上时,就会触发警报,并通知相关人员和部门。
  3. 模式告警规则:该规则根据监控指标的模式和趋势来触发警报,例如,当在线设备的可用率在一段时间内一直处于下降趋势时,就会触发警报,并通知相关人员和部门。
  4. 组合告警规则:该规则是将多个告警规则进行组合,当满足其中一个或多个规则时,就会触发警报,并通知相关人员和部门。
  5. 定时告警规则:该规则根据时间设置来触发警报,例如,每天下午4点时,对设备进行一次巡检,若发现异常,则触发警报,并通知相关人员和部门。
  6. 机器学习告警规则: 机器学习算法可以对历史数据进行分析和建模,根据数据模式来识别异常行为,并触发相应的警报。例如,可以使用机器学习算法来分析设备的使用流量,当出现异常使用流量行为时,就触发警报并通知相关人员和部门。
  7. 基于事件的告警规则: 基于事件的告警规则可以根据事件的发生来触发警报。例如,通过对设备状态数据的监测,当出现设备异常故障这些事件时,监控系统可以自动触发警报,并通知相关人员进行故障诊断和修复。

3. 自动化告警处理算法

自动化告警处理算法是指对告警信息进行处理和分析的算法,以减轻管理员的工作负担。在物联网平台中,自动化告警处理算法尤其重要,因为物联网设备数量庞大,监控指标繁多,手动处理告警信息几乎是不可能的。例如,当系统出现异常告警时,自动化告警处理算法可以自动化地进行故障定位和修复操作。

常见的自动化告警处理算法包括:

1)自动化分析算法

通过对告警信息进行自动化分析和处理,提高告警处理的效率和准确性,减少人工处理的工作量。

  • 告警信息的提取和解析:通过自动化算法对监控系统采集到的告警信息进行提取和解析。例如,从告警信息中提取出关键字、设备类型、SIM卡信息等重要信息。
  • 告警信息的分类:对采集到的告警信息进行分类,以便更快速地找到相关问题。例如,将告警信息分为硬件故障、网络异常、卡故障、系统错误等类别。
  • 告警信息的关联分析:对不同的告警信息进行关联分析,找出异常的根本原因,并对告警信息进行去重,避免重复处理同一问题。例如,将不同设备之间的告警信息进行关联分析,找出故障的根本原因。
  • 告警信息的预测分析:通过对历史数据的分析,预测未来可能出现的故障情况。例如,通过对设备运行数据的分析,预测未来可能出现的设备故障情况,提前进行维护和修复。

2)自动告警处理算法

根据预设的规则自动执行一定的处理动作,如发送短信、邮件等通知方式。

  • 发送通知:根据预设的规则,自动发送通知消息,如短信、邮件等,通知相关人员或部门进行处理。
  • 执行预设操作:根据预设的规则,自动执行一些操作,如重启设备、调整设备配置等。
  • 自动调整策略:根据预设的规则,自动调整监控策略,例如调整监控阈值等。
  • 自动忽略告警:根据预设的规则,自动判断告警是否需要处理,如果不需要则忽略。
  • 自动关闭告警:根据预设的规则,自动关闭已经处理完毕的告警。

六、告警通知的实现

告警系统发现问题并生成告警时,告警通知模块会自动触发,并将告警信息通知给相关人员和部门,以便及时采取措施解决问题。以物联网移动网络通信服务平台为例,当监控系统发现问题时,告警通知模块会自动触发并发送告警通知,具体步骤如下:

1)告警生成:监控系统检测到异常情况并生成告警信息。

2)告警分类:告警通知模块对告警信息进行分类,根据不同的告警等级和类型,选择相应的通知方式和接收人员。

3)通知方式选择:告警通知模块根据用户设置的通知方式,选择合适的方式通知相关人员。例如,对于紧急的告警,可以通过短信或电话通知负责人员;对于普通的告警,可以通过邮件或即时通讯工具(企业微信或钉钉等)通知相关人员,低级别告警则在大屏幕上进行展示即可。

  • 邮件通知:将告警信息通过邮件发送给相关人员或部门。该方式适用于需要及时通知并且信息量较大的告警情况。
  • 短信通知:将告警信息以短信的形式发送给相关人员或部门。该方式适用于需要紧急通知但信息量较少的告警情况。
  • 语音电话通知:将告警信息通过语音电话形式通知相关人员或部门。该方式适用于需要紧急通知但又不能立即查看信息的告警情况。
  • 微信/钉钉/企业微信等即时通讯工具通知:将告警信息通过即时通讯工具发送给相关人员或部门。该方式适用于需要及时通知且方便处理的告警情况。
  • 大屏幕展示:将告警信息以可视化的形式展示在大屏幕上,方便相关人员实时了解监控情况。
  • 应用内通知:当监控系统产生告警信息时,可通过应用内通知的方式快速通知相关人员,并提供详细的告警信息。

4)通知内容生成:告警通知模块生成告警通知内容,并将告警信息、设备信息、时间等关键信息包含在通知中,以便相关人员了解问题的具体情况。

5)通知发送:通过自定义规则,告警通知模块将通知发送给预设的接收人员,同时记录发送时间、发送状态等信息,方便后续跟进和处理。

七、警报信息处理

对已经发出来的告警信息进行处理以及记录处理的内容,可以让管理员清晰了解每个告警的处理状态和处理过程,帮助管理员更好地管理和维护系统。

1. 告警信息的处理

当一个告警被触发并且通知给管理员后,管理员需要对这个告警信息进行处理。这个处理过程包括以下几个步骤:

  1. 分析告警信息:管理员需要对告警信息进行分析,了解告警的来源、告警等级以及影响范围等,以便更好地判断告警的紧急程度和处理方法。
  2. 判断告警的处理方法:根据告警的紧急程度和影响范围,管理员需要判断告警的处理方法。如果告警比较紧急且影响范围较大,管理员需要立即采取措施处理告警;如果告警比较普通且影响范围较小,管理员可以在合适的时间进行处理。
  3. 处理告警:管理员需要采取措施对告警进行处理。具体措施包括重新启动设备、更换已分配的SIM卡、修改配置等等。处理完成后,管理员需要记录处理的内容,以便后续的跟踪和分析。

2. 处理记录的跟踪

在物联网移动网络通信服务平台中,每个告警信息都应该有相应的处理记录,以便管理员追踪告警的处理情况。处理记录的跟踪包括以下几个方面:

1)记录告警的处理过程

管理员需要记录告警的处理过程,包括采取的措施、处理时间、处理结果等等。这些记录可以帮助管理员了解告警的处理情况和处理效果。

2)记录告警的处理人员

管理员需要记录处理告警的人员信息,包括处理人员的姓名、工号、联系方式等等。这些记录可以帮助管理员了解告警的处理责任人和责任区域。

3)记录告警的处理状态

管理员需要记录告警的处理状态,包括告警的开始时间、结束时间、处理状态等等。这些记录可以帮助管理员了解告警的处理状态和处理效率。

  • 未处理:当监控系统接收到告警信息后,还没有进行任何处理,此时告警状态为未处理状态。
  • 处理中:当管理员开始处理告警信息时,告警状态会被设置为处理中。此时,管理员正在对告警信息进行分析和处理。
  • 已解决:当管理员处理告警信息后,确定问题已经得到解决,告警状态将被设置为已解决状态。
  • 误报:当告警信息被判定为误报时,告警状态会被设置为误报状态。
  • 忽略:当管理员认为告警信息不需要被处理时,可以将告警状态设置为忽略状态。

4)记录告警的处理结果

管理员需要记录告警的处理结果,包括处理结果的有效性、处理结果的影响范围等等。这些记录可以帮助管理员了解告警处理的情况,追踪问题的解决过程,并为未来的处理提供参考。对于重要的告警事件,还可以向相关人员发送告警处理的结果,以便及时通知相关人员。

  • 告警处理结果描述:管理员需要描述告警的处理结果,包括解决方案、处理过程等。
  • 处理结果状态:管理员需要记录处理结果的状态,如已解决、处理中等。
  • 处理人员:记录处理告警的人员,以便追踪问题的处理过程。
  • 处理时间:记录告警处理的时间,以便追踪问题的解决过程。
  • 处理影响范围:记录告警处理的影响范围,以便管理员评估问题的严重程度,并为未来的处理提供参考。

八、系统界面设计

在物联网移动网络通信服务平台中,监控告警系统的系统界面通常包括以下功能模块:

1)告警设置模块

用于设置告警的规则和处理方式,如设置告警的级别、触发条件、告警通知方式、告警的处理方式等。

2)告警列表模块

包括当前所有的告警信息以及过去所有发生的告警信息,包括告警等级、告警类型、告警内容、告警时间等信息。

  • 管理员通过快速浏览当前所有的告警信息,并进行快速的定位和处理。
  • 管理员通过查看历史告警的记录,并了解告警的处理情况和处理结果。

3)告警详情模块

展示选中告警的详细信息,包括告警的发生时间、告警的影响范围、告警的处理情况等信息。管理员可以通过该模块深入了解告警的具体情况,从而更好地制定解决方案。

4)告警处理模块

用于处理已经发生的告警,通常在告警详情页面进行处理。管理员可以通过该模块对告警信息进行处理,包括告警确认、告警分配、告警处理进展跟踪等。同时,管理员也可以将处理结果记录在该模块中,便于后续的跟踪和分析。

5)告警统计模块

对所有告警信息进行统计分析,包括告警级别、告警类型、设备类型、告警时间、告警内容等等。通过该模块来了解告警情况的总体概括,同时也为监控系统的改进和优化提供数据支持。

  • 总览界面:展示系统中的所有告警信息,以及告警的处理情况和处理结果,并按照告警级别、告警类型等分类。
  • 数据可视化分析界面:结合具体的监控告警指标,通过图表的形式展示具体告警数据的趋势和变化,例如历史告警故障设备趋势、历史故障SIM卡分布等。

6)系统配置模块

用于对监控告警系统权限进行配置和管理。管理员可以通过该模块对系统的用户、权限、日志等进行管理,确保系统的安全和稳定运行。

本文由 @产品@Devin 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。