大模型在日志运维场景的应用实践-2023 饶琛琳

分享主题大模型在日志运维场景的应用实践饶

琛

琳

日

志

易

产

品

副

总

裁截屏扫码，领取网络研讨会资料合集(含本期)行业报告资源群免责申明：本内容非原报告内容;1.

进群福利：进群即领万份行业研究、管理方案及其他学习资源，直接打包下载报告来源互联网公开数据；如侵权请联系客服微信，第一时间清理；2.

每日分享：6+份行研精选、3个行业主题3.

报告查找：群里直接咨询，免费协助查找4.

严禁广告：仅限行业报告交流，禁止一切无关信息报告仅限社群个人学习，如需它用请联系版权方；如有其他疑问请联系微信。微信扫码长期有效知识星球行业与管理资源专业知识社群：每月分享8000+份行业研究报告、商业计划、市场研究、企业运营及咨询管理方案等，涵盖科技、金融、教育、互联网、房地产、生物制药、医疗健康等；已成为投资、产业研究、企业运营、价值传播等工作助手。微信扫码行研无忧目录Contents01.

02.

03.大模型在日志场景的应用方向实践运用大模型的路径大模型在金融企业应用案例更快捷的分析海量日志更智能的解读和预测故障理想vs现实：估算资源构建高质量的训练数据模型的评估和迭代优化产品设计“扬长避短”背景：某金融企业大量业务日志难点：关键字复杂多变方案：实现知识库增强的自然语言查询效果：故障排查时间缩短40%01大模型在日志场景的应用方向Ø

更快捷的分析海量日志Ø

更智能的解读和预测故障Ø

理想vs现实：估算资源谷歌Sec-PaLM的日志概要效果日志问答方案(1)：超大窗口问题1：窗口不会无限大，日志却无限多。问题2：对于长文本中部的内容，LLM不太敏感。日志问答方案(2)：AgentChain问题1：运维知识理解的要求较高问题2：agent/functioncall能力要求较高日志问答方案(3)：模式提问+分段选择资源消耗估算场景看起来很美好，但实际部署时存在一定成本压力。我们进行了一些简单的资源估算:•

1000条SSH日志大概包含5-6万个tokens。对于这个长度，LLM推理速度较慢，需要10多秒。•

使用最新的Yi-6b-200k模型测试，24GB显存仅能处理约3ktokens，相当于50行日志。•

按ChatGLM规模预估,80G显存的单卡最多只能处理200行SSH日志。•

并行计算时，8块80G卡也只能同时处理约1600行。结论:•

直接进行日志问答，在理论上可行，但算力需求巨大。•

该方案实际成本过高，目前的硬件条件难以支撑实际应用。•

生成和调用现有分析工具相对更现实。02实践运用大模型的路径Ø

构建高质量的训练数据Ø

模型的评估和迭代优化Ø

产品设计“扬长避短”Text2SPL场景介绍/背景•TexttoSQL任务是NLP领域的经典课题之一。常见的数据集有：••SPL对比SQL的差异：没有预知的tableschema。要自行判断

prompt里哪些名词疑似字段名。无法直接套用ChatGPT，SPL目前只是概念通用，语法层无标准：•

WikiSQL，维基百科数据集主要是单表查询，语句比较简单。•

Spider，数据集包含join等多表和嵌套，语句比较复杂。在seq2seq之前，模板技术一般评分20+；bert/T5之前，一般评分60+；ChatGPT将评分提升到

85+。•日志易

SPL语法和splunk/kusto/esql/ppl/humio有差别。•日志易内置字段也和CIM/ECS有差别。•

CoSQL，在Spider的基础上添加了模糊语义多轮对话。目前评分在50+。•

BIRD：新一代数据集，不光考虑表结构，还要考虑脏数据、执行效率。目前ChatGPT评分为

40。通用大模型的表现(1)：GPT对比T5的飞跃自然语言提问splunk-google-t5ChatGPTsearchforthetermserror,failfailure,failed,orsevereintheeventsthatalsomentionbuttercupgamesindex=_internalfail*not[searchindex=_internalerror,fail*errorsearch(errorORfailORfailureORfailedORsevere)ANDbuttercupgamessearchthesourcetypefieldforanyvaluesthatbeginwithaccess_,status200,andaction"purchase".usethechartcommandtocountthenumberofpurchases.thesearchspecifiesthepurchasesmadeforeachproductbyusingcategoryId.Thedifferenceisthatthecountofpurchasesisnowanargumentofthesparkline()function.index=access_*status=200action=purchase|chartcount(price)就这一条是可以直接运行的，还和期望输出有差距searchsourcetype="access_*"status=200action="purchase"|chartcount(action)bycategoryId|evalpurchases=sparkline(count)就这一条是不能直接用的。两次追加提示后改对：searchsourcetype="access_*"status=200action="purchase"|chartsparkline(count(action))bycategoryIdsearchthesourcetypefieldforanyvaluesthatbeginwithaccess_,geteventswithstatus200,andaction"purchase".thencomputethemostcommoncategoryIdvalues.sourcetype=access_*status=200actionpurchase|topcategoryIdsearchsourcetype="access_*"status=200action="purchase"|topcategoryIdsearchthesourcetypefieldforanyvaluesthatbeginwithaccess_,geteventswithstatus200,andaction"purchase".thencomputetheonemostcommonclientip.sourcetype=access_*status=200actionpurchase|topclientipsearchsourcetype="access_*"status=200action="purchase"|top1clientipsearchthesourcetypefieldforanyvaluesthatbeginwithaccess_,thegetpriceas"Price"byproductName,thenrenameproductNamecolumnas"ProductName"sourcetype=access_.|statsvalues(price)aspricebyproductName|searchsourcetype="access_*"|evalPrice=price|statsvalues(Price)byproductName|renameproductNameas"ProductName"两次追加提示后改的更高效，并且能记住：searchsourcetype="access_*"|statsvalues(price)asPricebyproductName|renameproductNameas"ProductName"通用大模型的表现(2)：提示工程不是万能的问题

1：基础模型较差时，复杂逻辑完全无法处理问题

2：模型的预训练知识在细节处有严重干扰训练数据筹备(1)：内外网数据搜集原始数据来源n

指令说明文档n

手动编写，含多轮对话n

内部应用配置：图表标题及SPL语句n

github上公开的常用日志关键字n

github上公开的es/splunk/kusto安全分析规则训练数据筹备(2)：问答类数据增强ChatGPT⾃⽣成n

alpaca式的

self_instruct方案：通过

GPT-3.5接口，自动生成部分微调数据。n

添加

prompt声明圈定问答范围：ActasaSplunkExperttowriteSPL。n

然后人工复核，调整数据。训练数据筹备(3)：丰富提问方式StarChat⻆⾊扮演n

starcoder是开源

LLM中编码能力最强的。实验发现他甚至能给出具体的

splunk文档

url。n

通过

A/B角色扮演，让

starcoder说出对应

SPL语句的提问。n

效果一般，清洗后去掉了三分之二的数据。训练数据筹备(4)：加入其他产品知识⽂档⾃问答n

利用

pandoc工具将

word文档转为

markdown纯文本。n

来自北交大

transGPT交通大模型的LLMforDialogDataGenerate方法，基于文本生成问答。模型的评估与迭代•

尝试不同基础模型的效果：•

baichuan2的loss长期不收敛•

尝试不同数据配比的效果：•

1:2>1:5>1:1•

尝试构建除文本匹配以外的验证方案：•

引入SPLparserAPI语法校验•

对比索引实际响应内容•

有趣的是：和Splunk得到了相似的结论。扬长避短的产品设计••浏览器插件形式：兼容全部主产品版本、独立迭代锚定搜索页：获取数据集、字段列表等即时知识敏感数据拦截：注重数据安全，避免个人隐私外发•03大模型在金融企业应用案例Ø

背景：金融企业大量业务日志Ø

难点：关键字复杂多变Ø

方案：实现知识库增强的自然语言查询Ø

效果：故障排查时间缩短40%案例背景③.

找到返回码了，②.

业务系统上千个返回码，人只记得住最常见的10来个。其他的中文含义对应啥返回码？不过你问的是什么错误提示呢？①.

金融企业通常有200-600个业务系统，口头叫法大同小异，但开发商输出到日志里，实际用的是什么标识符？ChatSPL效果ChatSPL客户收益•

在“争分夺秒”的故障定位过程中，相比复杂的向量数据库召回方案，ChatSPL场景设计简单易行。查找错误类的用时下降

40%。•

业务线运维均可通过

ChatSPL

进行关键字查询、分组统计、趋势分析，极大的解放了维护平台的高级运维人员。将人力投入到可观测性等高阶能力建设中。未来展望•

后续版本的功能计划•

英文版本•

查询结果可视化•

针对日志/告警的解读•

主动推荐可选提问：5W1H•

针对日志生成grok正则•

期待开源大模型的成长！！行业报告资源群免责申明：本内容非原报告内容;1.

进群福利：进群即领万份行业研究、管理方案及其他学习资源，直接打包下载报告来源互联网公开数据；如侵权请联系客