潘陈益-从数据到告警的全流程优化与探索

从数据到告警的全流程优化与探索 潘陈益国泰君安数据中心/算法工程师 潘陈益 国泰君安证券数据中心算法工程师 从互联网到证券，深耕运维数据和算法应用，擅长将理论实践结合，有效解决实际问题 01整 体 介 绍 02数 据 服 务 能 力 建 设 03异 常 感 知 到 处 置 的 算 法 全 面 强 化 04“大 模 型+ ”创 新 探 索 05总 结 与 展 望 整体介绍 国泰君安智能运维发展历程 PART 02 数据服务能力建设 实现统一数据管理底座，夯实各类场景应用的数据支撑能力 技术手段保障 体系梳理建立 建立统一的、具有证券行业特性的运维指标体系，从而更准确的量化展现系统运行状态及业务价值，为数据分析、智能运维场景等提供基础条件。 通过技术手段实现指标模型管理、质量管理、计算任务管理、血缘管理，保障指标体系的动态更新和持续运营。 构建统一数据开发平台，实现敏捷数据交付与一站式开发服务能力 PART 03 异常感知到处置的算法全面强化 整体概览 指标日志异常检测算法简述 指 标 异 常 检 测 检测合理范围内的突变 通对时间间隔固定、具有⼀定时序特征或者周期特征的时序数据进行检测，识别出反常的异常点。 不受历史数据中异常干扰 日 志 异 常 检 测 通过日志的相似性进行聚类，对日志模板的频率变化进行检测，将未匹配日志及频率改变的日志进行告警提示。 单指标异常检测优化 算法异常≠实际异常 算法判定的异常有时是因为短暂的突变、频繁的突变、偏离基带距离较少等导致，不影响业务，无需告警。 算法强化 优化描述：指标异常检测告警过滤 过滤后告警量 优化目标： 准确率：94% 对产生告警的指标重新提取时序特征，通过历史相似性检验、趋势性检验、同环比检验等方式二次确认是否异常。 召回率：93% 日志异常检测优化一 算法异常≠实际异常 *大量无效告警干扰；*在提升平台可靠性同时，增加了人力运营成本。 算法强化 优化描述：日志异常检测告警有效性识别 优化目标： 通过对历史标注告警的学习，判断新生成的告警是否有效。 日志异常检测优化二 日志复杂->误报与性能问题 *日志大量kv内容会导致模式和变量识别不准确，模式数量增加；*性能问题导致告警延迟；*误报增加，带来运维风险。 算法强化 优化描述： 日志模式识别算法增强与异常检测模型调优 优化目标： 通过优化日志模式识别提高日志异常检测准确率，同时通过异常检测模型优化提高检测时效性 多指标——基于数字孪生模型的多指标观测 多指标——基于FluxRank的多指标关联分析 根因定位——基于数据立方模型的多维度观测 根因定位——多系统多链路观测 告警——统一告警管理+智能告警分析 PART 04 “大模型+”创新探索 基于告警知识库的告警处理方法问答 我收到了一条如下告警:\ntopic='datalake-kafka-xxxx'的消费组new_2ef35f-test中有1/3个partition的lag大于40万, lag范围: 1001 - 169万;各partion消费lag: 0=169万,1=1001,2=1001\n请告诉我应该怎么处理 请求返回 似乎没有完全匹配上应急手册中告警处理方案？？ 根据已知信息，这是一个关于Kafka消费组Lag告警的问题。告警内容显示，某个主题的消费组中有1/3个partition的Lag大于40万，Lag范围为1001-169万，各partition消费Lag分别为0=169万，1=1001，2=1001。\n\n根据应急手册，xx系统自监控已经完善了自监控，包括数据采集以及告警短信配置。如果收到短信告警，可以根据以下步骤进行处理：\n\n1.消费组LAG告警处理：根据告警内容，可以得知这是关于消费组LAG的告警。根据已知信息，可以尝试重启相关任务以解决。\n\n2.告警内容解析：根据告警内容，可以得知这是关于某个主题的消费组中有1/3个partition的Lag大于40万的问题。此时，需要检查该消费组是否配置了正确的LAG阈值以及告警规则，确保它们能够正常工作。\n\n3.LAG范围问题：根据告警信息，可以得知LAG范围为1001-169万。如果您的Kafka集群中有大量的partition，可能需要调整LAG阈值以避免告警。您可以查看Kafka集群的配置，并尝试增加阈值或减少partition的数量。\n\n4.解决方法：根据以上分析，您可以尝试以下方法来解决该问题：\n\na.检查Kafka集群的配置，确保LAG阈值和告警规则正确设置。\n\nb.如果您的Kafka集群中有大量的partition，可以尝试增加LAG阈值或减少partition的数量。\n\nc.检查主题的配置，确保它能够正确地设置LAG阈值和告警规则。\n\nd.如果以上方法都不能解决问题，您可以尝试查看Kafka集群的日志，以了解更多信息。 基于告警知识库的告警处理方法问答 "告警":"【严重】部署机器: 10.xx.xx.xx 2024-02-01 11:23:00+08:00 cpu使用率85.6%超过80%","处理方法":"查看CPU占用过高任务，考虑是否迁移"} 告警知识库示例 "告警":"topic='msg_test'的消费组new_1_49-test中有4/6个partition的lag大于40万, lag范围: 4525 - 111万;各partion消费lag: 0=52万,1=111万,2=1万,3=4525,4=92万,5=59万", "处理方法":"以上告警为简单阈值告警配置后发出的，每分钟检测一次，若超过阈值100万就会发送一条告警。可能会有两种情况•总的lag值在持续不断增大，持续时间超过半小时。这种情况下则很有可能任务异常了，可以采用重启任务的方法解决•总的lag值在9点半流量高峰的时候告警，也有持续告警，但是在几分钟后，总的lag值开始持续下降。此种情况不用处理，应该是正常的流量高峰导致的。"} 规范文档手动分割 {'msg': '查询成功','code': 'success','data': {'question': "topic='datalake-kafka-xxxx'的消费组new_2ef35f-test中有1/3个partition的lag大于40万, lag范围:1001 - 169万;各partion消费lag: 0=169万,1=1001,2=1001",'answer': '根据相似告警及处理方法，用户问题对应的处理方法如下：\n\n**上述告警为简单阈值告警配置后发出的，每分钟检测一次，若超过阈值100万就会发送一条告警。**\n\n由于用户问题的lag值为169万，属于简单阈值告警，因此处理方法为：\n\n**当总的lag值持续不断增大，持续时间超过半小时，或总的lag值在9点半流量高峰的时候告警，但持续告警，在几分钟后，总的lag值开始持续下降，这种情况正常，无需处理。**'}}请求返回 总结与展望 大模型探索 chatops与告警中心 基于知识库文档，以告警信息作为触发，实现基于大模型的告警智能化流程 特征提取 知识生成 通过对非结构化数据进行特征提取，结合大模型工具编排能力，提供告警分析服务，通过告警语义解析自动展示告警关联的日志原文、CMDB信息、服务治理信息查询等 基于大模型自然语言理解与生成技术，结合用户输入需求，实现运维知识生成、运维脚本自动生成及补全等能力。 智能运维算法治理 ——《算法之美》 高效运维社区DevOps时代 荣誉出品 感谢大家观看