1.本发明涉及流量数据技术领域，具体涉及一种基于流量数据的告警系统及方法。
背景技术：
2.在当今的金融行业中，互联网技术的普及和发展引领了许多创新和变化，尤其是对于以b端（browser）/ s端（server）架构为主的企业。这种架构无法避免接口交互，而接口的异常，如不可用或响应过慢等问题，可能对应用的稳定性和性能产生重大影响。
3.目前，这些接口异常往往需要依赖用户主动反馈或者巡检员点检后才能被发现，这无疑使得问题的发现渠道十分被动，极大地阻碍了研发人员能够第一时间发现并定位问题。此外，在定位问题的过程中，研发人员需要从入口开始，按照业务逻辑一步步排查，往往不能立刻定位到根本原因。这样就会导致问题暴露的时间延长，用户体验降低，进而给公司带来了巨大的损失。
4.另一方面，由于研发人员一般不会直接面对客户，所以异常的反馈链路也很长。当客户出现问题时，首先需要通过客服或专门对接的人员收集到问题，然后跨部门反馈给对应的开发负责人，开发负责人再根据出问题的接口所属的领域，将问题指派给具体的研发人员。这样一来，不仅增加了沟通成本，也拉长了问题解决的速度和效率。
5.因此，目前的告警系统存在的问题，如对实时流量变化的适应性差，不能提供准确的异常定位，告警噪声大等问题，都尤其在金融行业中显得尤为严重。这就更加突出了开发一种基于流量数据的告警系统，可以弹性计算告警阈值，准确定位异常，并有效降低告警噪声的必要性，以提高问题解决的效率，降低用户反馈和问题解决的时间，从而提高用户体验，减少公司损失。
技术实现要素：
6.为克服现有技术的不足，本发明提出一种基于流量数据的告警系统及方法，以解决生产环境中，发现流量异常不及时、不能提前预警、流量异常问题反馈链路过长、研发人员定位解决异常的速度慢等问题。
7.为实现上述目的，本发明提供一种基于流量数据的告警方法，包括：步骤s1：为每个接口设置明确的告警阈值；步骤s2：使用埋点和后台线程收集并存储请求数据和响应时间；步骤s3：按已设告警阈值，聚合计算每条流量数据，判断是否达到告警条件；步骤s4：当触发告警时，验证并重新设置告警阈值，排除因设定不当引发的误报告警；步骤s5：若确认有异常，调用算法并利用ai模型找出原因；步骤s6：根据告警频次和接口的分类，设定告警频率和通知方式。
8.进一步地，步骤s1具体如下：步骤s11：登录系统，选择需要监控的应用和接口；
步骤s12：根据特定接口的使用情况和要求，设定实时规则和延时规则的告警阈值；步骤s13：选择使用的阈值规则，确保告警的准确性和实用性。
9.进一步地，步骤s2具体如下：步骤s21：当发起请求访问时，通过http等协议将请求发送至服务器；步骤s22：使用埋点的方式，收集并在服务器内存中保存相关的数据信息，包括请求数据和对应的响应时间；步骤s23：启动后台线程，每秒钟汇总内存中的所有数据，并将这些数据信息投入到kafka消息中间件中；步骤s24：告警系统通过监听kafka消息，对相同应用、接口以及在同一秒中产生的数据进行汇总计算，然后将这些数据存储到influxdb时序数据库中以供后续使用和分析的数据服务包括根据条件查询模型数据、根据主键查询模型数据、根据主键修改模型数据、批量修改模型数据、批量新增模型数据、根据主键删除模型数据、批量删除模型数据、聚合数据服务。
10.进一步地，步骤s4具体如下：步骤s41：发出告警后，首先需要检查是否可能是由于阈值设置不合理导致的误报；步骤s42：根据应用和接口的维度，查看过去一个月内的历史流量数据，判断当前的qps/rt数据是否符合历史的规律；步骤s43：如果数据符合历史规律，那么将当前数据输入到阈值计算算法中，计算出新的阈值并重新设置阈值，告警处理流程到此结束；步骤s44：如果数据不符合历史规律，那么说明出现了异常情况，需要继续执行下一步的告警流程。
11.进一步地，步骤s5具体为在确认出现了异常情况后，需要调用异常定位模块的算法，异常定位模块基于请求链路、日志输出内容、硬件资源负载情况信息，使用ai模型进行分析，给出本次异常的原因。
12.进一步地，步骤s6具体为：步骤s61：根据接口的重要性以及是否选择降噪功能，来确定告警的频率和通知方式；步骤s62：在连续发出告警的次数达到阈值后，系统会自动提升接口的重要性等级，相应地提升告警的频率；步骤s63：告警信息可以通过企业微信、微信公众号、电子邮件和短信多种方式发送给接口的负责人。
13.进一步地，还包括自我学习的阈值调整，具体为：步骤s71：收集和存储大量的历史流量数据和告警事件；步骤s72：使用机器学习算法（例如决策树、神经网络等）来学习和建模这些数据。输入的特征可以包括时间、日期、请求的类型和数量等，输出的目标可以是是否发生了告警事件。
14.步骤s73：根据模型的预测结果，自动调整告警的阈值。例如，如果模型预测在每天
的18:00到20:00之间，系统的访问量通常会增加，那么就可以在这个时间段将阈值提高。
15.进一步地，还包括预测性告警：步骤s81：类收集和存储历史流量数据和告警事件。
16.步骤s82：使用预测型的机器学习模型（例如arima、lstm等）来预测未来的流量和告警事件。例如，可以预测在未来一小时内，每分钟的请求数量是多少，是否会超过告警的阈值。
17.步骤s83：如果预测的结果显示可能会发生告警事件，那么提前发出预警，给服务负责人足够的时间来预防问题的发生。
18.一种基于流量数据的告警系统，包括：阈值配置模块、流量数据收集模块、实时告警处理模块、阈值弹性计算模块、异常定位模块和告警通知与降噪模块；所述阈值配置模块负责接口告警阈值的设置，包括但不限于请求次数、响应时间等阈值。用户可以根据自己的需求，为每个接口定制明确的告警阈值；所述流量数据收集模块负责实时收集每个功能的请求数据和响应时间。通过埋点的方式，将用户访问的流量信息异步汇总到告警系统的数据库中；所述实时告警处理模块用于实时判断每条流量数据是否达到预设的告警阈值。如果达到阈值，可能需要触发告警；所述阈值弹性计算模块用于，当告警被触发时，阈值弹性计算模块会验证并重新设置告警阈值，以避免因阈值设置不合理而产生的误报；所述异常定位模块用于确认异常后，通过算法分析可能的原因，包括但不限于请求链路、日志输出内容、硬件资源负载情况等信息；所述告警通知与降噪模块用于根据告警频次和接口的分类，选择合适的告警通知方式，如企业微信、微信公众号、邮箱、短信等，并且可以在接口频繁触发告警但不影响用户体验的情况下，降低告警频率。
19.与现有技术相比，本发明的有益效果是：1.本发明提供了一种基于流量数据的告警系统及方法，主动采集流量数据并按应用 接口 时间粒度聚合，能够实时监测系统流量，提升了问题发现的效率，系统提供按照应用维度指定负责人，负责人可以自主选择自己希望的告警通知渠道，增强了告警消息的触达率。
20.2.本发明提供了一种基于流量数据的告警系统及方法，通过提供多种告警规则配置，实现了系统告警的个性化，满足了不同应用和接口的需求。
21.3.本发明提供了一种基于流量数据的告警系统及方法，利用接口维度进行分级，并实现了不同的降噪逻辑，有效地降低了无效告警，避免了告警信息的轰炸。
22.4.本发明提供了一种基于流量数据的告警系统及方法，依据历史数据通过数据算法不断优化阈值设置，使得系统更加灵活，能适应不同的流量变化。
23.5.本发明提供了一种基于流量数据的告警系统及方法，通过利用机器学习算法和其他数据平台的整合，提供了初步的异常原因定位，大大缩短了问题定位的时间，提升了问题处理的效率。
附图说明
24.为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
25.图1是本发明流程图；图2-3为管理系统ui设计；图4为本发明流量数据采集示意图；图5软件系统设计具体说明示意图；图6为红线规则计算流程图；图7为其他规则算法流程图；图8为软件操作运行流程图。
具体实施方式
26.下面将结合附图、通过对本发明的优选实施方式的描述，更加清楚、完整地阐述本发明的技术方案。
27.一种基于流量数据的告警系统，包括：阈值配置模块、流量数据收集模块、实时告警处理模块、阈值弹性计算模块、异常定位模块和告警通知与降噪模块；所述阈值配置模块负责接口告警阈值的设置，包括但不限于请求次数、响应时间等阈值。用户可以根据自己的需求，为每个接口定制明确的告警阈值；所述流量数据收集模块负责实时收集每个功能的请求数据和响应时间。通过埋点的方式，将用户访问的流量信息异步汇总到告警系统的数据库中；所述实时告警处理模块用于实时判断每条流量数据是否达到预设的告警阈值。如果达到阈值，可能需要触发告警；所述阈值弹性计算模块用于，当告警被触发时，阈值弹性计算模块会验证并重新设置告警阈值，以避免因阈值设置不合理而产生的误报；所述异常定位模块用于确认异常后，通过算法分析可能的原因，包括但不限于请求链路、日志输出内容、硬件资源负载情况等信息；所述告警通知与降噪模块用于根据告警频次和接口的分类，选择合适的告警通知方式，如企业微信、微信公众号、邮箱、短信等，并且可以在接口频繁触发告警但不影响用户体验的情况下，降低告警频率.如图1所示，本发明具体为：一种基于流量数据的告警方法，适用于一种基于流量数据的告警系统，包括：步骤s1：为每个接口设置明确的告警阈值；步骤s2：使用埋点和后台线程收集并存储请求数据和响应时间；步骤s3：按已设告警阈值，聚合计算每条流量数据，判断是否达到告警条件；步骤s4：当触发告警时，验证并重新设置告警阈值，排除因设定不当引发的误报告警；步骤s5：若确认有异常，调用算法并利用ai模型找出原因；
步骤s6：根据告警频次和接口的分类，设定告警频率和通知方式。
28.步骤s1具体如下：步骤s11：登录系统，选择需要监控的应用和接口；步骤s12：根据特定接口的使用情况和要求，设定实时规则和延时规则的告警阈值；步骤s13：选择使用的阈值规则，确保告警的准确性和实用性。
29.步骤s2具体如下：步骤s21：当发起请求访问时，通过http等协议将请求发送至服务器；步骤s22：使用埋点的方式，收集并在服务器内存中保存相关的数据信息，包括请求数据和对应的响应时间；步骤s23：启动后台线程，每秒钟汇总内存中的所有数据，并将这些数据信息投入到kafka消息中间件中；步骤s24：告警系统通过监听kafka消息，对相同应用、接口以及在同一秒中产生的数据进行汇总计算，然后将这些数据存储到influxdb时序数据库中以供后续使用和分析的数据服务包括根据条件查询模型数据、根据主键查询模型数据、根据主键修改模型数据、批量修改模型数据、批量新增模型数据、根据主键删除模型数据、批量删除模型数据、聚合数据服务。
30.步骤s4具体如下：步骤s41：发出告警后，首先需要检查是否可能是由于阈值设置不合理导致的误报；步骤s42：根据应用和接口的维度，查看过去一个月内的历史流量数据，判断当前的qps/rt数据是否符合历史的规律；步骤s43：如果数据符合历史规律，那么将当前数据输入到阈值计算算法中，计算出新的阈值并重新设置阈值，告警处理流程到此结束；步骤s44：如果数据不符合历史规律，那么说明出现了异常情况，需要继续执行下一步的告警流程。
31.步骤s5具体为在确认出现了异常情况后，需要调用异常定位模块的算法，异常定位模块基于请求链路、日志输出内容、硬件资源负载情况信息，使用ai模型进行分析，给出本次异常的原因。
32.步骤s6具体为：步骤s61：根据接口的重要性以及是否选择降噪功能，来确定告警的频率和通知方式；步骤s62：在连续发出告警的次数达到阈值后，系统会自动提升接口的重要性等级，相应地提升告警的频率；步骤s63：告警信息可以通过企业微信、微信公众号、电子邮件和短信多种方式发送给接口的负责人。
33.作为一种具体的实施方式还包括自我学习的阈值调整，具体为：步骤s71：收集和存储大量的历史流量数据和告警事件；步骤s72：使用机器学习算法（例如决策树、神经网络等）来学习和建模这些数据。
输入的特征可以包括时间、日期、请求的类型和数量等，输出的目标可以是是否发生了告警事件。
34.步骤s73：根据模型的预测结果，自动调整告警的阈值。例如，如果模型预测在每天的18:00到20:00之间，系统的访问量通常会增加，那么就可以在这个时间段将阈值提高。
35.作为一种具体的实施方式还包括预测性告警：步骤s81：类收集和存储历史流量数据和告警事件。
36.步骤s82：使用预测型的机器学习模型（例如arima、lstm等）来预测未来的流量和告警事件。例如，可以预测在未来一小时内，每分钟的请求数量是多少，是否会超过告警的阈值。
37.步骤s83：如果预测的结果显示可能会发生告警事件，那么提前发出预警，给服务负责人足够的时间来预防问题的发生。
38.如图2-3所示，用于展示现有的流量规则列表配置，操作步骤如下：（1）通过账号密码，登录告警系统页面；（2）打开规则列表页面，分页查看现有的告警规则；（3）可根据所属应用，所属接口等参数进行条件搜索；（4）点击新增或编辑按钮，弹出规则编辑弹窗；（5）填写规则类型/所属应用/所属接口；（6）点击 号，选择一个或多个需要添加的规则，并且逐个填写规则中的变量；（7）点击保存按钮，保存规则配置。
39.图4所示流量数据采集示意图，其运行流程如下：（1）利用agent技术，在每个web服务器上运行一个agent；每当接收到请求时，在内存中记录一下本次请求的时间stime。
40.（2）将请求数据继续发给web服务器处理。
41.（3）web服务器处理完成后，agent记录一下当前的时间etime；同时从内存中获取本次请求在s1时记录的开始时间stime；（4）使用请求开始时间etime，减去请求结束时间stime，计算后获得本次请求的实际耗时，单位是毫秒（ms）。
42.（5）将本次请求的耗时，保存到内存中。
43.（6） agent每隔一段时间，将内存中的所有数据，通过tcp接口发送给sentinel数据汇集服务。
44.（7）sentinel数据汇集服务将接收到的数据，按照应用/接口进行归类，然后以秒为维度，计算出平均耗时、请求总数。
45.（8）sentinel数据汇集服务将汇总后端数据，丢入kafka分布式消息系统。
46.（9）告警中心消费kafka消息，将数据保存influxdb数据库中，并且执行告警算法。
47.（10）如果有命中的告警规则，则通过通知模块给责任人发送告警消息。
48.图5软件系统设计具体说明示意图：使用模块化的思想，提取出不同类型的告警业务中的公共部分，将可变部分按照抽象接口的形式提供定制化的入口；将不可变部分固化，使用统一调度器 模板方法，最大程度的减少代码维护成本，并保持一定的扩展性。
49.作为一种具体的实施方式，流量数据收集模块：这是系统的入口，负责收集应用的实时流量数据。该模块会与其他应用的服务器进行交互，通过埋点技术收集到的数据会被发送到告警系统。
50.实时告警处理模块：这个模块接收来自流量数据收集模块的数据，并根据预先设定的阈值进行告警判定。它的输入是流量数据，输出是可能的告警事件。
51.阈值弹性计算模块：当实时告警处理模块产生一个可能的告警事件时，该模块会被触发。它负责校验当前的阈值是否合适，是否需要进行调整。如果需要调整阈值，该模块会更新在实时告警处理模块中使用的阈值。
52.异常定位模块：如果经过阈值弹性计算模块的校验，确认确实存在异常，那么该模块将被调用。它会通过分析请求链路、日志输出内容、硬件资源负载情况等信息，确定可能的异常原因。
53.告警通知与降噪模块：最后，该模块负责向接口负责人发送告警信息。它的输入是来自异常定位模块的异常原因，以及接口负责人的联系信息。告警通知将通过负责人选择的方式发送。
54.图6所示为红线规则计算流程图；（1）告警系统收到kafka消息后，首先将数据写入到influxdb中。如果写入失败，则直接中断本次处理。
55.（2）根据kafka消息里的所属应用和所属接口，从redis里获取现有的所有属于红线规则的告警配置。如果没有配置任何告警规则，则结束本次法处理。
56.（3）调用告警调度器，执行规则解析、告警计算。
57.（4）如果计算的结果，是需要执行告警，则调用告警通知模块的降噪算法，判断是否发送消息。如果需要降噪，则结束本次处理。
58.（5）如果不需要降噪，则利用告警通知模块发送通知消息，触达负责人。
59.图7所示为其他规则算法流程图；（1）告警系统收到kafka消息后，首先将数据写入到influxdb中。如果写入失败，则直接中断本次处理。
60.（2）根据kafka消息里的所属应用和所属接口，从redis里获取现有的所有不属于红线规则的其他规则的配置。如果没有配置任何告警规则，则结束本次法处理。
61.（3）根据规则配置的时间，将流量数据/规则配置放入[时间轮]数据结构中，等待[时间轮]触发执行告警计算。延迟触发时间设置为则中配置的时间。
[0062]
（4）[时间轮]根据延时配置，触发告警计算。
[0063]
（5）遍历规则集合，将流量数据和规则，传入告警核心分析调度器，执行规则解析，告警计算。
[0064]
（6）如果计算的结果，是需要执行告警，则调用告警通知模块的降噪算法，判断是否发送消息。如果需要降噪，则结束本次处理。
[0065]
（7）如果不需要降噪，则利用告警通知模块发送通知消息，触达负责人。
[0066]
图8为整理软件运行流程图，其流程如下：（1）登录系统，选择应用/接口，按需设置各类告警规则；（2）当用户访问某些功能时，通过埋点的方式，异步将流量信息汇总到系统数据
库；（3）按照设置的规则，聚合计算每一条流量数据，是否符合告警条件；（4）利用企业微信、微信公众号、邮箱、短信等方式，给接口负责人发送告警信息。
[0067]
作为一种具体的实施例，针对股票金融行业的特殊性，进行告警规则定制化，按时间维度分类，配置不同的阈值，并根据机器学习算法，自动优化阈值配置，具体如下：经过对金融股票行业的观察，大体上可以将一天分为集合竞价、开盘中、开盘后三个阶段，故本发明在阈值设计时，需要分别配置三个阶段的流量阈值，流量阈值的类型包括某个接口的每秒请求数（以下简称qps）和每秒平均响应时间（以下简称rt）；同时引入自动化算法，根据上文中的三个阶段的历史数据，自动分析计算出更合理的阈值，并自动设置最新阈值，降低误报概率，步骤如下：登录系统，选择应用/接口，按需设置各类告警规则，包括：1.【实时规则】集合竞价/盘中/盘后超过[变量y] qps/rt。
[0068]
2.【延时规则】集合竞价/盘中/盘后，[变量t]分钟内，[变量p]% 的qps/rt超过[变量y]值。
[0069]
3.【延时规则】集合竞价/盘中/盘后，[变量t]分钟内，出现[变量x]次超过[变量y]值的数据。
[0070]
4.【延时规则】根据[变量t]时间内的趋势走向，预测qps/rt即将超过[变量y]值。
[0071]
各个变量含义说明：集合竞价/盘中/盘后表示股市所处阶段，单选项，每当进行告警计算时，会优先根据股票所处阶段决定使用哪一种阈值规则；[变量t]表示时间，单位分钟，整数，如5分钟，30分钟等，因为超过1小时的数据不具有参考价值，所以该变量最大支持到1小时。[变量p]表示百分比，2位小数浮点数，最大100；[变量x]表示次数，类型为整数；[变量y]表示阈值的具体数值，根据业务场景是不同的类型，目前qps为整数和rt为浮点数。
[0072]
规则含义详细说明：【实时规则】集合竞价/盘中/盘后超过[变量y] qps/rt，当流量数据中的qps或者响应时间，超过设定的阈值[变量y]，则直接发送告警。
[0073]
【延时规则】集合竞价/盘中/盘后，[变量t]分钟内，p% 的qps/rt超过[变量y]值，当接收到流量数据后，根据时间设置[变量t]，发布一个延时计算任务。当延时计算任务触发时，从influxdb中查询t时间内的所有历史数据，将这些历史数据根据数值的大小进行排序，并根据百分比配置[变量p]，计算出这些历史数据中位于[变量p]%的具体值，然后使用百分位的具体值和流量数据中的值进行比较，若百分位的具体值小于流量数据中的值，则触发告警；否则结束本次告警计算。
[0074]
【延时规则】集合竞价/盘中/盘后，[变量t]分钟内，出现[变量x]次超过[变量y]值的数据，当接收到流量数据后，根据时间设置[变量t]，发布一个延时计算任务。当延时计算任务触发时，从influxdb中查询t时间内的所有历史数据，对配置中的阈值[变量y]的历史数据进行计数，如果计数值大于阈值[变量x]，则触发告警；否则结束本次告警计算。
[0075]
【延时规则】根据t时间内的趋势走向，预测qps/rt即将超过[变量y]值，当接收到流量数据后，根据时间设置[变量t]，发布一个延时计算任务。当延时计算任务触发时，从influxdb中查询[变量t]时间内的所有历史数据，利用预测算法和历史数据，计算出预测值，如果预测值大于阈值[变量y]，则触发告警；否则结束本次告警计算。
[0076]
根据历史的一段数据来预测未来的结果，结果为固定的几类如上面第一个判断会不会爆异常这种为分类问题常见算法是k近邻、朴素贝叶斯、决策树和逻辑回归。预测未来结果是连续的数值如第二个算趋势的属于回归问题，常见算法是线性回归和岭回归，以线性回归算法为例，都是根据输入变量调用算法的api得出来一个一个结果公式如：其中，w表示权重，x表示具体值 b:偏置项；以本发明的场景举例：设：30分钟到1小时内的流量数据权重为0.2，10分钟到30分钟内的流量数据权重为0.3，10分钟内的权重为0.5；偏置项为0；再将流量数据值（qps或者rt）和权重带入公式即可。
[0077]
还包括一种阈值优化算法和ai智能定位算法，当触发告警后，会首先执行阈值优化算法进行一次计算，以期望降低误告的概率，阈值优化算法首先会根据本次流量的响应时间进行一次基本判断，若响应时间小于1s，则直接使用最新的值替换掉原阈值。若大于1s，则通过近三周的历史数据，并根据quantile算法，计算出p99的值，如果p99值大于本次告警的值，则直接使用p99值替换掉原阈值；如果p99值小于等于本次告警的值，则继续触发告警。ai智能定位算法，利用所有可用的度量系统的数据和历史异常定位结果，利用如梯度下降法（wi 1 = wi
‑ꢀ
di
·
ηi, i=0,1,
…ꢀ
wi表示权值，参数η是学习速率，di表示损失函数total_loss对应于权值i的梯度）进行模型训练，每当确定需要发送告警消息时，利用此模型计算出可能的异常原因。
[0078]
还包括一种告警消息通知和降噪算法，经过发明人对历史异常的研究和经验发现，99%的异常都是持续的。比如某个接口的响应时间原本只有30ms，出现异常后直接激增到3s，那么在异常被修复之前，此接口的响应时间会一直持续在3s左右波动。那么如果每一次请求都触发告警的话，会形成信息轰炸，干扰到问题的定位；如果告警一次后便不再告警，也会出现疏漏或者不知道是否已经解决的情况。故本发明提供了一种告警消息降噪计算方法，包括：设置告警规则时，可以勾选是否降噪（不降噪表示每次异常都告警），并且设置接口的重要性（优先级）。重要性表示接口的重要程度，并决定了初始降噪时间间隔。可选的重要性选项包括：1.核心接口；2.重要接口；3.正常接口；4.辅助接口。所述核心接口表示：此接口非常重要，如果出问题整个系统将会崩溃；故设置成此类型的接口，每1分钟就告警一次。所述重要接口表示：此接口重要，如果出现问题，某些模块将不可用，但不影响其他模块的运行，故设置成此类型的接口，每5分钟告警一次，当连续告警10次后，系统会自动升级重要性为核心接口。所述正常接口表示：此接口为单一功能，如果出现问题仅仅影响一个功能。故设置成此类型的接口，每10分钟告警一次，当连续告警10次后，系统会自动升级重要性为重要接口。所述辅助接口表示：此接口即使出现了问题，用户也不会发现、不影响体验或者不会引起用户反感，此类接口告警一次后1小时内均不会再告警，当连续告警8次后，系统会自动升级重要性为正常接口。同时，系统的管理人可以自由选择使用邮箱、企业微信还是短信进行告警消息触达，从侧面提高了告警消息的触达率。
[0079]
还包括一种基于流量数据的告警计算流程，包含以下步骤：当用户访问某些功能时，通过埋点的方式，异步将流量信息汇总到告警系统的数据库，步骤具体为：c端用户访问某个功能时，会使用http等协议给服务器发送请求，当请求进入到web服务器后，使用埋点的方式，将数据存储在服务器内存中；当请求经过web服务器的运算，得到运算结果后，在通过协议将运算结果返回前，将本次请求的响应时间也存储在服务器内存中；同时每一台web服务器都在后台启用一个线程，此线程每1秒将当前内存中的所有数据汇总后，丢入到kafka消息中间件中；告警系统通过监听kafka消息，将相同应用、相同接口、同一秒中的数据汇总计算，得到总请求数、总响应时间和平均响应时间，然后将计算后的数据存入influxdb时序数据库中，以备后续使用。
[0080]
按照设置的规则，聚合计算每一条流量数据，是否符合告警条件步骤具体为：首先根据应用和接口，查询到配置的所有告警阈值规则；然后以秒为维度，查询出请求数和响应时间等数据；最后将规则集合和数据传递给规则运算引擎，得到规则命中结果；如果没有命中的规则则表示不需要告警；如果有命中的规则，则表示达到了阈值，可能需要做告警。
[0081]
若可能需要告警，可能是告警阈值不合理的误报，故调用阈值弹性计算模块校验/重新设置阈值。所述阈值弹性计算模块具体步骤为：(1)根据应用 接口维度，查询历史一个月内的历史流量数据。
[0082]
(2)判断qps/rt是否符合历史规律。
[0083]
(3)如果符合规律，则将今天的数据代入阈值计算算法，计算出最新的阈值并重新设置阈值，结束本次告警运算。
[0084]
(4)如果不符合规律，则表示是异常情况，继续向下执行告警流程。
[0085]
若确认是异常情况，则调用异常定位模块算法，根据请求链路、日志输出内容、硬件资源负载情况等信息，通过ai模型训练的算法，给出本次异常可能的原因。所述异常定位模块具体步骤为：(1)根据应用 接口 时间（秒）维度，调用调用链系统（如skywalking）的开放接口，查询出当前秒内的所有调用，再依次分析出明显超时的操作，如redis操作超时、mysql操作超时、远程调用超时等所有可能有异常的节点和耗时。
[0086]
(2)根据应用维度，调用日志采集系统（如elk）的开放接口，查询出所有异常日志，再依次根据异常日志类型、描述，调用公司知识库接口，利用机器学习ai算法，计算出每个异常的详细解释、可能的原因以及解决方法。
[0087]
(3)根据应用维度，查询本应用依赖的所有硬件资源地址，然后依次根据时间（秒）维度调用公司硬件监控系统（如prometheus）的开放接口，查询应用所在机器当时的硬件负载情况，判定硬件是否有如cpu负载过高、内存撑满、连接数过高等异常。并根据异常情况给出增加机器、增加内存、调整连接数最大限制等j9九游会真人的解决方案。
[0088]
(4)将上述1、2、3步所得到的所有异常分析结果和j9九游会真人的解决方案汇总并去重。得到一个所有可能原因的列表。
[0089]
利用企业微信、微信公众号、邮箱、短信等方式，给接口负责人发送告警信息。步骤具体为：(1)负责人预先登录告警系统，选择自己负责的应用，选择并设置告警方式。
[0090]
(2)当触发告警时，系统会根据所属应用查询到负责人和告警方式。然后组织文案
后通过设置的告警方式发出告警消息。
[0091]
以下为消息的模板示例：策略大师服务/search/stock接口，盘中的qps高于3000、1分钟内30% 的响应时间超过300ms，可能的原因：1.redis负载过高，可检查是否存在大key查询的场景。或增加redis实例的硬件配置；2.远程调用微信获取access_token接口响应过慢，建议适当增加缓存。
[0092]
qps数值明显高于历史数据，可能是前端不断重试请求导致，建议检查。
[0093]
作为一种具体的实施例，在一家大型电商网站中，公司使用了基于流量数据的告警系统进行服务监控和维护，具体如下：1. 阈值配置：服务负责人根据商品搜索接口的重要性，配置了请求次数和响应时间的阈值。例如，设置在任何一个60秒的滑动窗口内，如果请求次数超过2000次，或者平均响应时间超过500ms，则触发告警。
[0094]
2. 流量数据收集：在商品搜索接口中，每当用户发起一个搜索请求，系统都会记录请求时间、响应时间等信息，并异步将这些流量数据汇总到告警系统的数据库中。
[0095]
3. 实时告警处理：告警系统实时监控收集的流量数据，发现某个60秒的滑动窗口内，搜索接口的请求次数超过了2000次，触发了告警。
[0096]
4. 阈值弹性计算：触发告警后，系统调用阈值弹性计算模块，校验并重新设置阈值。经过分析发现，由于正值活动高峰期，请求次数的增加符合预期，因此系统自动调整了阈值，避免了误报。
[0097]
5. 异常定位：当告警系统在后续的流量数据中再次触发告警，系统确认了异常状态，随即调用异常定位模块。通过分析请求链路、日志和硬件负载等信息，系统定位到了一个数据库查询操作的响应时间过长。
[0098]
6. 告警通知与降噪：告警系统通过企业微信向服务负责人发送告警信息，同时系统记录了这次告警，如果在短时间内同样的告警再次触发，系统会降低告警频率，避免干扰服务负责人。
[0099]
总的来说，基于流量数据的告警系统准确地捕捉到了异常情况，并及时通知了服务负责人，使其能够迅速地定位问题并采取措施，保障了服务的稳定运行。
[0100]
上述具体实施方式仅仅对本发明的优选实施方式进行描述，而并非对本发明的保护范围进行限定。在不脱离本发明设计构思和精神范畴的前提下，本领域的普通技术人员根据本发明所提供的文字描述、附图对本发明的技术方案所作出的各种变形、替代和改进，均应属于本发明的保护范畴。本发明的保护范围由权利要求确定。