CN110347571A - 一种崩溃日志采集方法、分析方法及相关装置 - Google Patents
一种崩溃日志采集方法、分析方法及相关装置 Download PDFInfo
- Publication number
- CN110347571A CN110347571A CN201910616028.0A CN201910616028A CN110347571A CN 110347571 A CN110347571 A CN 110347571A CN 201910616028 A CN201910616028 A CN 201910616028A CN 110347571 A CN110347571 A CN 110347571A
- Authority
- CN
- China
- Prior art keywords
- log
- kernel panic
- kernel
- server
- linux system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种崩溃日志采集方法，可以由linux系统设备在监测到内核崩溃时就将内核崩溃日志写入至非易失性存储空间pstore中，从而再次重启linux系统设备后，linux系统恢复功能，同时pstore中的内核崩溃日志也会保留，将内核崩溃日志上传至服务器，从而可以使开发人员通过服务器来获取到各个linux系统设备的内核崩溃日志，而无需现场通过串口线的方式获取，从而极大的方便了linux系统设备的崩溃日志的采集。本申请还提供一种linux系统设备、一种崩溃日志分析方法、服务器设备，以方便的获取到linux内核崩溃信息，同样可以实现上述效果。
Description
技术领域
本发明涉及linux内核异常分析领域，尤其涉及一种崩溃日志采集方法、 linux系统设备、一种崩溃日志分析方法、服务器设备。
背景技术
在linux系统中，当linux内核遇到错误或异常时，会将错误进程的堆栈信息、CPU寄存器信息等内核崩溃信息打印到串口以辅助开发人员定位和分析问题。
在linux系统设备的开发调试阶段，设备是以开发板的形式提供给研发人员使用，开发通常预留了串口线，开发人员可以通过串口线来连接设备的串口，当linux内核出现异常时，即可通过串口线获得串口记录的内核崩溃信息，从而读linux内核出现的异常进行分析。
当linux系统设备开发完毕后，会移除串口线并增加包装壳，当linux内核再出现异常时，使用串口线的方式进行内核崩溃信息的获取将会十分的不便。此外，采用串口线的方式进行内核崩溃信息的获取需要开发人员到达设备现场进行操作，而设备开发完毕后，可能会被分发到不同的地区，这将使得内核崩溃信息的获取更加不便。
因此，如何能够方便的获取到linux内核崩溃信息，是本领域技术人员亟待解决的问题。
发明内容
本发明的主要目的在于提供一种崩溃日志采集方法、linux系统设备、一种崩溃日志分析方法、服务器设备，以方便的获取到linux内核崩溃信息。
为实现上述目的，本发明提供的一种崩溃日志采集方法，所述方法包括：
一种崩溃日志采集方法，应用于linux系统设备，包括：
监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore；
所述设备重启后，从预先挂载的预设pstore的文件系统读取所述内核崩溃日志；
将所述内核崩溃日志通过网络上传至服务器，以通过服务器获取所有接收到的内核崩溃日志。
可选地，所述从预先挂载的预设pstore的文件系统读取所述内核崩溃日志之后，还包括：
将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志；
则所述将所述内核崩溃日志上传至服务器，包括：
从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器。
可选地，所述将所述内核崩溃日志保存至eMMC中，并删除所述pstore 中的所述内核崩溃日志之前，还包括：
将所述内核崩溃日志上传至服务器，判断所述内核崩溃日志是否上传成功；
若否，则执行所述将所述内核崩溃日志保存至eMMC中，并删除所述 pstore中的所述内核崩溃日志的步骤。
可选地，所述从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器之后，还包括：
判断所述内核崩溃日志是否上传成功；
若是，则删除所述eMMC中的所述内核崩溃日志。
可选地，所述方法还包括：
监测所述eMMC中的所述内核崩溃日志超出预设个数时，按照时间从近到远的顺序确定所述预设个数的保留内核崩溃日志，并删除所有非保留内核崩溃日志。
可选地，所述将所述内核崩溃日志上传至服务器，包括：
将所述内核崩溃日志与所述内核崩溃日志对应的验证数据上传至服务器，以使服务器进行验证分析。
可选地，所述验证数据包括：
从预先挂载的预设pstore的文件系统读取所述内核崩溃日志。
为实现上述目的，本申请还提供一种linux系统设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如任一项所述崩溃日志采集方法的步骤。
为实现上述目的，本申请还提供一种崩溃日志分析方法，应用于服务器，包括：
接收linux系统设备发送的内核崩溃日志；所述内核崩溃日志为linux系统设备监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取并保存于pstore，并从预先挂载的预设pstore的文件系统读取并上传至所述服务器的所述内核崩溃日志；
接收内核崩溃日志的获取请求；
将所述内核崩溃日志返回至所述获取请求的发起端。
可选地，还包括：
接收所述linux系统设备发送的对应所述内核崩溃日志的发送时间戳；
确定接收到所述内核崩溃日志的接收时间戳，利用所述发送时间戳与所述接收时间戳确定所述内核崩溃日志的发送时长是否超出预设时间范围；
若否，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
可选地，还包括：
结合每个所述内核崩溃日志的发送时间戳确定内核崩溃日志的时间分布结果。
可选地，还包括：
接收所述linux系统设备发送的对应所述内核崩溃日志的linux系统设备序列号；
确定所述linux系统设备序列号是否满足预设规则；
若是，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
可选地，还包括：
结合每个所述内核崩溃日志的linux系统设备序列号确定每个linux系统设备出现内核崩溃的频次。
为实现上述目的，本申请还提供一种服务器设备，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如任一项所述崩溃日志分析方法的步骤。
为实现上述目的，本发明进一步提供一种计算机程序产品，包括计算机指令，当所述计算机指令在计算机上运行时，使得所述计算机可以执行前述公开的崩溃日志采集方法。
由此可见，本申请提供的一种崩溃日志采集方法，可以由linux系统设备在监测到内核崩溃时就将内核崩溃日志写入至非易失性存储空间pstore中，从而再次重启linux系统设备后，linux系统恢复功能，同时pstore中的内核崩溃日志也会保留，将内核崩溃日志上传至服务器，从而可以使开发人员通过服务器来获取到各个linux系统设备的内核崩溃日志，而无需现场通过串口线的方式获取，从而极大的方便了linux系统设备的崩溃日志的采集。
附图说明
图1为本发明提供的一种崩溃日志采集方法流程图；
图2为本发明提供的一种具体的崩溃日志采集方法流程图；
图3为本发明提供的一种具体的崩溃日志采集方法流程图；
图4为本发明提供的一种崩溃日志采集系统结构示意图；
图5为本发明一实施例揭露的linux系统设备的内部结构示意图；
图6为本发明提供的一种崩溃日志分析方法流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是，在本发明中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。
本申请提供一种崩溃日志采集方法、linux系统设备、一种崩溃日志分析方法、服务器设备，以方便的获取到linux内核崩溃信息。
本发明提供一种崩溃日志采集方法。
参照图1，图1为本发明提供的一种崩溃日志采集方法流程图。
在一实施例中，该方法包括：
S101，监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump 函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore。
需要说明的是，Panic函数，实际上是User::Panic()，当系统发现无法继续运行下去的故障时将调用它，panic函数会依次调用预先注册的钩子函数。在本方案中，预先利用Kmsg_dump函数注册一个pstore_dump函数， pstore_dump函数即用于读取内核崩溃日志到pstore中的函数，在完成注册后，内核出现崩溃情况，panic函数就会调用该pstore_dump函数，读取内核崩溃日志，并将内核崩溃日志保存于pstore。
S102，所述设备重启后，从预先挂载的预设pstore的文件系统读取所述内核崩溃日志。
需要说明的是，pstore是在linux系统中管理的一块在不断电重启的情况下的非易失性的存储空间，当linux内核崩溃时，将内核崩溃日志存储到pstore 中，再次重启linux系统后，内核崩溃日志就依然会保留在pstore中，从而可以避免内核崩溃日志的丢失。
在本方案中，预先对linux系统设备进行设置，以使linux系统设备可以在监测到内核崩溃时，从内核中读取内核崩溃日志至pstore中。
首先在使用前可以在BootLoader(启动装载)启用并设置好linux内核的 pstore参数，如为pstore设置ram(Random Access Memory，随机存取存储器) 的开始地址，ram的长度等。
内核崩溃后需要重新启动linux系统，才能够进行后续的操作。重新启动 linux系统，从而预先挂载预设pstore的文件系统中向预设pstore读取内核崩溃日志。
需要说明的是，pstore是内核层的存储空间，用户层无法直接从pstore中读取数据，需要提前挂载对应pstore的文件系统，文件系统属于用户层，可以通过文件系统来访问pstore。
S103，将所述内核崩溃日志通过网络上传至服务器，以通过服务器获取所有接收到的内核崩溃日志。
在读取到内核崩溃日志后，将内核崩溃日志通过网络上传至服务器，从而开发人员可以通过服务器来获取到各个linux系统设备的内核崩溃日志，而无需现场通过串口线的方式获取。
在一个具体的实施方式中，linux系统设备通过HTTP协议进行内核崩溃日志的上传，具体可以采用HTTP post方式将内核崩溃日志上传至服务器，服务器的崩溃日志分析系统需要提前绑定TCP80端口，开启HTTP服务，从而接收linux系统设备上传的数据。如果上传成功，服务器可以返回HTTP 200，以告知linux系统设备上传成功。
由此可见，本申请提供的一种崩溃日志采集方法，可以由linux系统设备在监测到内核崩溃时就将内核崩溃日志写入至非易失性存储空间pstore中，从而再次重启linux系统设备后，linux系统恢复功能，同时pstore中的内核崩溃日志也会保留，将内核崩溃日志上传至服务器，从而可以使开发人员通过服务器来获取到各个linux系统设备的内核崩溃日志，而无需现场通过串口线的方式获取，从而极大的方便了linux系统设备的崩溃日志的采集。
下面对本申请实施例提供的一种具体的崩溃日志采集方法进行介绍，下文描述的一种具体的崩溃日志采集方法与上述实施例可以相互参照。
参见图2，本申请实施例提供的一种具体的崩溃日志采集方法，具体包括：
S201，监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump 函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore。
S202，所述设备重启后，从预先挂载的预设pstore的文件系统读取所述内核崩溃日志。
S203，将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志。
需要说明的是，pstore对应的存储空间只能够满足不断电情况下的非易失性，如果断电，则存储在其中的数据将会被清除；此外，由于存储介质本身的存储空间有限，而且实际业务中并不能够将全部的存储介质设置为pstore，所以在linux系统中设置的pstore的存储空间通常更为有限。
为了节省pstore对应的存储空间，并保证内核崩溃日志数据存储的可靠性，在本方案中，将内核崩溃日志从pstore直接保存至存储介质eMMC
(Embedded Multi Media Card，嵌入式多媒体卡)中，eMMC具有数据在断电不丢失的性能，从而既能够保证数据存储的可靠性，又能够及时删除pstore 中的内核崩溃日志，节省pstore的存储空间。
需要说明的是，linux内核在向pstore存储内核崩溃日志时，均是内核层的操作，而从pstore中读取内核崩溃日志的操作是用户层的操作，用户层不能够直接对内核层pstore进行操作，因此，还需要挂载pstore的文件系统，在文件系统中对pstore中的数据进行访问。
在一个具体的实施方式中，所述将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志之前，还包括：
将所述内核崩溃日志上传至服务器，判断所述内核崩溃日志是否上传成功；
若否，则执行所述将所述内核崩溃日志保存至eMMC中，并删除所述 pstore中的所述内核崩溃日志的步骤。
在一个具体的实施方式中，为了避免过多占用eMMC的存储空间，所述从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器之后，还包括：
判断所述内核崩溃日志是否上传成功；
若是，则删除所述eMMC中的所述内核崩溃日志。
如果内核崩溃日志已经上传成功，则可以在本地eMMC中删除内核崩溃日志，从而节省eMMC存储空间。
在本方案中，将内核崩溃日志从pstore读到eMMC再进行上传会有一定的延时，而且相比于直接从pstore读取内核崩溃日志进行上传来说，操作的复杂度也有一定程度的增加。因此本方案中先直接从pstore读取内核崩溃日志进行上传，当上传失败时，为了保证数据不被丢失，再将内核崩溃日志保存至eMMC，再进行上传操作时，则从eMMC读取内核崩溃日志。
S204，从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志通过网络上传至服务器。
在本方案中，内核崩溃日志保存与eMMC中，因此从eMMC中读取内核崩溃日志，并将内核崩溃日志上传至服务器。
在一个具体的实施方式中，还包括：
监测所述eMMC中的所述内核崩溃日志超出预设个数时，按照时间从近到远的顺序确定所述预设个数的保留内核崩溃日志，并删除所有非保留内核崩溃日志。
需要说明的是，如果不及时删除eMMC中的过期内核崩溃日志，会导致 eMMC资源浪费严重，因此本方案中的eMMC中的内核崩溃日志超出预设个数时，就按照时间顺序将存放时间较长的eMMC数据删除。
可见，eMMC具有数据在断电不丢失的性能，从而既能够保证数据存储的可靠性，又能够及时删除pstore中的内核崩溃日志，节省pstore的存储空间。
下面对本申请实施例提供的一种具体的崩溃日志采集方法进行介绍，下文描述的一种具体的崩溃日志采集方法与上述任一实施例可以相互参照。
参见图3，本申请实施例提供的一种具体的崩溃日志采集方法，具体包括：
S301，监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump 函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore。
S302，所述设备重启后，从预先挂载的预设pstore的文件系统读取所述内核崩溃日志。
S303，将所述内核崩溃日志与所述内核崩溃日志对应的验证数据通过网络上传至服务器，以使服务器进行验证分析。
在本方案中，为了确保内核崩溃日志的真实可靠，及时发现内核崩溃日志在上传过程中被篡改的情况，在本方案中，需要将内核崩溃日志与对应的验证数据共同上传至服务器，从而使服务器根据验证数据对内核崩溃日志进行验证分析。
在一个具体的实施方式中，所述验证数据包括：
当前时间戳、所述linux系统设备序列号和签名参数中的至少一项。
当前时间戳也就是发送内核崩溃日志时的时间戳，linux系统设备将当前时间戳与内核崩溃日志一起发送至服务器，服务器可以判断接收到的时间戳和接收到内核崩溃日志时服务器系统的时间戳之差是否大于预设阈值，从而判断内核崩溃日志传输过程是否超时，如果超时，则认为内核崩溃日志不正常，即可向linux系统设备返回失败的信号，以使其重新发送内核崩溃日志。
每个linux系统设备都会有唯一的序列号(Serial Number，SN)，合法的 linux系统设备的序列号均符合特定的预设规则，如长度规则、前缀规则等， linux系统设备可以将序列号与内核崩溃日志一起发送至服务器，从而服务器根据预设规则判断其长度是否满足预设规则以及前缀是否满足前缀规则，从而判断出序列号是否合法，如果不合法，则认为内核崩溃日志不正常，即可向linux系统设备返回失败的信号，以使其重新发送内核崩溃日志。
为进一步确保内核崩溃日志数据的安全性，还可以采用签名技术来验证内核崩溃日志。具体地，利用预设加密算法如MD5，对内核崩溃日志的相关参数进行签名，如对上述时间戳、序列号进行签名得到签名参数，服务器在接收到签名参数后，利用相同的算法进行解密，得到明文的参数，将解密得到的明文参数与内核崩溃日志携带的明文参数进行对比，如不一致，则认为内核崩溃日志不正常，即可向linux系统设备返回失败的信号，以使其重新发送内核崩溃日志。
需要说明的是，在本方案中，内核崩溃日志可以被服务器保存至磁盘，并将对应的验证数据，如序列号、时间戳等数据以及内核崩溃日志文件的标识作为一条数据记录保存至数据库中，以便查询。
可见本申请发送内核崩溃日志以及对应的验证数据即可使服务器对内核崩溃日志进行验证，从而确保内核崩溃日志的真实可靠，及时发现内核崩溃日志在上传过程中被篡改的情况。
下面对本申请实施例提供的一种崩溃日志采集系统进行介绍，下文描述的一种崩溃日志采集系统与上述任一实施例可以相互参照。
参见图4，本申请实施例提供的一种崩溃日志采集系统，具体包括：
内核崩溃日志保存模块400，用于监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore。
内核崩溃日志读取模块401，用于所述设备重启后，从预先挂载的预设 pstore的文件系统读取所述内核崩溃日志。
上传模块402，用于将所述内核崩溃日志通过网络上传至服务器，以通过服务器获取所有接收到的内核崩溃日志。
可选地，所述系统还包括：
保存模块，用于将所述内核崩溃日志保存至eMMC中，并删除所述pstore 中的所述内核崩溃日志；
则上传模块具体用于从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器。
可选地，所述系统还包括：
第一上传结果检测模块，用于将所述内核崩溃日志上传至服务器，判断所述内核崩溃日志是否上传成功；若否则调用保存模块。
可选地，所述系统还包括：
第二上传结果检测模块，用于判断所述内核崩溃日志是否上传成功；
删除模块，用于所述内核崩溃日志上传成功时，删除所述eMMC中的所述内核崩溃日志。
可选地，所述系统还包括：
监测模块，用于监测所述eMMC中的所述内核崩溃日志超出预设个数时，按照时间从近到远的顺序确定所述预设个数的保留内核崩溃日志，并删除所有非保留内核崩溃日志。
可选地，所述上传模块402具体用于将所述内核崩溃日志与所述内核崩溃日志对应的验证数据上传至服务器，以使服务器进行验证分析。
可选地，所述验证数据包括：
当前时间戳、所述linux系统设备序列号和签名参数中的至少一项。
本实施例的一种崩溃日志采集系统用于实现前述的一种崩溃日志采集方法，因此一种崩溃日志采集系统中的具体实施方式可见前文中的一种崩溃日志采集方法的实施例部分，例如，内核崩溃日志保存模块400，内核崩溃日志读取模块401，上传模块402，分别用于实现上述崩溃日志采集系统方法中步骤S101，S102，S103，所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再赘述。
进一步的，本实施例还公开了一种linux系统设备。
参照图5，图5为本发明一实施例揭露的linux系统设备的内部结构示意图。图5中，linux系统设备1包括存储器11和处理器12，所述存储器11上存储有可在所述处理器12上运行的崩溃日志采集程序，所述崩溃日志采集程序被所述处理器12执行时实现如下方法：
监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore；所述设备重启后，从预先挂载的预设pstore的文件系统读取所述内核崩溃日志；将所述内核崩溃日志通过网络上传至服务器，以通过服务器获取所有接收到的内核崩溃日志。
由此可见，本申请提供的一种linux系统设备，可以在监测到内核崩溃时就将内核崩溃日志写入至非易失性存储空间pstore中，从而再次重启linux系统设备后，linux系统恢复功能，同时pstore中的内核崩溃日志也会保留，将内核崩溃日志上传至服务器，从而可以使开发人员通过服务器来获取到各个linux系统设备的内核崩溃日志，而无需现场通过串口线的方式获取，从而极大的方便了linux系统设备的崩溃日志的采集。
所述崩溃日志采集程序被所述处理器12执行时，还可以实现：将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志；
从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器。
所述崩溃日志采集程序被所述处理器12执行时，还可以实现：将所述内核崩溃日志上传至服务器，判断所述内核崩溃日志是否上传成功；若否，则执行所述将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志的步骤。
所述崩溃日志采集程序被所述处理器12执行时，还可以实现：判断所述内核崩溃日志是否上传成功；若是，则删除所述eMMC中的所述内核崩溃日志。其中，所述第二分割结果被发送时的所需带宽数据小于所述上报模块的带宽性能数据。
所述崩溃日志采集程序被所述处理器12执行时，还可以实现：监测所述 eMMC中的所述内核崩溃日志超出预设个数时，按照时间从近到远的顺序确定所述预设个数的保留内核崩溃日志，并删除所有非保留内核崩溃日志。
所述崩溃日志采集程序被所述处理器12执行时，具体可以实现：将所述内核崩溃日志与所述内核崩溃日志对应的验证数据上传至服务器，以使服务器进行验证分析。
可选地，所述验证数据包括：
当前时间戳、所述linux系统设备序列号和签名参数中的至少一项。
在本实施例中，所述linux系统设备1可以是PC(Personal Computer，个人电脑)，也可以是智能手机、平板电脑、掌上电脑、便携计算机。
进一步的，参照图5，所述linux系统设备1还可以包括总线13，其中，所述存储器11和所述处理器12通过所述总线13连接。
其中，存储器11至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器11在一些实施例中可以是linux系统设备1 的内部存储单元，例如该linux系统设备1的硬盘。存储器11在另一些实施例中也可以是linux系统设备1的外部存储设备，例如linux系统设备1上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(SecureDigital,SD)卡，闪存卡(Flash Card)等。进一步地，存储器11还可以既包括linux系统设备1的内部存储单元也包括外部存储设备。存储器11不仅可以用于存储安装于linux系统设备1的应用软件及各类数据，例如崩溃日志采集程序的代码等，还可以用于暂时地存储已经输出或者将要输出的数据。
处理器12在一些实施例中可以是一中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行存储器11中存储的程序代码或处理数据，例如执行崩溃日志采集程序等。
总线13可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称 EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
进一步地，linux系统设备1还可以包括网络接口14，网络接口14可选的可以包括有线接口和/或无线接口(如WI-FI接口、蓝牙接口等)，通常用于在该linux系统设备1与其他电子设备之间建立通信连接。
可选地，该linux系统设备1还可以包括用户接口15，用户接口15可以包括显示器(Display)、输入单元比如键盘(Keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在linux系统设备1中处理的信息以及用于显示可视化的用户界面。
图5仅示出了具有组件11-15的linux系统设备1，本领域技术人员可以理解的是，图5示出的结构并不构成对linux系统设备1的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。
进一步的，本实施例还公开了一种崩溃日志分析方法。
参见图6，本申请实施例提供的一种崩溃日志分析方法，应用于服务器，包括：
S501，接收linux系统设备发送的内核崩溃日志；所述内核崩溃日志为 linux系统设备监测到内核崩溃时，利用panic函数调用预先注册的 pstore_dump函数读取并保存于pstore，并从预先挂载的预设pstore的文件系统读取并上传至所述服务器的所述内核崩溃日志。
服务器接收linux系统设备发送的内核崩溃日志，内核崩溃日志被linux 系统设备采集并发送的具体操作步骤可以参见上述实施例，本方案将不再赘述。
S502，接收内核崩溃日志的获取请求。
在本方案中，服务器可以接收内核崩溃日志的获取请求，该获取请求可以是远程终端通过网络远程发送的获取请求，也可以是线程对服务器进行操作发起的获取请求。换句话说，用户可以现场操作服务器请求获取linux系统设备的内核崩溃日志，也可以是通过网络访问服务器来请求获取linux系统设备的内核崩溃日志。
具体地，服务器可以提供web服务，以使用户可以通过网络访问服务器来请求获取linux系统设备的内核崩溃日志。
S503，将所述内核崩溃日志返回至所述获取请求的发起端。
服务器接收到内核崩溃日志的获取请求后，将该请求对应的内核崩溃日志返回至获取请求的发起端。
由此可见，本申请提供的一种崩溃日志分析方法，服务器中保存有linux 系统设备上传的内核崩溃日志，linux系统设备可以在监测到内核崩溃时就将内核崩溃日志写入至非易失性存储空间pstore中，从而再次重启linux系统设备后，linux系统恢复功能，同时pstore中的内核崩溃日志也会保留，将内核崩溃日志上传至服务器，从而可以使开发人员通过服务器来获取到各个linux 系统设备的内核崩溃日志，而无需现场通过串口线的方式获取，从而极大的方便了linux系统设备的崩溃日志的采集。
在上述实施例的基础上，本实施例对技术方案作出进一步的扩充与说明，具体如下：
在上述实施例的基础上，崩溃日志分析方法还包括：
接收所述linux系统设备发送的对应所述内核崩溃日志的发送时间戳；
确定接收到所述内核崩溃日志的接收时间戳，利用所述发送时间戳与所述接收时间戳确定所述内核崩溃日志的发送时长是否超出预设时间范围；
若否，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
需要说明的是，发送时间戳也就是linux系统设备发送的对应内核崩溃日志时的时间戳，linux系统设备将发送时间戳与内核崩溃日志一起发送至服务器，服务器可以判断接收到的发送时间戳和接收到内核崩溃日志时服务器系统的接收时间戳之差是否超出预设时间范围，从而判断内核崩溃日志传输过程是否超时，如果不超时，则保留内核崩溃日志；如果超时，则认为内核崩溃日志不正常，即可删除该内核崩溃日志，同时也可以向linux系统设备返回失败的信号，以使其重新发送内核崩溃日志。
在上述实施例的基础上，本实施例对技术方案作出进一步的扩充与说明，具体如下：
在上述实施例的基础上，崩溃日志分析方法还包括：
结合每个所述内核崩溃日志的发送时间戳确定内核崩溃日志的时间分布结果。
在本方案中，由于服务器接收内核崩溃日志以及对应的时间戳，因此，可以根据时间戳信息来确定出内核崩溃日志的时间分布结果，从而便于对用户根据时间分布结果对内核崩溃情况进行分析。
在上述实施例的基础上，本实施例对技术方案作出进一步的扩充与说明，具体如下：
在上述实施例的基础上，崩溃日志分析方法还包括：
接收所述linux系统设备发送的对应所述内核崩溃日志的linux系统设备序列号；
确定所述linux系统设备序列号是否满足预设规则；
若是，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
在本方案中，每个linux系统设备都会有唯一的序列号(Serial Number， SN)，合法的linux系统设备的序列号均符合特定的预设规则，如长度规则、前缀规则等，linux系统设备可以将序列号与内核崩溃日志一起发送至服务器，从而服务器根据预设规则判断其长度是否满足预设规则以及前缀是否满足前缀规则，从而判断出序列号是否合法，如果合法，则将内核崩溃日志保留，如果不合法，则认为内核崩溃日志不正常，删除内核崩溃日志，同时也可向 linux系统设备返回失败的信号，以使其重新发送内核崩溃日志。
在上述实施例的基础上，本实施例对技术方案作出进一步的扩充与说明，具体如下：
在上述实施例的基础上，崩溃日志分析方法还包括：
结合每个所述内核崩溃日志的linux系统设备序列号确定每个linux系统设备出现内核崩溃的频次。
在本方案中，由于服务器接收内核崩溃日志以及对应的linux系统设备序列号，因此，可以根据linux系统设备序列号来确定出每个linux系统设备出现内核崩溃的频次，从而便于对用户根据每个linux系统设备出现内核崩溃的频次结果对内核崩溃情况进行分析。
下面对本申请实施例提供的一种崩溃日志分析系统进行介绍，下文描述的一种崩溃日志分析系统与上述实施例可以相互参照。
本申请实施例提供的一种崩溃日志分析系统，具体包括：
内核崩溃日志接收模块，用于接收linux系统设备发送的内核崩溃日志；所述内核崩溃日志为linux系统设备监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取并保存于pstore，并从预先挂载的预设pstore 的文件系统读取并上传至所述服务器的所述内核崩溃日志；
获取请求接收模块，用于接收内核崩溃日志的获取请求；
日志返回模块，用于将所述内核崩溃日志返回至所述获取请求的发起端。
本实施例的崩溃日志分析系统用于实现前述的崩溃日志分析方法，因此崩溃日志分析系统中的具体实施方式可见前文中的崩溃日志分析方法的实施例部分，例如，内核崩溃日志接收模块，获取请求接收模块，日志返回模块，分别用于实现上述崩溃日志分析方法中步骤S501，S502，S503，所以，其具体实施方式可以参照相应的各个部分实施例的描述，在此不再赘述。
可选地，所述系统还包括：
时间戳接收模块，用于接收所述linux系统设备发送的对应所述内核崩溃日志的发送时间戳；
超时检测模块，用于确定接收到所述内核崩溃日志的接收时间戳，利用所述发送时间戳与所述接收时间戳确定所述内核崩溃日志的发送时长是否超出预设时间范围；若否，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
可选地，所述系统还包括：
时间分布确定模块，用于结合每个所述内核崩溃日志的发送时间戳确定内核崩溃日志的时间分布结果。
可选地，所述系统还包括：
序列号接收模块，用于接收所述linux系统设备发送的对应所述内核崩溃日志的linux系统设备序列号；
序列号检测模块，用于确定所述linux系统设备序列号是否满足预设规则；若是，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
可选地，所述系统还包括：
频次统计模块，用于结合每个所述内核崩溃日志的linux系统设备序列号确定每个linux系统设备出现内核崩溃的频次。
进一步的，本实施例还公开了一种服务器设备。
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如任一实施例所述崩溃日志分析方法的步骤。
由此可见，本申请提供的一种服务器设备，服务器中保存有linux系统设备上传的内核崩溃日志，linux系统设备可以在监测到内核崩溃时就将内核崩溃日志写入至非易失性存储空间pstore中，从而再次重启linux系统设备后， linux系统恢复功能，同时pstore中的内核崩溃日志也会保留，将内核崩溃日志上传至服务器，从而可以使开发人员通过服务器来获取到各个linux系统设备的内核崩溃日志，而无需现场通过串口线的方式获取，从而极大的方便了 linux系统设备的崩溃日志的采集。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质， (例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
需要说明的是，上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。并且本文中的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。
Claims (14)
1.一种崩溃日志采集方法，其特征在于，应用于linux系统的设备，包括：
监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取内核崩溃日志，并将所述内核崩溃日志保存于pstore；
所述设备重启后，从预先挂载的预设pstore的文件系统读取所述内核崩溃日志；
将所述内核崩溃日志通过网络上传至服务器，以通过服务器获取所有接收到的内核崩溃日志。
2.根据权利要求1所述的方法，其特征在于，所述从预先挂载的预设pstore的文件系统读取所述内核崩溃日志之后，还包括：
将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志；
则所述将所述内核崩溃日志上传至服务器，包括：
从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器。
3.根据权利要求2所述的方法，其特征在于，所述将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志之前，还包括：
将所述内核崩溃日志上传至服务器，判断所述内核崩溃日志是否上传成功；
若否，则执行所述将所述内核崩溃日志保存至eMMC中，并删除所述pstore中的所述内核崩溃日志的步骤。
4.根据权利要求2所述的方法，其特征在于，所述从所述eMMC中读取所述内核崩溃日志，并将所述内核崩溃日志上传至服务器之后，还包括：
判断所述内核崩溃日志是否上传成功；
若是，则删除所述eMMC中的所述内核崩溃日志。
5.根据权利要求2所述的方法，其特征在于，所述方法还包括：
监测所述eMMC中的所述内核崩溃日志超出预设个数时，按照时间从近到远的顺序确定所述预设个数的保留内核崩溃日志，并删除所有非保留内核崩溃日志。
6.根据权利要求1至5任意一项所述的方法，其特征在于，所述将所述内核崩溃日志上传至服务器，包括：
将所述内核崩溃日志与所述内核崩溃日志对应的验证数据上传至服务器，以使服务器进行验证分析。
7.根据权利要求6所述的方法，其特征在于，所述验证数据包括：
当前时间戳、所述linux系统设备序列号和签名参数中的至少一项。
8.一种linux系统设备，其特征在于，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如权利要求1至7任一项所述崩溃日志采集方法的步骤。
9.一种崩溃日志分析方法，其特征在于，应用于服务器，包括：
接收linux系统设备发送的内核崩溃日志；所述内核崩溃日志为linux系统设备监测到内核崩溃时，利用panic函数调用预先注册的pstore_dump函数读取并保存于pstore，并从预先挂载的预设pstore的文件系统读取并上传至所述服务器的所述内核崩溃日志；
接收内核崩溃日志的获取请求；
将所述内核崩溃日志返回至所述获取请求的发起端。
10.根据权利要求9所述的方法，其特征在于，还包括：
接收所述linux系统设备发送的对应所述内核崩溃日志的发送时间戳；
确定接收到所述内核崩溃日志的接收时间戳，利用所述发送时间戳与所述接收时间戳确定所述内核崩溃日志的发送时长是否超出预设时间范围；
若否，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
11.根据权利要求10所述的方法，其特征在于，还包括：
结合每个所述内核崩溃日志的发送时间戳确定内核崩溃日志的时间分布结果。
12.根据权利要求9所述的方法，其特征在于，还包括：
接收所述linux系统设备发送的对应所述内核崩溃日志的linux系统设备序列号；
确定所述linux系统设备序列号是否满足预设规则；
若是，则保留所述内核崩溃日志；若否，则删除所述内核崩溃日志。
13.根据权利要求12所述的方法，其特征在于，还包括：
结合每个所述内核崩溃日志的linux系统设备序列号确定每个linux系统设备出现内核崩溃的频次。
14.一种服务器设备，其特征在于，包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如权利要求9至13任一项所述崩溃日志分析方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910616028.0A CN110347571A (zh) | 2019-07-09 | 2019-07-09 | 一种崩溃日志采集方法、分析方法及相关装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910616028.0A CN110347571A (zh) | 2019-07-09 | 2019-07-09 | 一种崩溃日志采集方法、分析方法及相关装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110347571A true CN110347571A (zh) | 2019-10-18 |
Family
ID=68178631
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910616028.0A Pending CN110347571A (zh) | 2019-07-09 | 2019-07-09 | 一种崩溃日志采集方法、分析方法及相关装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110347571A (zh) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112417245A (zh) * | 2020-11-18 | 2021-02-26 | 掌阅科技股份有限公司 | 应用日志的抓取方法、计算设备及计算机存储介质 |
| CN113505014A (zh) * | 2021-06-09 | 2021-10-15 | 荣耀终端有限公司 | 一种故障诊断文件获取方法及装置 |
| CN114706708A (zh) * | 2022-05-24 | 2022-07-05 | 北京拓林思软件有限公司 | 一种用于Linux操作系统的故障分析方法及系统 |
| CN115292260A (zh) * | 2022-10-10 | 2022-11-04 | 深圳市广和通无线通信软件有限公司 | 一种系统运行维护处理方法、装置、设备及介质 |
| CN116662284A (zh) * | 2022-09-07 | 2023-08-29 | 荣耀终端有限公司 | 日志管理方法、装置、芯片、电子设备及介质 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106888125A (zh) * | 2017-03-30 | 2017-06-23 | 努比亚技术有限公司 | 一种处理异常关机日志的方法、移动终端和服务器 |
| CN107967192A (zh) * | 2017-12-20 | 2018-04-27 | 北京奇虎科技有限公司 | 一种智能终端的系统崩溃处理方法和装置 |
| CN108121612A (zh) * | 2017-12-19 | 2018-06-05 | 上海斐讯数据通信技术有限公司 | 一种基于Linux内核路由器的崩溃处理方法和系统 |
| CN109062627A (zh) * | 2018-07-12 | 2018-12-21 | 郑州云海信息技术有限公司 | 一种Linux服务器系统kdump服务的配置方法 |
-
2019
- 2019-07-09 CN CN201910616028.0A patent/CN110347571A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106888125A (zh) * | 2017-03-30 | 2017-06-23 | 努比亚技术有限公司 | 一种处理异常关机日志的方法、移动终端和服务器 |
| CN108121612A (zh) * | 2017-12-19 | 2018-06-05 | 上海斐讯数据通信技术有限公司 | 一种基于Linux内核路由器的崩溃处理方法和系统 |
| CN107967192A (zh) * | 2017-12-20 | 2018-04-27 | 北京奇虎科技有限公司 | 一种智能终端的系统崩溃处理方法和装置 |
| CN109062627A (zh) * | 2018-07-12 | 2018-12-21 | 郑州云海信息技术有限公司 | 一种Linux服务器系统kdump服务的配置方法 |
Non-Patent Citations (3)
| Title |
|---|
| FKINGING: "Pstore dmesg 注册篇", pages 1 - 2, Retrieved from the Internet <URL:https://blog.csdn.net/qq_27125121/article/details/78668035> * |
| SHUAI_WEN: "pstore 从oops发生到保存dmesg的过程", pages 1 - 5, Retrieved from the Internet <URL:https://blog.csdn.net/u011279649/article/details/50197725> * |
| YAXINSN: "嵌入式系统linux 记录内存panic", pages 1 - 2, Retrieved from the Internet <URL:https://blog.csdn.net/wbd880419/article/details/70241130> * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112417245A (zh) * | 2020-11-18 | 2021-02-26 | 掌阅科技股份有限公司 | 应用日志的抓取方法、计算设备及计算机存储介质 |
| CN113505014A (zh) * | 2021-06-09 | 2021-10-15 | 荣耀终端有限公司 | 一种故障诊断文件获取方法及装置 |
| CN113505014B (zh) * | 2021-06-09 | 2022-05-27 | 荣耀终端有限公司 | 一种故障诊断文件获取方法及装置 |
| CN114706708A (zh) * | 2022-05-24 | 2022-07-05 | 北京拓林思软件有限公司 | 一种用于Linux操作系统的故障分析方法及系统 |
| CN116662284A (zh) * | 2022-09-07 | 2023-08-29 | 荣耀终端有限公司 | 日志管理方法、装置、芯片、电子设备及介质 |
| CN115292260A (zh) * | 2022-10-10 | 2022-11-04 | 深圳市广和通无线通信软件有限公司 | 一种系统运行维护处理方法、装置、设备及介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110347571A (zh) | 一种崩溃日志采集方法、分析方法及相关装置 | |
| CN111414334B (zh) | 基于云技术的文件分片上传方法、装置、设备及存储介质 | |
| US10104063B2 (en) | Android-based mobile equipment security protection method, and device | |
| CN108108286A (zh) | 数据收集方法和装置、服务器、存储介质 | |
| JP3954642B1 (ja) | 画面保存システム | |
| CN101848373A (zh) | 无线视频监控系统及其视频监控方法 | |
| WO2019051948A1 (zh) | 监控数据的处理方法、设备、服务器及存储介质 | |
| CN102196021A (zh) | 远端移除数据的方法与系统、伺服器及移动装置 | |
| CN102693381A (zh) | 一种便携计算机设备的防盗方法、装置和系统 | |
| CN109299064B (zh) | 数据库监控方法及终端设备 | |
| US20160321450A1 (en) | Method and Apparatus for Managing Super User Password on Smart Mobile Terminal | |
| CN109800576B (zh) | 未知程序异常请求的监控方法、装置、及电子装置 | |
| CN105224441B (zh) | 虚拟机信息采集装置、方法及虚拟机信息维护方法和系统 | |
| CN104615662B (zh) | 一种处理数据的方法、装置及终端设备 | |
| US9571333B2 (en) | Network device and method for maintaining network connection | |
| CN111464513A (zh) | 数据检测方法、装置、服务器及存储介质 | |
| CN103490978A (zh) | 终端、服务器和消息监视方法 | |
| CN109597707A (zh) | 克隆卷数据拷贝方法、装置及计算机可读存储介质 | |
| CN105847516B (zh) | 一种联系人信息管理方法及装置 | |
| CN115134352B (zh) | 一种埋点数据上传方法、装置、设备及介质 | |
| CN102752365B (zh) | 信息处理的方法与装置 | |
| CN109936528B (zh) | 监测方法、装置、设备及系统 | |
| CN113852610B (zh) | 报文处理方法、装置、计算机设备和存储介质 | |
| CN106603625B (zh) | 一种数据保护方法及装置 | |
| CN111093186B (zh) | 一种eSIM卡运营商文件管理方法和系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |