一种日志监控处理方法、装置、设备及存储介质制造方法及图纸

本申请公开了一种日志监控处理方法、装置、设备及存储介质，基于大数据技术与智能算法能够实现多源离散日志的统一采集、处理，能够做到自动采集，自动上传，回捞日志，实现了日志统一采集，自动上报，记录关键帧，关键埋点以及相应的上下文信息，帮助开发人员、运维人员更方便的解决移动端APP存在的问题，且分析移动端APP运营数据，解决了难以收集需要的错误信息，且在应用没有集成日志收集框架的时候，需要用户配合才能获取操作信息，无法快速定位bug的技术问题。bug的技术问题。bug的技术问题。

【技术实现步骤摘要】
一种日志监控处理方法、装置、设备及存储介质


[0001]本申请涉及金融科技
，尤其涉及一种日志监控处理方法、装置、设备及存储介质。

技术介绍

[0002]在开发移动端应用的时候，总会遇到各种各样的bug。如果是本地发现的bug，可以经过本地IDE调试，通过报错的堆栈和报错信息来定位问题所在。但是生产环境线上出现问题，就很难定位问题所在。
[0003]一般来讲，我们可以通过一些其他的错误上报系统，比如腾讯的Bugly，来收集错误提示信息。但是很多时候，Bugly上报的错误并不能正确的把我们需要的错误信息反馈给我们，或者说，我们无法定位bug真正出现的时机点，用户之前的操作是什么。甚至有时候Bugly上报的堆栈信息是错误的时间节点，这让我们定位bug发生真正时机很困难。
[0004]在银行金融系统中，一旦出现bug，可能会导致用户的资金遭受损失，极大地降低了用户的体验性，且移动端应用的用户量庞大，若无法及时发现问题，后果比较严重。
[0005]在应用没有集成日志收集框架的时候，当线上出现问题的时候，客服需要联系到这个用户，争取获得用户的配合。通过发送私包给用户，由用户安装后，重现刚才的bug，才能把操作日志写入App的错误日志中，让用户通过交流软件发给我们。这个过程反复沟通的时间成本无法估量，也存在用户的信息遗漏或缺失。随着业务的不断扩张，业务复杂度不断加深，这种传统的方式显然不能够满足各个开发同学的需要，也无法快速定位问题。

技术实现思路

[0006]本申请提供了一种日志监控处理方法、装置、设备及存储介质，解决了难以收集需要的错误信息，且在应用没有集成日志收集框架的时候，需要用户配合才能获取操作信息，无法快速定位bug的技术问题。
[0007]有鉴于此，本申请第一方面提供了一种日志监控处理方法，所述方法包括：
[0008]S1、通过预设埋点，基于日志采集器filebeat获取第一日志信息；
[0009]S2、响应于当检测到有crash时触发的日志拉取指令，获取crash对应的第二日志信息；
[0010]S3、对所述第一日志信息以及所述第二日志信息进行过滤清洗，得到第三日志信息；
[0011]S4、将所述第三日志信息存储于数据库中，并在所述数据库中建立索引；
[0012]S5、通过kibana对所述数据库中的所述第三日志信息进行分析，并可视化分析结果。
[0013]可选地，所述步骤S1具体包括：
[0014]根据业务需求确定预设埋点，所述预设埋点包括用户的页面访问情况、点击事件、停留时间以及错误信息；
[0015]基于日志采集器filebeat获取所述预设埋点上报的第一日志信息，所述第一日志信息为JSON格式。
[0016]可选地，所述步骤S2具体包括：
[0017]当检测到有crash时，基于PLCrashReporter收集发生crash时的堆栈信息；
[0018]响应于开发基于所述堆栈信息确定的日志拉取指令，获取crash对应的第二日志信息。
[0019]可选地，所述步骤S3具体包括：
[0020]通过logstash对所述第一日志信息以及所述第二日志信息进行过滤清洗，将所述第一日志信息以及所述第二日志信息中的数据格式统一为目标格式，并过滤所述一日志信息以及所述第二日志信息中的无效信息。
[0021]可选地，所述步骤S5中可视化分析结果具体包括：
[0022]基于仪表盘展示实时和历史的指标和数据；
[0023]将所述第三日志信息转化为图表或表格进行可视化；
[0024]对实时和历史的所述第三日志信息进行数据统计可视化。
[0025]可选地，还包括：
[0026]根据对所述第三日志信息的分析结果，进行报警和通知。
[0027]可选地，还包括：
[0028]通过kibana响应于日志搜索指令，从所述数据库中查询对应的第三日志信息。
[0029]本申请第二方面提供一种日志监控处理装置，所述装置包括：
[0030]第一获取单元，用于通过预设埋点，基于日志采集器filebeat获取第一日志信息；
[0031]第二获取单元，用于响应于当检测到有crash时触发的日志拉取指令，获取crash对应的第二日志信息；
[0032]过滤单元，用于对所述第一日志信息以及所述第二日志信息进行过滤清洗，得到第三日志信息；
[0033]存储单元，用于将所述第三日志信息存储于数据库中，并在所述数据库中建立索引；
[0034]可视化单元，用于通过kibana对所述数据库中的所述第三日志信息进行分析，并可视化分析结果。
[0035]本申请第三方面提供一种日志监控处理设备，所述设备包括处理器以及存储器：
[0036]所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；
[0037]所述处理器用于根据所述程序代码中的指令，执行如上述第一方面所述的日志监控处理方法的步骤。
[0038]本申请第四方面提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行上述第一方面所述的日志监控处理方法的步骤。
[0039]从以上技术方案可以看出，本申请实施例具有以下优点：
[0040]本申请中，提供了一种日志监控处理方法、装置、设备及存储介质，基于大数据技术与智能算法能够实现多源离散日志的统一采集、处理，能够做到自动采集，自动上传，回捞日志，实现了日志统一采集，自动上报，记录关键帧，关键埋点以及相应的上下文信息，帮助开发人员、运维人员更方便的解决移动端APP存在的问题，且分析移动端APP运营数据，解
决了难以收集需要的错误信息，且在应用没有集成日志收集框架的时候，需要用户配合才能获取操作信息，无法快速定位bug的技术问题。
附图说明
[0041]图1为本申请实施例中日志监控处理方法的方法流程图；
[0042]图2为本申请实施例中日志监控处理装置的结构示意图；
[0043]图3为本申请实施例中日志监控处理设备的结构示意图。
具体实施方式
[0044]为了使本
的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0045]本申请设计了一种日志监控处理方法、装置、设备及存储介质，解决了难以收集需要的错误信息，且在应用没有集成日志收集框架的时候，需要用户配合才能获取操作信息，无法快速定位bug的技术问题。
[0046]为了便于理解，请参阅图1，图1为本申请实施例中日志监控处理方法的方法流程图，如图1所示，具体为：
[0047]S1、通过预本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种日志监控处理方法，其特征在于，包括：S1、通过预设埋点，基于日志采集器filebeat获取第一日志信息；S2、响应于当检测到有crash时触发的日志拉取指令，获取crash对应的第二日志信息；S3、对所述第一日志信息以及所述第二日志信息进行过滤清洗，得到第三日志信息；S4、将所述第三日志信息存储于数据库中，并在所述数据库中建立索引；S5、通过kibana对所述数据库中的所述第三日志信息进行分析，并可视化分析结果。2.根据权利要求1所述的日志监控处理方法，其特征在于，所述步骤S1具体包括：根据业务需求确定预设埋点，所述预设埋点包括用户的页面访问情况、点击事件、停留时间以及错误信息；基于日志采集器filebeat获取所述预设埋点上报的第一日志信息，所述第一日志信息为JSON格式。3.根据权利要求1所述的日志监控处理方法，其特征在于，所述步骤S2具体包括：当检测到有crash时，基于PLCrashReporter收集发生crash时的堆栈信息；响应于开发基于所述堆栈信息确定的日志拉取指令，获取crash对应的第二日志信息。4.根据权利要求1所述的日志监控处理方法，其特征在于，所述步骤S3具体包括：通过logstash对所述第一日志信息以及所述第二日志信息进行过滤清洗，将所述第一日志信息以及所述第二日志信息中的数据格式统一为目标格式，并过滤所述一日志信息以及所述第二日志信息中的无效信息。5.根据权利要求1所述的日志监控处理方法，其特征在于，所述步骤S5中可视化分析结果具体包括：基...

【专利技术属性】
技术研发人员：耿彭彭，
申请(专利权)人：平安银行股份有限公司，
类型：发明
国别省市：