Method and device for monitoring open source software

Abstract

The invention discloses an open source software monitoring method and device, and relates to the technical field of networks. The method comprises the following steps: a heartbeat server determines whether a process is abnormal or not according to a heartbeat message, and determines that a heartbeat client is in an abnormal state under the condition that the heartbeat message of the heartbeat client is not received within threshold time. Wherein the heartbeat client is a process in a container of the open source software. By adopting the scheme, even if the process is locked or hung, the process abnormity can still be monitored through the method, the problem that abnormal information caused by locking or hanging in the related technology is not recorded is solved, and the reliability and maintainability of open source software can be improved.

Description

Technical Field

[0001] The present application relates to the field of network technology, and in particular to a monitoring method and device for open source software. Background Art

[0002] The architecture of open source software such as SONIC (Software for Open Networking in the Cloud) includes processes for running various services, which are placed in containers. If all processes in all containers run successfully, the open source software has completed the startup process and can handle services normally.

[0003] During the operation of open source software, the software management mechanism of open source software will monitor each process in the container. Once a process in the container exits abnormally, relevant information about the exception will be recorded in the system log file for subsequent maintenance.

[0004] Therefore, open source software can only record system log files when a process exits abnormally. When a process in a container has an exception but does not exit (such as deadlock or hanging), the open source software will not record relevant information of the exception in the system log file, resulting in poor overall system reliability and maintainability. Summary of the invention

[0005] The present application provides a method and device for monitoring open source software, which can improve the reliability and maintainability of open source software.

[0006] In a first aspect, the present application provides a monitoring method for open source software. The open source software includes a heartbeat server and a heartbeat client, and the method includes: when the heartbeat server does not receive a heartbeat message from the heartbeat client within a threshold time, the heartbeat server determines that the heartbeat client is in an abnormal state, and the heartbeat client is a process in a container of the open source software.

[0007] In this implementation, a heartbeat server is set in the open source software, and the process in the container of the open source software transmits heartbeat messages between the heartbeat client and the heartbeat server. The heartbeat server determines whether a process abnormality occurs based on the heartbeat message, and if the heartbeat message from the heartbeat client is not received within the threshold time, it is considered a process abnormality. With this solution, even if the process is locked or hung, the process abnormality can still be monitored by this method, which solves the problem of no record of abnormal information caused by locking or hanging in the related technology, and can improve the reliability and maintainability of the open source software.

[0008] In the implementation of the present application, the heartbeat server receives the heartbeat messages sent by each heartbeat client. Based on the heartbeat message transmission status of each heartbeat client, it is determined whether each heartbeat client has an abnormality. In the scenario where an abnormal state occurs, there are the following two situations:

[0009] In one example, during the receiving process, after the heartbeat server continuously receives several heartbeat messages from a heartbeat client, it no longer receives the heartbeat message from the heartbeat client within the threshold time. At this time, the heartbeat server can determine that the heartbeat client is in an abnormal state.

[0010] In another example, after the heartbeat server has determined the heartbeat client to be monitored, it has not received a heartbeat message from the heartbeat client, and has not received a heartbeat message from the heartbeat client within a threshold time. In this case, the heartbeat server may also consider the heartbeat client to be in an abnormal state.

[0011] In the implementation of the present application, the threshold time can be set as needed. Exemplarily, the transmission period of the heartbeat message is time T, then the threshold time can be 2T to 4T, for example, the threshold time is 3T.

[0012] The size of T can be set as required. For example, T is 10 seconds to 60 seconds, for example, T is 30 seconds.

[0013] In the implementation of the present application, the role of the heartbeat message is that the heartbeat client notifies the heartbeat server of the normal operation of the open source software process corresponding to the heartbeat client. Therefore, the heartbeat message only needs to carry relevant information of the open source software process.

[0014] In some possible implementations of the present application, the heartbeat message includes a service identifier assigned by the heartbeat server to the heartbeat client and an identifier of a process corresponding to the heartbeat client.

[0015] The heartbeat server will assign an ID to each process of the open source software, which is also called a service ID. The process ID is assigned by the system. For example, if the base of the open source software is the Linux system, the process ID is the ID assigned by the Linux system.

[0016] In this implementation, the heartbeat message carries both of the above identifiers. The process identifier allows the process to be located in the system later through the identifier, while the service identifier allows the heartbeat server to manage the client from the perspective of the heartbeat service.

[0017] In some other possible implementations of the present application, the heartbeat message may also include only one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client.

[0018] Optionally, the heartbeat message may further include at least one of a priority field and a reserved field.

[0019] Among them, the role of priority is to mark the priority of the heartbeat messages of different heartbeat clients. If the traffic between the heartbeat client and the heartbeat server is too large, you can use the priority to schedule and process or send and receive the heartbeat messages with high priority first, and then process the heartbeat messages with low priority.

[0020] The function of the reserved field is to enhance the scalability of the heartbeat message. The reserved field can be used to carry the frame check sequence (FCS). The reserved field can be filled with a fixed all-0 by default.

[0021] In the implementation of the present application, the method further includes: the heartbeat server stores call stack information of the heartbeat client, and the call stack information is used to analyze the cause of the abnormality when the heartbeat client is determined to be abnormal.

[0022] The function of the call stack information is that when a process is abnormal, the user can analyze and determine the cause of the abnormality of the process by viewing the call stack information of the process. Therefore, by storing the call stack information of the heartbeat client when the heartbeat client is abnormal, a basis is provided for subsequent users to analyze and determine the cause of the abnormality of the process.

[0023] Exemplarily, the call stack information may include a call function stack. In this implementation, the call function stack is used as a basis for troubleshooting the cause of the exception.

[0024] Optionally, the information stored by the heartbeat server also includes:

[0025] At least one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client, the state of the heartbeat client, the duration of not receiving the heartbeat message and at least one of the last receiving time of the heartbeat message.

[0026] The status of the heartbeat client includes an abnormal status and a normal status. If the heartbeat server does not receive a heartbeat message from the heartbeat client within a threshold time, the heartbeat server determines that the heartbeat client is in an abnormal status; if the heartbeat server receives a heartbeat message from the heartbeat client within a threshold time, the heartbeat server determines that the heartbeat client is in a normal status.

[0027] In this implementation, by storing the status of the heartbeat client, it is possible to intuitively indicate whether the process corresponding to the heartbeat client is abnormal.

[0028] Among them, at least one of the duration of not receiving the heartbeat message and the last receiving time of the heartbeat message is used to indicate the heartbeat message transmission between the heartbeat client and the heartbeat server, and belongs to the heartbeat message transmission information. The duration of not receiving the heartbeat message refers to the duration from the last successful reception of the heartbeat message to the current time; the last receiving time of the heartbeat message refers to the time when the heartbeat message was successfully received for the last time.

[0029] In this implementation, by storing at least one of the duration of not receiving the heartbeat message and the last receiving time of the heartbeat message, the transmission status of the heartbeat message can be determined when the heartbeat client is abnormal, and the time when the abnormality occurred can also be determined.

[0030] Optionally, the information stored by the heartbeat server also includes:

[0031] Heartbeat message count value. The heartbeat message count value refers to the cumulative number of heartbeat messages sent by the heartbeat client. The heartbeat message count value can be recorded as a statistical data of the heartbeat message and belongs to the heartbeat message transmission information.

[0032] In some possible implementations of the present application, the heartbeat server stores the call stack information of the heartbeat client, including:

[0033] The heartbeat server stores the call stack information of the heartbeat client in the remote dictionary server Redis. The key in Redis is at least one of the service identifier of the heartbeat client, the identifier of the process corresponding to the heartbeat client, and the name of the process corresponding to the heartbeat client. The value in Redis is the call stack information of the heartbeat client.

[0034] In this implementation, by using Redis for storage, serialization can be completed through the Redis interface and the data can be stored in Redis.

[0035] Redis uses a hash structure to store call stack information. The hash structure of Redis is Key-Field-Value, where the Key can be the name of a heartbeat client process. In this way, according to the Key, it is clear which process in the open source software the entry corresponds to. The Field corresponds to the name of the call stack information of the heartbeat client, and the Value is the value corresponding to the Field, that is, the content of the call stack information of the heartbeat client.

[0036] Optionally, in addition to storing call stack information, when the information stored on the heartbeat server includes other content, the other content can also be stored in the Redis Hash structure. When storing these contents, you only need to add Field-Value to the Redis Hash structure. Taking the status of the heartbeat client as an example, Field corresponds to the name of the status of the heartbeat client, and Value is the value of the status of the heartbeat client.

[0037] In other possible implementations of the present application, the call stack information of the heartbeat client may also be stored in other ways, and the present application does not impose any restrictions on this.

[0038] In the implementation of the present application, the heartbeat server may store relevant information of the heartbeat client in normal state in addition to storing the heartbeat client information, heartbeat message transmission information, and call stack information of the heartbeat client in abnormal state.

[0039] In some examples, the heartbeat server stores information about the heartbeat client in a normal state and heartbeat message transmission information.

[0040] In other examples, the heartbeat server stores information of the heartbeat client in a normal state, heartbeat message transmission information, and call stack information.

[0041] The manner in which the heartbeat server stores the relevant information of the heartbeat client in a normal state may be the same as the manner in which the heartbeat server stores the relevant information of the heartbeat client in an abnormal state.

[0042] In the implementation of the present application, each open source software process needs to be registered on the heartbeat server first, and the heartbeat message can be transmitted only after the registration is completed. That is, the method also includes:

[0043] The heartbeat server receives the registration request from the heartbeat client; the heartbeat server allocates a service identifier to the heartbeat client in response to the registration request.

[0044] In some possible implementations of the present application, the heartbeat client sends a registration request to the heartbeat server by means of a function call.

[0045] In one example, the registration request carries the name of the process corresponding to the heartbeat client.

[0046] In other examples, the registration request may further include an identifier of the process, or include a name of the process and an identifier of the process, etc.

[0047] In some other possible implementations of the present application, the heartbeat client sends a registration request to the heartbeat server through other means, which is not limited in the present application.

[0048] In the implementation of the present application, the open source software is the cloud-based open network software SONIC.

[0049] In this implementation, the open source software is SONIC, and the solution provided in this application can improve the reliability and maintainability of SONIC.

[0050] In a second aspect, the present application provides a monitoring device for open source software, the open source software includes a heartbeat server and a heartbeat client, the device is applied to the heartbeat server, and the device includes:

[0051] The processing unit is used to determine that the heartbeat client is in an abnormal state when no heartbeat message from the heartbeat client is received within a threshold time. The heartbeat client is a process in a container of open source software.

[0052] Exemplarily, the heartbeat message includes at least one of a service identifier assigned by the heartbeat server to the heartbeat client and an identifier of a process corresponding to the heartbeat client.

[0053] Optionally, the heartbeat message also includes at least one of a priority field and a reserved field.

[0054] Optionally, the device further comprises:

[0055] The storage unit is used to store call stack information of the heartbeat client, and the call stack information is used to analyze the cause of the abnormality when the heartbeat client is determined to be abnormal.

[0056] Optionally, the information stored by the heartbeat server also includes:

[0057] At least one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client, the state of the heartbeat client, the duration of not receiving the heartbeat message and at least one of the last receiving time of the heartbeat message.

[0058] Optionally, the information stored by the heartbeat server also includes:

[0059] Heartbeat message count value.

[0060] Optionally, the storage unit is used to store the call stack information of the heartbeat client in the remote dictionary server Redis, the key Key in Redis is at least one of the service identifier of the heartbeat client, the identifier of the process corresponding to the heartbeat client, and the name of the process corresponding to the heartbeat client, and the value Value in Redis is the call stack information of the heartbeat client.

[0061] Optionally, the device further comprises:

[0062] A receiving unit, used for receiving a registration request from a heartbeat client;

[0063] The processing unit is further configured to allocate a service identifier to the heartbeat client in response to the registration request.

[0064] Exemplarily, the open source software is the cloud-based open network software SONIC.

[0065] In a third aspect, a network device is provided. The network device includes a processor and a memory. The memory is used to store software programs and modules. The processor implements the method in the first aspect or any possible implementation of the first aspect by running or executing the software program and / or module stored in the memory.

[0066] Optionally, the number of the processors is one or more, and the number of the memories is one or more.

[0067] Optionally, the memory may be integrated with the processor, or the memory may be provided separately from the processor.

[0068] In the specific implementation process, the memory can be a non-transitory memory, such as a read-only memory (ROM), which can be integrated with the processor on the same chip or can be set on different chips. This application does not limit the type of memory and the setting method of the memory and the processor.

[0069] In a fourth aspect, a computer program product is provided, wherein the computer program product includes a computer program code, and when the computer program code is executed by a device, the device executes the method in the first aspect or any possible implementation of the first aspect.

[0070] In a fifth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store program codes executed by a processor, wherein the program codes include a method for implementing any possible implementation of the first aspect above.

[0071] In a sixth aspect, a chip is provided, comprising a processor, the processor being used to call and execute instructions stored in a memory from the memory, so that a network device equipped with the chip executes a method in any possible implementation manner of the above-mentioned first aspect.

[0072] In a seventh aspect, another chip is provided. The another chip includes an input interface, an output interface, a processor, and a memory. The input interface, the output interface, the processor, and the memory are connected via an internal connection path. The processor is used to execute the code in the memory, and when the code is executed, the processor is used to execute the method in any possible implementation of the first aspect above.

[0073] In an eighth aspect, a transmission system is provided, the system comprising a device as in the second aspect or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] Figure 1 It is a schematic diagram of a system architecture provided by an embodiment of the present application;

[0075] Figure 2 is a flow chart of a method for monitoring open source software provided in an embodiment of the present application;

[0076] Figure 3 is a flow chart of a method for monitoring open source software provided in an embodiment of the present application;

[0077] Figure 4 It is a structural diagram of a heartbeat server provided in an embodiment of the present application;

[0078] Figure 5 is a block diagram of a monitoring device for open source software provided in an embodiment of the present application;

[0079] Figure 6 It is a structural diagram of a network device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0080] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0081] To facilitate the understanding of the technical solution provided by the embodiment of the present application, the system structure of the present application is first introduced. The system structure of the present application is the architecture of open source software, and the following is an exemplary description using the SONIC architecture as an example.

[0082] Figure 1 Schematic diagram of a system architecture provided by an embodiment of the present application. The system architecture is a SONIC architecture, see Figure 1 The SONIC architecture includes a container 10, in which a process 20 for running a business is provided. In order to solve the technical problem to be solved by the present application, the present application adds a heartbeat server 30 in SONIC. The heartbeat server 30 is a new component in SONIC, which is deployed and runs in SONIC as an independent process. The process 20 in each container 10 can register with the heartbeat server 30 as a heartbeat client, and then transmit the heartbeat message.

[0083] like Figure 1As shown, the containers in SONIC may include border gateway protocol (BGP) containers, link aggregation group (LAG) containers, SONIC switch state service (SWSS) containers, etc. The BGP container is provided with a BGP daemon (Bgpd), which is used to implement standard BGP services; the LAG container is provided with a team daemon (Teamd), which is used to run the LAG function in the SONIC device and aggregate multiple threads into a Team; the SWSS container is provided with a core daemon, named Orchagent process, which is the most critical component in SWSS.

[0084] See again Figure 1 The SONIC architecture also includes a database (DB) 40 for storing data of abnormal heartbeat clients.

[0085] The solution provided in this application can be applied to network devices that use open source software as a control system, such as switch devices that use SONIC as a control system.

[0086] Figure 2 1 is a flow chart of a method for monitoring open source software provided by an embodiment of the present application. The method can be executed by a network device that uses the open source software as a control system, for example, by a heartbeat server of the open source software in the network device. Figure 2 As shown, the method includes the following steps.

[0087] S101: When the heartbeat server does not receive a heartbeat message from the heartbeat client within a threshold time, the heartbeat server determines that the heartbeat client is in an abnormal state.

[0088] Among them, the heartbeat client is a process in the container of the open source software.

[0089] In the implementation of this application, the heartbeat server needs to clearly identify which heartbeat clients to monitor. Specifically, you can refer to Figure 3 The method provided in steps S201 and S202 in the corresponding embodiment monitors the heartbeat client registered with the heartbeat server.

[0090] In the implementation of the present application, the heartbeat server determines whether each heartbeat client has an abnormality based on the heartbeat message transmission of each heartbeat client. In the scenario where an abnormal state occurs, there are the following two situations:

[0091] In one example, during the receiving process, the heartbeat server receives several heartbeat messages from a heartbeat client in succession, but then no longer receives heartbeat messages from the heartbeat client within a threshold time. Figure 3 The method provided by steps S203 and S204 in the corresponding embodiment. At this time, the heartbeat server can determine that the heartbeat client is in an abnormal state.

[0092] In another example, after the heartbeat server has determined the heartbeat client to be monitored, it has not received a heartbeat message from the heartbeat client, and has not received a heartbeat message from the heartbeat client within a threshold time. In this case, the heartbeat server may also consider the heartbeat client to be in an abnormal state.

[0093] In the implementation of the present application, after the heartbeat server determines the heartbeat client in the abnormal state, it can also store the relevant information of the heartbeat client in the abnormal state. Specifically, you can refer to Figure 3 The method provided in step S205 in the corresponding embodiment stores the call stack information of the heartbeat client in the abnormal state.

[0094] In this implementation, a heartbeat server is set in the open source software, and the process in the container of the open source software transmits heartbeat messages between the heartbeat client and the heartbeat server. The heartbeat server determines whether a process abnormality occurs based on the heartbeat message, and if the heartbeat message from the heartbeat client is not received within the threshold time, it is considered a process abnormality. With this solution, even if the process is locked or hung, the process abnormality can still be monitored by this method, which solves the problem of no record of abnormal information caused by locking or hanging in the related technology, and can improve the reliability and maintainability of the open source software.

[0095] Figure 3 1 is a flow chart of a method for monitoring open source software provided by an embodiment of the present application. The method can be executed by a network device that uses the open source software as a control system, for example, by a heartbeat server and a heartbeat client of the open source software in the network device. Figure 3 As shown, the method includes the following steps.

[0096] S201: The heartbeat client sends a registration request to the heartbeat server. The heartbeat server receives the registration request from the heartbeat client.

[0097] Among them, the heartbeat client is a process in each container of the open source software.

[0098] In some possible implementations of the present application, the heartbeat client sends a registration request to the heartbeat server by means of a function call.

[0099] For example, a process in the open source software calls the Heartbeat_client_register(string client_name) function to register with the heartbeat server, where client_name is the name of the process.

[0100] In one example, the registration request carries the name of the process corresponding to the heartbeat client.

[0101] In other examples, the registration request may further include an identifier of the process, or include a name of the process and an identifier of the process, etc.

[0102] In some other possible implementations of the present application, the heartbeat client sends a registration request to the heartbeat server through other means, which is not limited in the present application.

[0103] Step S201 may be executed after the open source software is started, that is, the services in each container in the open source software are started, and the heartbeat server is started.

[0104] Figure 4 Schematic diagram of the structure of a heartbeat server provided in an embodiment of the present application. Figure 4 The heartbeat server includes a communication module, which is used to communicate with the heartbeat client (process) and is responsible for transmitting registration requests and heartbeat messages.

[0105] In the implementation of the present application, step S201 may be performed by the communication module.

[0106] S202: The heartbeat server allocates a service identifier to the heartbeat client in response to the registration request.

[0107] After receiving the registration request, the heartbeat server assigns a corresponding service identifier to the process to identify different heartbeat clients. The assignment of a service identifier indicates that the heartbeat client has successfully registered. After successful registration, the heartbeat server feeds back the assigned service identifier to the heartbeat client.

[0108] When allocating service identifiers, the heartbeat server may allocate service identifiers in the order in which the registration requests are received, for example, allocating service identifiers to each heartbeat client in ascending order of receipt. In this case, the service identifier is also a sequence number.

[0109] After the heartbeat server allocates the service identifier, a corresponding relationship between the service identifier and the name of the process and / or the identifier of the process may also be established within the heartbeat server.

[0110] In the implementation of the present application, step S202 may be performed by the communication module.

[0111] S203: The heartbeat client sends a heartbeat message to the heartbeat server. The heartbeat server receives the heartbeat messages sent by each heartbeat client.

[0112] In the implementation of the present application, the role of the heartbeat message is that the heartbeat client notifies the heartbeat server of the normal operation of the open source software process corresponding to the heartbeat client. Therefore, the heartbeat message only needs to carry relevant information of the open source software process.

[0113] In some possible implementations of the present application, the heartbeat message includes a service identifier assigned by the heartbeat server to the heartbeat client and an identifier of a process corresponding to the heartbeat client.

[0114] The heartbeat server will assign an ID to each process of the open source software, which is also called a service ID. The process ID is assigned by the system. For example, if the base of the open source software is a Linux system, the process ID is the ID assigned by the Linux system. The call stack information of the heartbeat client can be dumped through the process ID.

[0115] In this implementation, the heartbeat message carries both of the above identifiers. The process identifier allows the process to be located in the system later through the identifier, while the service identifier allows the heartbeat server to manage the client from the perspective of the heartbeat service.

[0116] In some other possible implementations of the present application, the heartbeat message may also include only one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client.

[0117] Optionally, the heartbeat message may further include at least one of a priority field and a reserved field.

[0118] Among them, the role of priority is to mark the priority of the heartbeat messages of different heartbeat clients, so that the heartbeat server can process the messages according to the priority later. For example, if the traffic between the heartbeat client and the heartbeat server is too large, the priority can be used for scheduling, and the heartbeat messages with high priority can be processed or sent and received first, and the heartbeat messages with low priority can be processed later. Priority is an optional field, and the default value can be 0.

[0119] The function of the reserved field is to enhance the scalability of the heartbeat message. For example, the reserved field can be used to carry FCS. The reserved field can be filled with fixed all 0s by default.

[0120] The following Table 1 is an example of the format of a heartbeat message provided in an embodiment of the present application.

[0121] Table 1

[0122] Service ID Process ID Priority R

[0123] Referring to Table 1, the heartbeat message includes a service identifier (Service ID), a process identifier (Process ID), a priority (Priority), and a reserved field (Rsv).

[0124] In some possible implementations of the present application, the heartbeat client periodically and actively sends heartbeat messages to the heartbeat server, indicating that its own state is normal rather than abnormal.

[0125] In some other possible implementations of the present application, the heartbeat server periodically sends messages to each heartbeat client, and the heartbeat client sends a heartbeat message in response after receiving the message from the heartbeat server. That is, the heartbeat client passively sends a heartbeat message to the heartbeat server, indicating that its own state is normal, not abnormal.

[0126] Regardless of the above implementation method, the heartbeat server can determine whether the status of the heartbeat client is normal or abnormal based on the time when the heartbeat message is received.

[0127] Exemplarily, the transmission period of the heartbeat message is time T, and the size of T can be set as needed. Exemplarily, T is 10 seconds to 60 seconds, for example, T is 30 seconds.

[0128] In the implementation of the present application, step S203 may be performed by the communication module.

[0129] S204: When the heartbeat server does not receive a heartbeat message from the heartbeat client within the threshold time, the heartbeat server determines that the heartbeat client is in an abnormal state; when the heartbeat server receives a heartbeat message from the heartbeat client within the threshold time, the heartbeat server determines that the heartbeat client is in a normal state.

[0130] In the implementation of the present application, the heartbeat server simultaneously monitors the heartbeat message transmission status of the processes in each container in the open source software, and marks the status of each process based on the heartbeat message transmission status of each process.

[0131] In the implementation of the present application, the threshold time can be set as needed. Exemplarily, the threshold time can be 2T to 4T, for example, the threshold time is 3T.

[0132] In the implementation of the present application, the open source software may provide a configuration interface and / or interface for setting the threshold time and / or transmission period, so that the threshold time and / or transmission period are configurable.

[0133] Accordingly, the method further includes: receiving an input threshold time and / or transmission period, and confirming whether the heartbeat message of the heartbeat client exceeds the threshold time based on the received threshold time and / or transmission period.

[0134] See again Figure 4 The heartbeat server also includes a timer module, which is used to periodically query whether the heartbeat messages of each heartbeat client are received. When the heartbeat message of the heartbeat client is not received after multiple consecutive queries, that is, when the heartbeat message of the heartbeat client is not received within the threshold time, the heartbeat client is marked as an abnormal state, otherwise it is marked as a normal state.

[0135] In the implementation of the present application, step S204 may be executed by the timer module.

[0136] When it is determined that the heartbeat client is in an abnormal state, the method further includes step S205.

[0137] S205: The heartbeat server stores the call stack information of the heartbeat client. The call stack information is used to analyze the cause of the abnormality when the heartbeat client is determined to be abnormal.

[0138] The function of the call stack information is that when a process is abnormal, the user can analyze and determine the cause of the abnormality of the process by viewing the call stack information of the process. Therefore, by storing the call stack information of the heartbeat client when the heartbeat client is abnormal, a basis is provided for subsequent users to analyze and determine the cause of the abnormality of the process.

[0139] Exemplarily, the information stored by the heartbeat server also includes:

[0140] At least one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client, the state of the heartbeat client, the duration of not receiving the heartbeat message and at least one of the last receiving time of the heartbeat message.

[0141] The status of the heartbeat client includes an abnormal state and a normal state. The abnormal state can also be called a delay state. If the heartbeat server does not receive a heartbeat message from the heartbeat client within the threshold time, the heartbeat server determines that the heartbeat client is in an abnormal state; if the heartbeat server receives a heartbeat message from the heartbeat client within the threshold time, the heartbeat server determines that the heartbeat client is in a normal state.

[0142] In this implementation, by storing the status of the heartbeat client, it is possible to intuitively indicate whether the process corresponding to the heartbeat client is abnormal.

[0143] Among them, at least one of the duration of not receiving the heartbeat message and the last receiving time of the heartbeat message is used to indicate the heartbeat message transmission between the heartbeat client and the heartbeat server, and belongs to the heartbeat message transmission information. The duration of not receiving the heartbeat message refers to the duration from the last successful reception of the heartbeat message to the current time; the last receiving time of the heartbeat message refers to the time when the heartbeat message was successfully received for the last time.

[0144] In this implementation, by storing at least one of the duration of not receiving the heartbeat message and the last receiving time of the heartbeat message, the transmission status of the heartbeat message can be determined when the heartbeat client is abnormal, and the time when the abnormality occurred can also be determined.

[0145] Optionally, the information stored by the heartbeat server also includes:

[0146] Heartbeat message count value. The heartbeat message count value refers to the cumulative number of heartbeat messages sent by the heartbeat client. The heartbeat message count value can be recorded as a statistical data of the heartbeat message and belongs to the heartbeat message transmission information.

[0147] Exemplarily, the call stack information may include a call function stack. In this implementation, the call stack information is stored as a basis for troubleshooting the cause of the exception.

[0148] Exemplarily, the contents of the calling function stack are as follows:

[0149] 1 0x55aa2b3428ad <dotask>

[0150] 2 0x55aa2bc5a59d<main+0x5b>

[0151] 3 0x7f7ec351bd0a<__libc_start_main+0xea>

[0152] 4 0x55aa2bc5a20e<_start+0x2e>

[0153] The call stack indicates that the process corresponding to the current heartbeat client has executed the doTask function, which is called by _start->__libc_start_main–>main in sequence. If the status of the heartbeat client is Delay, that is, an abnormal state, the user can check the call stack information and find that the client is executing the doTask function. The preliminary cause of the fault can be confirmed as being stuck in the doTask function for some reason, and then continue to locate the fault based on the preliminary cause.

[0154] In this implementation, the heartbeat server stores the above information so that the user can analyze and determine the cause of the process exception by viewing the call stack information of the process.

[0155] Table 2 below is an example of the format of a call stack information provided in an embodiment of the present application.

[0156] Table 2

[0157]

[0158] Referring to Table 2, the call stack information includes the process name (name), service ID (Service ID), process ID (Process ID), status (Status), heartbeat message count value (Rcv Total), duration of not receiving heartbeat messages (Delay Count), last received time of heartbeat messages (Last received) and call stack information (StackInfo).

[0159] In some possible implementations of the present application, the heartbeat server stores the call stack information of the heartbeat client, including:

[0160] The heartbeat server stores the call stack information of the heartbeat client in the remote dictionary server Redis. The key in Redis is at least one of the service identifier of the heartbeat client, the identifier of the process corresponding to the heartbeat client, and the name of the process corresponding to the heartbeat client. The value in Redis is the call stack information of the heartbeat client.

[0161] The heartbeat server stores the call stack information of the heartbeat client in Redis by dumping, thereby maintaining the call stack information of the abnormal heartbeat client.

[0162] In this implementation, by using Redis for storage, serialization can be completed through the Redis interface and the data can be stored in Redis.

[0163] In the implementation of the present application, the heartbeat server may store relevant information of the heartbeat client in normal state in addition to storing the heartbeat client information, heartbeat message transmission information, and call stack information of the heartbeat client in abnormal state.

[0164] In some examples, the heartbeat server stores information about the heartbeat client in a normal state and heartbeat message transmission information.

[0165] In other examples, the heartbeat server stores information of the heartbeat client in a normal state, heartbeat message transmission information, and call stack information.

[0166] The manner in which the heartbeat server stores the relevant information of the heartbeat client in a normal state may be the same as the manner in which the heartbeat server stores the relevant information of the heartbeat client in an abnormal state.

[0167] After using Redis to store the call stack information of the heartbeat client, users or maintenance personnel can read the data in Redis through the command line Cli. For example, users or maintenance personnel can use the command line Cli, and the information returned and displayed by the command line all comes from the call stack information previously stored in Redis, and the above operations help locate the problem.

[0168] In addition to using the command line, you can also use other methods to obtain data in Redis for fault location, such as remote measurement (telemetry).

[0169] The following Table 3 is an example of the format of a Key-Field-Value provided in an embodiment of the present application (only part of the content in Table 2 is shown as an example).

[0170] Table 3

[0171]

[0172] As shown in Table 3, Redis uses a hash structure to store call stack information. The hash structure of Redis is Key-Field-Value, where the Key can be the name of a heartbeat client process. In this way, according to the Key, it is clear which process in the open source software the entry corresponds to. The Field corresponds to the name of each field in the call stack information of the heartbeat client, and the Value is the value corresponding to the Field, that is, the content of the call stack information of the heartbeat client.

[0173] Refer to Table 3 again. In addition to storing call stack information, when the information stored on the heartbeat server includes other content, the other content can also be stored in the Redis Hash structure. When storing these contents, you only need to add Field-Value to the Redis Hash structure. Taking the status of the heartbeat client as an example, Field corresponds to the name of the status of the heartbeat client, and Value is the value of the status of the heartbeat client.

[0174] In this implementation, the hash structure can express richer data hierarchical relationships than other data structures.

[0175] In other possible implementations of the present application, the call stack information of the heartbeat client may also be stored in other ways, and the present application does not impose any restrictions on this.

[0176] See again Figure 4 The heartbeat server also includes a storage module, which is used to store call stack information of each heartbeat client, including heartbeat client information, heartbeat message transmission information, call stack information, etc.

[0177] In the implementation of the present application, step S205 can be executed by the timer module.

[0178] In the implementation of the present application, the open source software is the cloud-based open network software SONIC.

[0179] In this implementation, the open source software is SONIC, and the solution provided in this application can improve the reliability and maintainability of SONIC.

[0180] The embodiment of the present application solves the problem of no record of abnormal information caused by locking or hanging in the related art by defining the heartbeat server and the heartbeat client in the open source software to transmit the heartbeat message, and can improve the reliability and maintainability of the open source software. By dumping the call stack information of the heartbeat client in the abnormal state, it is possible to assist in locating the cause of the abnormality.

[0181] Figure 5 1 is a block diagram of a monitoring device of an open source software provided in an embodiment of the present application. The monitoring device of the open source software can be implemented as all or part of a network device through software, hardware or a combination of both. The open source software includes a heartbeat server and a heartbeat client. The device is applied to the heartbeat server. The monitoring device of the open source software may include: a processing unit 501.

[0182] The processing unit 501 is used to determine that the heartbeat client is in an abnormal state when no heartbeat message from the heartbeat client is received within a threshold time. The heartbeat client is a process in a container of open source software.

[0183] Exemplarily, the heartbeat message includes at least one of a service identifier assigned by the heartbeat server to the heartbeat client and an identifier of a process corresponding to the heartbeat client.

[0184] Optionally, the heartbeat message also includes at least one of a priority field and a reserved field.

[0185] Optionally, the device further comprises:

[0186] The storage unit 502 is used to store the call stack information of the heartbeat client. The call stack information is used to analyze the abnormal cause when the heartbeat client is determined to be abnormal.

[0187] Optionally, the information stored by the heartbeat server also includes:

[0188] At least one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client, the state of the heartbeat client, the duration of not receiving the heartbeat message and at least one of the last receiving time of the heartbeat message.

[0189] Optionally, the information stored by the heartbeat server also includes:

[0190] Heartbeat message count value.

[0191] Optionally, the storage unit 502 is used to store the call stack information of the heartbeat client in the remote dictionary server Redis, the key Key in Redis is at least one of the service identifier of the heartbeat client, the identifier of the process corresponding to the heartbeat client, and the name of the process corresponding to the heartbeat client, and the value Value in Redis is the call stack information of the heartbeat client.

[0192] Optionally, the device further comprises:

[0193] The receiving unit 503 is used to receive a registration request from a heartbeat client;

[0194] The processing unit 501 is further configured to allocate a service identifier to the heartbeat client in response to the registration request.

[0195] Exemplarily, the open source software is the cloud-based open network software SONIC.

[0196] In a possible implementation of the present application, the receiving unit 503 may be all or part of the communication module in the heartbeat server. Specifically, the receiving unit 503 may execute Figure 3 The method provided in step S201 and / or step S203 in the corresponding embodiment; the processing unit 501 can be all or part of the timer module in the heartbeat server. Specifically, the processing unit 501 can execute Figure 2 The method provided in step S101 of the corresponding embodiment, or executing Figure 3 The method provided in step S202 and / or step S204 in the corresponding embodiment; the storage unit 502 can be all or part of the storage module in the heartbeat server. Specifically, the storage unit 502 can execute Figure 3 The method provided in step S205 in the corresponding embodiment.

[0197] It should be noted that the open source software monitoring device provided in the above embodiment only uses the division of the above functional units as an example when monitoring the open source software. In actual applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the device can be divided into different functional units to complete all or part of the functions described above. In addition, the open source software monitoring device provided in the above embodiment and the open source software monitoring method embodiment belong to the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0198] The present application also provides a transmission system. The transmission system includes: Figure 5 The monitoring device of the open source software shown. The monitoring device of the open source software can be realized as all or part of the network device through software, hardware or a combination of both. The network device uses open source software as a control system, for example, SONIC as a switch device of the control system.

[0199] Figure 6 A schematic diagram of the structure of a network device 150 provided in an embodiment of the present application is shown. Figure 6 The network device 150 shown is used to perform the above Figure 2 or Figure 3 The operations involved in the monitoring method of the open source software shown. The network device 150 can be implemented by a general bus architecture.

[0200] like Figure 6 As shown, the network device 150 includes at least one processor 151 , a memory 153 , and at least one communication interface 154 .

[0201] The processor 151 is, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the solution of the present application. For example, the processor 151 includes an application-specific integrated circuit (ASIC), a programmable logic device (PLD) or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The PLD is, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. It can implement or execute various logic blocks, modules, and circuits described in conjunction with the disclosure of the embodiments of the present application. The processor can also be a combination that implements a computing function, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and the like.

[0202] Optionally, the network device 150 further includes a bus. The bus is used to transmit information between the components of the network device 150. The bus may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0203] The memory 153 is, for example, a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, or a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 153 is, for example, independent and connected to the processor 151 through a bus. The memory 153 can also be integrated with the processor 151.

[0204] The communication interface 154 uses any transceiver-like device to communicate with other devices or communication networks, and the communication network can be Ethernet, a radio access network (RAN) or a wireless local area network (WLAN), etc. The communication interface 154 may include a wired communication interface and may also include a wireless communication interface. Specifically, the communication interface 154 may be an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a wireless local area network (WLAN) interface, a cellular network communication interface or a combination thereof. The Ethernet interface may be an optical interface, an electrical interface or a combination thereof. In an embodiment of the present application, the communication interface 154 may be used for the network device 150 to communicate with other devices.

[0205] In a specific implementation, as an embodiment, the processor 151 may include one or more CPUs, such as Figure 6 0 and CPU1 shown in FIG. Each of these processors may be a single-CPU processor or a multi-CPU processor. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0206] In a specific implementation, as an embodiment, the network device 150 may include multiple processors, such as Figure 6 1 and 155. Each of these processors may be a single-CPU or a multi-CPU. A processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0207] In a specific implementation, as an embodiment, the network device 150 may also include an output device and an input device. The output device communicates with the processor 151 and can display information in a variety of ways. For example, the output device may be a liquid crystal display (LCD), a light emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device communicates with the processor 151 and can receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensor device.

[0208] In some embodiments, the memory 153 is used to store the program code 1510 for executing the solution of the present application, and the processor 151 can execute the program code 1510 stored in the memory 153. That is, the network device 150 can implement the open source software monitoring method provided by the method embodiment by executing the program code 1510 in the memory 153 through the processor 151. The program code 1510 may include one or more software modules. Optionally, the processor 151 itself may also store the program code or instruction for executing the solution of the present application.

[0209] In a specific embodiment, the network device 150 of the embodiment of the present application may correspond to the controller in each of the above-mentioned method embodiments, and the processor 151 in the network device 151 reads the instruction in the memory 153 so that Figure 6 The illustrated network device 150 is capable of performing all or a portion of the operations performed by a controller.

[0210] Specifically, the processor 151 is used to determine that the heartbeat client is in an abnormal state when the heartbeat server does not receive a heartbeat message from the heartbeat client within a threshold time. The heartbeat client is a process in a container of open source software.

[0211] For the sake of brevity, other optional implementations are not described here in detail.

[0212] in, Figure 2 or Figure 3 Each step of the open source software monitoring method shown is completed by an integrated logic circuit of hardware or software instructions in the processor of the network device 150. The steps of the method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor, or a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory, and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it is not described in detail here.

[0213] The embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory. The input interface, the output interface, the processor and the memory are connected through an internal connection path. The processor is used to execute the code in the memory. When the code is executed, the processor is used to execute any of the above-mentioned open source software monitoring methods.

[0214] It should be understood that the processor may be a CPU, or other general-purpose processors, DSPs, ASICs, FPGAs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the ARM architecture.

[0215] Further, in an optional embodiment, the processor is one or more and the memory is one or more. Optionally, the memory can be integrated with the processor, or the memory and the processor are separately arranged. The memory can include a read-only memory and a random access memory, and provide instructions and data to the processor. The memory can also include a non-volatile random access memory. For example, the memory can also store a reference block and a target block.

[0216] The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may be a ROM, a PROM, an EPROM, an EEPROM, or a flash memory. The volatile memory may be a RAM, which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, SRAM, DRAM, SDRAM, DDR SDRAM, ESDRAM, SLDRAM, and DR RAM.

[0217] In an embodiment of the present application, a computer-readable storage medium is also provided, which stores computer instructions. When the computer instructions stored in the computer-readable storage medium are executed by a network device, the network device executes the open source software monitoring method provided above.

[0218] In an embodiment of the present application, a computer program product including instructions is also provided, which, when executed on a network device, enables the network device to execute the open source software monitoring method provided above.

[0219] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in this application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk), etc.

[0220] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0221] The above are only optional embodiments of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0222] Unless otherwise defined, the technical or scientific terms used herein shall have the usual meanings understood by persons of ordinary skill in the field to which this application belongs. The words "first", "second", "third" and similar words used in the patent application specification and claims of this application do not indicate any order, quantity or importance, but are only used to distinguish different components. Similarly, words such as "one" or "a" do not indicate a quantitative limitation, but rather indicate the presence of at least one. Words such as "include" or "comprise" and similar words mean that the elements or objects appearing before "include" or "comprise" cover the elements or objects listed after "include" or "comprise" and their equivalents, and do not exclude other elements or objects.

[0223] The above is only an embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.< / dotask>

Claims

1. A method for monitoring open source software, characterized in that: The open source software includes a heartbeat server and a heartbeat client, and the method includes: When the heartbeat server does not receive a heartbeat message from the heartbeat client within a threshold time, the heartbeat server determines that the heartbeat client is in an abnormal state, and the heartbeat client is a process in the container of the open source software.

2. The method according to claim 1, characterized in that The heartbeat message includes at least one of a service identifier assigned by the heartbeat server to the heartbeat client and an identifier of a process corresponding to the heartbeat client.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: The heartbeat server stores call stack information of the heartbeat client, and the call stack information is used to analyze the cause of the abnormality when the heartbeat client is determined to be abnormal.

4. The method according to claim 3, characterized in that The information stored in the heartbeat server also includes: At least one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client, the state of the heartbeat client, and at least one of the duration of not receiving the heartbeat message and the last reception time of the heartbeat message.

5. The method according to claim 3 or 4, characterized in that: The heartbeat server stores the call stack information of the heartbeat client, including: The heartbeat server stores the call stack information of the heartbeat client in the remote dictionary server Redis, the key Key in the Redis is at least one of the service identifier of the heartbeat client, the identifier of the process corresponding to the heartbeat client and the name of the process corresponding to the heartbeat client, and the value Value in the Redis is the call stack information of the heartbeat client.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The heartbeat server receives a registration request from the heartbeat client; The heartbeat server allocates a service identifier to the heartbeat client in response to the registration request.

7. The method according to any one of claims 1 to 6, characterized in that: The open source software is the cloud-based open network software SONIC.

8. A monitoring device for open source software, characterized in that: The open source software includes a heartbeat server and a heartbeat client. The device is applied to the heartbeat server. The device includes: The processing unit is used to determine that the heartbeat client is in an abnormal state when no heartbeat message from the heartbeat client is received within a threshold time. The heartbeat client is a process in the container of the open source software.

9. The device according to claim 8, characterized in that The heartbeat message includes at least one of a service identifier assigned by the heartbeat server to the heartbeat client and an identifier of a process corresponding to the heartbeat client.

10. The device according to claim 8 or 9, characterized in that The device also includes: The storage unit is used to store the call stack information of the heartbeat client, and the call stack information is used to analyze the abnormal cause when the heartbeat client is determined to be abnormal.

11. The device according to claim 10, characterized in that The information stored in the heartbeat server also includes: At least one of the service identifier assigned by the heartbeat server to the heartbeat client and the identifier of the process corresponding to the heartbeat client, the state of the heartbeat client, and at least one of the duration of not receiving the heartbeat message and the last reception time of the heartbeat message.

12. The device according to claim 10 or 11, characterized in that The storage unit is used to store the call stack information of the heartbeat client in the remote dictionary server Redis, the key Key in the Redis is at least one of the service identifier of the heartbeat client, the identifier of the process corresponding to the heartbeat client and the name of the process corresponding to the heartbeat client, and the value Value in the Redis is the call stack information of the heartbeat client.

13. The device according to any one of claims 8 to 12, characterized in that The device also includes: A receiving unit, configured to receive a registration request from the heartbeat client; The processing unit is further configured to allocate a service identifier to the heartbeat client in response to the registration request.

14. The device according to any one of claims 8 to 13, characterized in that The open source software is the cloud-based open network software SONIC.

15. A network device, characterized in that: The network device comprises a processor and a memory, wherein the memory is used to store a software program, and the processor runs or executes the software program stored in the memory so that the network device implements the method according to any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store program codes executed by a processor, wherein the program codes include instructions for implementing the method according to any one of claims 1 to 7.

17. A computer program product, characterized in that The computer program product comprises program codes, and when a device runs the computer program product, the device executes the method according to any one of claims 1 to 7.

18. A transmission system, characterized in that: The transmission system comprises the device according to any one of claims 8 to 14.

Images