一种车载娱乐终端控制器卡顿监测及预警方法与流程

文档序号:29498261发布日期:2022-04-06 16:20阅读:147来源:国知局
一种车载娱乐终端控制器卡顿监测及预警方法与流程

1.本发明涉及车载娱乐控制终端技术领域,具体涉及一种车载娱乐终端控制器卡顿监测及预警方法。


背景技术:

2.随着汽车智能化的不断发展,智能座舱将成为其中的业务核心,而车载娱乐控制终端(车机)作为智能座舱的核心,它的运行状态直接决定客户对车辆智能座舱的满意水平。
3.传统的车载娱乐控制终端发生卡顿后,无法快速将车载娱乐控制终端各程序运行状态(cpu和内存使用率)返回主机厂及时进行分析。只有派技术人员联系用户进行分析,但此时很难复现异常情况出现时用户的使用场景,且车机日志因存储空间有限,写入采取滚动写入循环覆盖的方式,这样异常情况日志易被覆盖,这样收集的信息片面导致无法清楚了解各型车机及其上各子程序的运行情况,也无法有效、快速和完整解决车机卡顿问题,降低了用户的满意度,也影响主机厂的声誉,严重甚者将会进行产品召回或扼杀该车型在市场的正常销售。
4.因此,如何及时、准确和全面获取车机卡顿时各程序的cpu和内存资源占用情况,并对异常程序进行实时监控和对占用资源大的程序进行统计计算,然后整改和调优,以便迅速解决车机卡顿故障问题。


技术实现要素:

5.针对现有技术存在的上述不足,本发明的目的在于提供一种车载娱乐终端控制器卡顿监测及预警方法,解决了现有技术中不能及时、准确的获取车载娱乐终端的卡顿的监测和预警的问题。
6.为实现上述目的,本发明所提供的技术方案是:一种车载娱乐终端控制器卡顿监测及预警方法,其特征在于,包括如下步骤:s1:日志创建,将终端控制器进程cpu和内存使用率写入本地日志,建立日志埋点程序,周期性采集终端控制器各进程cpu和内存使用率;s2:日志上云,云平台拉取终端控制器日志,并存储至分布式文件存储系统中;s3:日志解析,建立解析模型,将终端控制器日志内非结构化数据转化为结构化数据并储存在分布式文件存储系统中;s4:日志计算,建立监测规则模型,读取步骤s3中解析的结构化数据,根据监测规则得出监测的结果数据并储存;s5:日志查询及展示,建立查询展示模型,查询步骤s4中得到的结果数据并根据前端要求的数据结构和约定形式返回给前端,前台将查询的数据展示,最后,工作人员根据展示的数据进行监测及预警。
7.进一步地,所述步骤s1中,当终端控制器为安卓系统时,通过终端控制器的安卓系
统自带的top命令直接读取总的进程cpu和内存占用率、cpu占用率top5的进程情况,然后周期性读取上述数据并写入log.info日志文件并储存。
8.进一步地,所述log.info日志文件超过设定大小或超过存储时间或已上云,则采用先进先出方式进行清除log.info日志文件后再次写入。
9.进一步地,所述步骤s2中,云平台拉取终端控制器日志的方式包括主动拉取或手动拉取,其中,云平台向终端控制器发送读取终端控制器日志命令,当终端控制器收到日志读取命令后,将其终端控制器日志上传至云平台,云平台接收后再存储到分布式文件存储系统中。
10.进一步地,所述步骤s3中,采取java.io.bufferedreader中的readline方法逐行读取分布式文件存储系统储存的日志文件数据,并根据文档中每行数据得出对应的键值对结构,所述键值对结构包括终端控制器进程cpu总的占用率、终端控制器进程cpu总的空闲率、进程名和该进程cpu占比、内存占比日志数据,封装为一个对象按行写入分布式文件存储系统中的hive表中,其中每次读取对应hive中的每行,按读取次数逐行增加。
11.进一步地,所述步骤s4中,所述监测规则模型如下:s401:采用sql语言读取hive表中的键值对结构基础数据;s402:按照终端控制器指标计算规则进行监控、预警计算,其中,cpu总的空闲率低于预警设定值记为一次告警;单个进程cpu占比大于预警设定值记为一次告警;统计top进程权重分布,将这些数据写入mysql数据库中,按天进行统计计算。
12.进一步地,所述top进程权重分布计算方式为权重设置top1记为1、top2记为0.8、top3记为0.6、top4记为0.4、top5记为0.2,然后计算当日的各进程出现top排序的次数乘以对应的权重得出权值。
13.进一步地,所述步骤s5中,前端技术采用react+echarts框架及技术,后端采用springboot+mybatis框架及技术,后端按前端数据展示需求和mysql数据结构,查询出结果;前端再根据查询出的结果进行相应展示。
14.进一步地,步骤s5中展示内容包括根据选择日期、车型和软件版本查询异常车辆数、当日上传数据车辆数和当日异常次数的监控预警指标,及进程异常次数分布情况、top进程权重分布情况和告警详细信息数据。
15.相比现有技术,本发明具有如下有益效果:本发明通过车载娱乐终端控制器采集自身各个进程cpu和内存占比数据,并写入到日志文件,云平台再拉取车载娱乐终端控制器日志文件并对其中的数据进行统计计算,写入数据库;然后进行解析、计算后,通过前端进行展示,这样,工作人员即可按需查看车载娱乐终端控制器各个进程cpu运行和内存消耗情况,以达到监测车机卡顿监测和预警的效果,并根据监测和预警信息对相应车系相应软件版本对应进程进行整改优化,并及时通过ota对车机进行软件升级,提高用户的操作体验感。
附图说明
16.附图是用来提供对本发明的进一步理解,并且构成说明书的一部分,与下面的具体实施方式一起用于解释本发明,但并不构成对本发明的限制。在附图中:
图1是本发明的工作流程图。
17.图2是本发明中日志创建流程图。
18.图3是本发明中日志上云流程图。
19.图4是本发明中日志解析流程图。
20.图5是本发明中日志计算模块流程图。
21.图6是本发明中日志查询和展示流程图。
具体实施方式
22.下面通过具体实施方式进一步详细的说明:请参阅图1,本发明公开一种车载娱乐终端控制器(即车机或车机系统)卡顿监测及预警方法,包括如下步骤:s1:日志创建,将终端控制器进程cpu和内存使用率写入本地日志,建立日志埋点程序,周期性采集终端控制器各进程cpu和内存使用率。具体的,请参阅图2,当终端控制器为安卓系统时,因其建立在linux内核之上,因此可通过终端控制器的安卓系统自带的top命令直接读取总的进程cpu和内存占用率、cpu占用率top5的进程情况,以10秒为周期读取上述数据并写入log.info日志文件并储存。并且,当所述log.info日志文件超过指定大小或超过存储时间或已上云则采用先进先出方式进行清除后再次写入。
23.s2:日志上云,云平台(云端平台或车云平台)拉取终端控制器日志,并存储至hdfs分布式文件存储系统中。具体地,请参阅图3,所述云平台拉取终端控制器日志的方式包括主动拉取或手动拉取。其中,云平台和终端控制器建立4g网络连接,云平台向终端控制器发送读取终端控制器日志命令,该命令发送方式为自动读取或者手动读取,并能够设置自动读取的时间周期,例如,设定为每天读取一次。在自动读取时,如果终端控制器在线,将会直接接收到日志读取指令;如不在线,终端控制器将在启动联网建立好后,调用待执行指令查询接口,如有日志读取指令,亦会接收到日志读取指令。终端控制器接收指令后,立刻读取log.info日志文件的日志文件并进行文件上传,云平台接收成功后存储到云平台(私有云)上,具体为云平台建立的分布式文件存储系统的私有云cos中。
24.s3:日志解析,建立解析模型,将终端控制器日志内非结构化数据转化为结构化数据并储存在hdfs分布式文件存储系统中。具体地,请参阅图4,采取java.io.bufferedreader中的readline方法逐行读取分布式文件存储系统储存的日志文件,根据建立的解析模型规则解析日志文件,得到日志基础数据后进行存储,并根据文档中每行数据得出对应的键值对结构。所述键值对结构包括终端控制器进程cpu总的占用率、终端控制器进程cpu总的空闲率、进程名和该进程cpu占比、内存占比日志数据,封装为一个对象按行写入分布式文件存储系统中的hive表中,其中每次读取对应hive中的每行,按读取次数逐行增加。
25.s4:日志计算,建立监测规则模型,读取步骤s3中解析的结构化数据,根据监测规则得出监测的结果数据并储存。其中,请参阅图5,所述监测规则模型如下:s401:采用sql语言读取hive表中的键值对结构基础数据;s402:按照终端控制器指标计算规则进行监控、预警计算。
26.其中,cpu总的空闲率低于预警设定值记为一次告警;单个进程cpu占比大于预警
设定值记为一次告警;统计top进程权重分布,将这些数据写入mysql数据库中,按天进行统计计算。所述top进程权重分布计算方式为权重设置top1记为1、top2记为0.8、top3记为0.6、top4记为0.4、top5记为0.2,然后计算当日的各进程出现top排序的次数乘以对应的权重得出权值。
27.s5:日志查询及展示,建立查询展示模型,查询步骤s4中得到的结果数据并根据前端要求的数据结构和约定形式返回给前端,前台将查询的数据展示,最后,工作人员根据展示的数据进行监测及预警。具体地,请参阅图6,前端技术采用react+echarts框架及技术,后端采用springboot+mybatis框架及技术,后端按前端数据展示需求和mysql数据结构,查询出结果;前端再根据查询出的结果进行相应展示。展示内容包括根据选择日期、车型和软件版本查询异常车辆数、当日上传数据车辆数和当日异常次数的监控预警指标,及进程异常次数分布情况、top进程权重分布情况和告警详细信息数据。
28.最后,根据监测、预警信息对相应的终端控制器相应软件进程进行优化,通过ota进行升级。即,工作人员根据监测和预警信息对相应车系相应车机软件版本对应进程进行整改优化,并及时通过ota对车机进行软件升级。
29.根据上述说明书的揭示和教导,本发明所属领域的技术人员还可以对上述实施方式进行变更和修改。因此,本发明并不局限于上面揭示和描述的具体实施方式,对本发明的一些修改和变更也应当落入本发明的权利要求的保护范围内。此外,尽管本说明书中使用了一些特定的术语,但这些术语只是为了方便说明,并不对本发明构成任何限制,采用与其相同或相似的其它装置,均在本发明保护范围内。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1