TWI740886B - Log collection client terminal and its upgrading method - Google Patents

Abstract

The invention discloses a log collection client terminal and an upgrade method thereof. The method first sends a heartbeat request to a configuration server, receives a heartbeat request response returned by the configuration server, and then downloads an upgrade file according to an upgrade instruction carried in the heartbeat request response Pause sending heartbeat requests, and stop collecting new log data, write the collected but not completed log data to the local file, record the current progress point, use the downloaded upgrade file to upgrade, and check whether the upgrade is successful, if the upgrade is successful The log data written into the local file is sent to the data server, and the log data is collected from the recorded progress point, and the work starts with the upgraded version, otherwise, it returns to the pre-upgrade version to work. The log collection client of the present invention includes a heartbeat request module, an upgrade response module, and an upgrade check module. There is no loss of data collection during the upgrading process of the present invention, and the new version of the program can be automatically transferred back when the new version of the program is abnormal.

Description

Log collection client terminal and its upgrading method

The invention belongs to the field of computer technology, and particularly relates to a log collection client terminal and an upgrade method thereof.

With the development of electronic information technology, the era of big data has arrived. Log is a widely distributed and important data resource. Based on the log, system monitoring, operation audit, data analysis and other tasks can be completed. The log collection client is a program running on the equipment operating system, which can read the content of the specified log file according to the collection configuration, and send it to the log server after processing.

In order to avoid the potential risks of known program bugs and provide a better functional experience, the client program often needs to be upgraded to a higher version. However, in actual business scenarios, logs are generated all the time, and client program upgrades inevitably require replacement of executable files and restart of the process. Therefore, it is easy to cause the loss of log collection progress during the upgrade process.

In the existing technical solutions, there are mainly two types of solutions in the industry to solve the problem of upgrading the log collection client. Solution one is a cold upgrade, such as Logstash (version 1.5.4), fluentd (version 2.2.1) and other open source log collection software. The program version upgrade process is divided into three steps: Execute the control script on the device to stop the running old Version schedule; install the new version program file to the device by means of yum or tar package; execute the control script on the device to start the new version schedule and complete the upgrade.

The second solution is a dual program file hot upgrade. This type of client software will run two program files on the device, corresponding to two schedules: one is the log collection schedule, which installs the SIGTERM signal and executes the program exit in the signal processing function The other is to guard the schedule, which is responsible for downloading new program files and completing the switch from the old to the new version. The upgrade process includes four steps: the guardian program detects that a new client program installation package is available in a poll and downloads it to the machine; the guardian program sends a SIGTERM signal to the log collection program; in general, log collection After the itinerary receives the SIGTERM signal, it completes the exit preparation operation and records the log collection progress to the local area and then actively exits. If the exit action of the log collection process times out (for example, the exit preparation operation is not completed one minute after the process accepts SIGTERM), the guard process will issue SIGKILL to force the end of the log collection process.

The guard program detects that the old version of the log collection program has exited, starts the new version of the program and completes the upgrade.

However, the existing cold upgrade solution requires manual participation in the upgrade process, which results in high operation and maintenance costs, and the program upgrade process will forcefully kill the old itinerary and cause the loss of the log collection progress. The program version upgrade will affect the integrity of data collection; if it is new The version program file is not available (such as a crash after startup), and there is no automatic version rollback mechanism. In the existing dual-program hot upgrade solution, the log collection program and the daemon are combined to support automated operation. However, during the upgrade process, the daemon program communicates with the log collection program in one direction through a signal. The log collection program is short after receiving the SIGTERM signal. The time cannot exit normally (for example, the persistence of the log collection progress is not completed), and the guard process will send the SIGKILL signal again after the timeout, and its operation will be forcibly terminated. In this way, the log collection progress before the upgrade cannot be obtained after the new version of the program is started, resulting in the loss of data collection. And after the SIGTERM is issued by the guard schedule, the log collection schedule of the old version exits normally, but the new collection program that is subsequently started fails to start normally, the log collection is interrupted and manual operation and maintenance intervention is required.

The purpose of the present invention is to provide a log collection client and an upgrade method thereof. The program itself can be upgraded through a single program file and double-stroke operation, which solves the problem of data loss that may occur during the upgrade process and the version rollback when the upgrade fails. problem.

In order to achieve the above objectives, the technical solution of the present invention is as follows: a log collection client upgrade method, applied to the log collection client, the method includes: sending a heartbeat request to the configuration server, receiving the heartbeat request response returned by the configuration server; according to the heartbeat The upgrade instruction carried in the request response, download the upgrade file and suspend sending the heartbeat request, and stop collecting new log data, write the collected but not completed log data to the local file, record the current progress point, and use the downloaded upgrade file Perform the upgrade; check whether the upgrade is successful, if the upgrade is successful, send the log data written to the local file to the data server, and collect the log data from the recorded progress point, start working with the upgraded version, otherwise roll back to the upgrade Work on the previous version.

Among them, after the log collection client is started, a guard schedule and a work schedule are created, then a heartbeat request should be sent to the configuration server, including: the work schedule periodically sends a heartbeat request to the configuration server, and the heartbeat request carries the current log collection client The version number of the terminal and the IP address of the host to configure the server to send an empty heartbeat request response without an upgrade API request, and send a heartbeat request response with an upgrade instruction when there is an upgrade API request. The upgrade instruction includes The version number and download address of the client to be upgraded log collection.

Further, the log collection client upgrade method before the upgrade is performed using the downloaded upgrade file, further includes: the work schedule sends a signal SIGUSR1 notifying the upgrade operation to the guard schedule.

Further, the guarding itinerary has the following global status: A, DAEMON_INIT, the guarding itinerary is ready to perform initialization work; B, DAEMON_INIT_FAIL, the guarding itinerary initialization execution fails; C, DAEMON_NORMAL, the guarding itinerary initialization is successfully executed, and the guarding work begins; D, DAEMON_UPDATE , Guardian itinerary is ready to perform program upgrade work; E, DAEMON_UPDATE_FAIL, Guardian itinerary execution program upgrade task failed.

Further, the upgrade using the downloaded upgrade file includes: the guard journey sets the global status to DAEMON_UPDATE after receiving the SIGUSR1 signal; when the guard journey detects that the current global status is DAEMON_UPDATE in the guard loop, the downloaded upgrade file is used to upgrade; The guard schedule sends the SIGKILL signal to the work schedule, and the work schedule exits.

Further, the upgrade using the downloaded upgrade file also includes the steps of: executing the upgraded log collection client program to create the guard schedule and work schedule under the new version; the guard schedule cycle under the new version checks the global status; If the work schedule under the new version exits abnormally after starting, causing the global status to change to DAEMON_UPDATE_FAIL, the notification signal SIGUSR2 will be sent to the guard schedule under the original version with a startup failure message; if the status is found to remain DAEMON_INIT, the new cycle will be updated. If no abnormality occurs in the work schedule under the version, the notification signal SIGUSR2 and the start-up success message are sent to the guard schedule under the original version.

Further, the check whether the upgrade is successful includes: a loop check of the guard trip cycle under the original version is the notification signal SIGUSR2 from the guard trip under the new version; if there is no SIGUSR2 from the guard trip under the new version in the loop cycle, The guard schedule under the original version considers that the start of the new version is timed out and sends a SIGKILL command to the schedule group of the guard schedule under the new version to end the operation of the new program, and then the guard schedule under the original version restarts the work schedule and rolls back to before the upgrade Status; if the SIGUSR2 signal from the guard trip under the new version is received during the loop cycle and a startup failure message is obtained, the guard trip under the original version sends the SIGKILL command to the trip group of the guard trip under the new version to end the new program After that, the guard trip under the original version restarts the work schedule and returns to the pre-upgrade state; if the SIGUSR2 signal from the guard trip under the new version is received during the loop cycle and the startup success message is obtained, the original version is downloaded The guardian program exited and the upgrade was successful.

The present invention also proposes a log collection client, the log collection client includes: a heartbeat request module for sending a heartbeat request to the configuration server, and receiving a heartbeat request response returned by the configuration server; an upgrade response module for According to the upgrade instructions carried in the heartbeat request response, download the upgrade file and suspend sending the heartbeat request and stop collecting new log data, write the collected but not completed log data to the local file, record the current progress point, and use the downloaded upgrade The file is upgraded; the upgrade check module is used to check whether the upgrade is successful, if the upgrade is successful, the log data written to the local file is sent to the data server, and the log data is collected from the recorded progress point to the upgraded version Start to work, otherwise fall back to the version before the upgrade to work.

Further, after the log collection client is started, it creates a guard schedule and a work schedule. When the heartbeat request module sends a heartbeat request to the configuration server, it performs the following operations: the work schedule periodically sends a heartbeat request to the configuration server. The heartbeat request carries the version number of the current log collection client and the IP address of the host, so that the configuration server sends an empty heartbeat request response without an upgrade API request, and sends an upgrade instruction if there is an upgrade API request In response to the heartbeat request, the upgrade instruction includes the version number of the log collection client to be upgraded and its download address.

Further, before the upgrade response module uses the downloaded upgrade file to upgrade, it also performs the following operations: the work schedule sends a signal SIGUSR1 to the guard schedule to notify the upgrade operation.

Further, the guarding itinerary has the following global status: A, DAEMON_INIT, the guarding itinerary is ready to perform initialization work; B, DAEMON_INIT_FAIL, the guarding itinerary initialization execution fails; C, DAEMON_NORMAL, the guarding itinerary initialization is successfully executed, and the guarding work begins; D, DAEMON_UPDATE , Guardian itinerary is ready to perform program upgrade work; E, DAEMON_UPDATE_FAIL, Guardian itinerary execution program upgrade task failed.

Further, when the upgrade response module uses the downloaded upgrade file to upgrade, it performs the following operations: After the guard program receives the SIGUSR1 signal, it sets the global state to DAEMON_UPDATE; when the guard program detects that the current global state is DAEMON_UPDATE in the guard loop, Use the downloaded upgrade file to upgrade; the guard schedule sends a SIGKILL signal to the work schedule, and the work schedule exits.

Further, when the upgrade response module uses the downloaded upgrade file to upgrade, it also performs the following operations: executes the upgraded log collection client program, creates the guard schedule and the work schedule under the new version; the guard schedule under the new version Periodic loop detection of the global status; if the work schedule under the new version exits abnormally after starting, causing the global status to change to DAEMON_UPDATE_FAIL, the notification signal SIGUSR2 will be sent to the guard schedule under the original version with a startup failure message; if the status is found to remain as DAEMON_INIT, there is no abnormality in the work schedule under the new version in the loop cycle, then the notification signal SIGUSR2 and the start success message are sent to the guard schedule under the original version.

Further, when the upgrade check module checks whether the upgrade is successful, it performs the following operations: The guard trip cycle of the original version loops to check the notification signal SIGUSR2 from the guard trip of the new version; if there is no signal from the new version in the loop cycle For the SIGUSR2 of the guardian schedule under the version, the guardian schedule under the original version thinks that the start of the new version is timed out and sends a SIGKILL command to the schedule group of the guardian schedule under the new version to end the operation of the new program, and then the guardian schedule under the original version restarts Work schedule and roll back to the state before the upgrade; if you receive the SIGUSR2 signal from the guard schedule under the new version and get the start failure message during the loop cycle, the guard schedule under the original version will be transferred to the guard schedule under the new version. The group sends the SIGKILL command to end the operation of the new program, and then the guard schedule under the original version restarts the working schedule and returns to the pre-upgrade state; if the SIGUSR2 signal from the guard schedule under the new version is received during the loop cycle and gets If the startup message is successful, the guard program under the original version exits, and the upgrade is successful.

The log collection client terminal and its upgrade method proposed by the present invention require no manual operation and maintenance intervention during the upgrade process. During the upgrade process, the parent-child journey communicates bidirectionally, and the upgrade operation is performed after consensus. The data before and after the upgrade is not lost; if the new program starts abnormally, Guardian itinerary can quickly discover and automatically perform version rollback operations.

S1‧‧‧Step

S2‧‧‧Step

S3‧‧‧Step

Fig. 1 is a flowchart of the method for upgrading a log collection client of the present invention; Fig. 2 is a flowchart of the operation of the original version of the client of the present invention; Fig. 3 is a flowchart of the operation of a new version of the client of the present invention; Fig. 4 is the structure of the log collection client of the present invention Schematic.

The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments, and the following embodiments do not constitute a limitation to the present invention.

The log system generally includes a log collection client Client installed on the host, a configuration server ConfigServer used to manage log collection clients running on all hosts, and a data server DataServer that receives log data collected by the log collection client. The host is the device that the log system needs to record logs, and a log collection client is installed on each host.

After the host's log collection client is started, two processes start to run, one is the daemon process DaemonProcess, and the other is the work process WorkerProcess. When starting the record collection client, first create the parent process DaemonProcess, and then call the system call fork to create the child process WorkerProcess. The worker process sub-process collects the content of the specified log file according to the user's collection configuration and sends it to the data server through the network. At the same time, the worker process sub-process also sends a heartbeat request to the configuration server at a fixed time (for example, 1 minute), and responds to the heartbeat request. To accept the command to configure the server. The parent process DaemonProcess is a guard process, and the child process is restarted when the WorkerProcess is found to exit unexpectedly, and the upgrade process is triggered when the Client version upgrade instruction is found.

As shown in Figure 1, a method for upgrading a log collection client in this embodiment is applied to the log collection client and includes:

Step S1: Send a heartbeat request to the configuration server, and receive a heartbeat request response returned by the configuration server.

After the Client on the host is started, WorkerProcess sends a heartbeat request to ConfigServer every 1 minute. The request content includes the current program file version number v_1 and host ip_1. When there is no upgrade operation, ConfigServer returns empty content to WorkerProcess in the response to the heartbeat request.

Assuming that there is a new Client version v_2 for the host ip_1, the operation and maintenance personnel sends a request to ConfigServer through the upgrade API. After receiving the upgrade API request, ConfigServer sets the status of the host ip_1: current version v_1, version v_2 to be upgraded.

Then ConfigServer returns an upgrade instruction in the response to the heartbeat request. The upgrade instruction includes the v_2 version number, the v_2 program upgrade file (HTTP download address), and the md5sum of the executable file.

Step S2, according to the upgrade instruction carried in the heartbeat request response, suspend sending the heartbeat request and stop collecting new log data, write the collected log data into a local file, record the current progress point, download the upgrade file to start the upgrade.

For ease of description, this embodiment refers to the log collection client of version v_1 as ClientV1, and its two corresponding processes are WorkerProcessV1 and DaemonProcessV1. The log collection client upgraded to version v_2 is called ClientV2, and its corresponding two processes are WorkerProcessV2 and DaemonProcessV2.

After ClientV1 runs, when WorkerProcessV1 finds that there is an upgrade instruction in the response to the heartbeat request, it starts to prepare for the upgrade operation: download the program upgrade file to the local machine, unzip it and verify the executable file md5sum.

Stop reading new log data.

The log data that has been read in the memory is parsed and written to the local file BuffeFile. The log data written to BuffeFil is the log data that has been collected but not yet sent. BufferFile will be sent by ClientV2 to the DataServer after the upgrade is completed. Writing BufferFile can greatly reduce the problem of long upgrade time caused by network transmission delay.

Record the progress point CheckPoint. Log collection is progressing, CheckPoint saves the state and persists to the file. The content includes: log directory, log file case name, log file signature, and the location where the log file is currently collected.

WorkerProcessV1 sends SIGUSR1 to DaemonProcessV1 to notify the upgrade operation.

In this embodiment, for the DaemonProcess process, five global states are defined, which are used to represent the process state of the DaemonProcess, which are:

1. DAEMON_INIT

DaemonProcess is ready to perform initialization work.

2. DAEMON_INIT_FAIL

DaemonProcess initialization failed.

3. DAEMON_NORMAL

DaemonProcess initialization and execution are successful, and start guarding work.

4. DAEMON_UPDATE

DaemonProcess is ready to perform program upgrade work.

5. DAEMON_UPDATE_FAIL

DaemonProcess failed to execute program upgrade.

At the same time, DaemonProcess has the following signal processing functions:

1) SIGCHLD signal processing function of DaemonProcess.

The SIGCHLD signal indicates that its sub-stroke WorkerProcess exits abnormally. If the global status is DAEMON_INIT, the status changes to DAEMON_INIT_FAIL.

2) SIGUSR1 signal processing function of DaemonProcess.

The customized SIGUSR1 in this embodiment is a signal sent by WorkerProcess to DaemonProcess to notify the upgrade operation, and DaemonProcess sets the global status to DAEMON_UPDATE after receiving the signal.

3) SIGUSR2 signal processing function of DaemonProcess

In this embodiment, the customized SIGUSR2 is a signal sent to the old version of DaemonProcess from the new version of DaemonProcess initiated by the upgrade. If the signal is accompanied by a message DaemonStartSuccess (the new version of DaemonProcess, WorkerProcess starts successfully), DaemonProcess exits actively; if the signal message is DaemonStartFail (the new version of DaemonProcess or WorkerProcess fails to start), the global status of DaemonProcess is set to DAEMON_UPDATE_FAIL.

4. SIGKILL, after sending SIGKILL to the itinerary, the itinerary that receives the signal terminates its operation.

Therefore, after WorkerProcessV1 sends SIGUSR1 to DaemonProcessV1, DaemonProcessV1 processes the SIGUSR1 signal and enters an interrupt. The signal processing function sets the global state to DAEMON_UPDATE.

As shown in Figure 2, after ClientV1 is started, it sets DaemonProcessV1 to DAEMON_INIT state and installs the SIGCHLD signal, then forks WorkerProcessV1 for log collection loops, DaemonProcessV1 installs the SIGUSR1 signal, and sets the state to DAEMON_NORMAL. When ConfigServer carries the upgrade command in the response to the heartbeat request, WorkerProcessV1 sends SIGUSR1 to DaemonProcessV1, and DaemonProcessV1 detects that the current global status is DAEMON_UPDATE in the guard loop and starts the upgrade.

DaemonProcessV1 sends SIGKILL to WorkerProcessV1. At this time, the memory queue of WorkerProcessV1 is empty, and then WorkerProcessV1 exits without data loss.

DaemonProcessV1 installs SIGUSR2 signal: if the installation fails, set the current status to DAEMON_NORMAL and perform a rollback, re-fork out WorkerProcessV1 to run, end the upgrade operation and return to the pre-upgrade state; if the installation of SIGUSR2 is successful, fork a sub-stroke, in the sub-stroke Run the new version of the program file ClientV2 in the current travel space, and start looping to check whether the upgrade is successful.

Step S3. Check whether the upgrade is successful. If the upgrade is successful, send the log data written to the local file to the data server, and collect the log data from the recorded progress point, and start working with the upgraded version, otherwise, roll back to the upgrade The previous version.

As shown in Figure 3, after executing the new version of the program file ClientV2, DaemonProcessV2 performs initialization work.

Set the current status to DAEMON_INIT.

Install SIGUSR2 signal and SIGCHLD signal.

DaemonProcessV2 forks WorkerProcessV2 to execute, and enters a 5-second loop wait. DaemonProcessV2 detects the global status: if it finds that the status changes to DAEMON_INIT_FAIL (WorkerProcessV2 exits abnormally after starting, the interrupt processing SIGCHLD signal causes global status changes), then it sends the signal SIGUSR2 to DaemonProcessV1, Attach the message DaemonStaftFail.

If it is found that the status remains as DAEMON_INIT, and no abnormality occurs in WorkerProcessV2 within 5 seconds, the SIGUSR2 signal and the message DaemonStartSuccess will be sent to DaemonProcessV1.

Continuing to Figure 2, and DaemonProcessV1 waits for 15 seconds to check the signal from DaemonProcessV2. There are three situations: if there is no SIGUSR2 from DaemonProcessV2 within 15 seconds, DaemonProcessV1 thinks that the start of the new version has timed out and sends a SIGKILL command to DaemonProcessV2's trip group to end the operation of the new program. Then DaemonProcessV1 restarts WorkerProcessV1 and returns to the pre-upgrade state.

If the SIGUSR2 signal is received within 15 seconds and the message DaemonStartFail is received, DaemonProcessV1 sends a SIGKILL command to the trip group of DaemonProcessV2 to end the operation of the new program, and then DaemonProcessV1 restarts WorkerProcessV1 and returns to the pre-upgrade state. That is, DaemonProcessV1 will clean up ClientV2's itinerary group and fall back to V1 to work.

If the SIGUSR2 signal is received within 15 seconds and the message DaemonStartSuccess is received, DaemonProcessV1 will execute exit, that is, DaemonProcessV1 will exit actively after receiving the signal. After DaemonProcessV1 exits, DaemonProcessV2 and WorkerProcessV2 will take over completely, and the upgrade will be completed. After that, there are only two versions of V2. The itinerary runs on the machine and the upgrade process ends successfully.

The log collection client of the present invention is deployed on hundreds of thousands of servers, and the upgrade of all machine client versions can be completed in 10 minutes through the upgrade API. The client upgrade of a single machine can generally be completed within 5 seconds. There is no loss of data collection during the process, and the new version of the program can be automatically transferred back when the new version of the program is abnormal.

As shown in FIG. 4, a log collection client of this embodiment includes a heartbeat request module, an upgrade response module, and an upgrade check module. The log collection client of this embodiment is installed on the host to collect log data and interact with the configuration server to complete the program upgrade.

Among them, the heartbeat request module is used to send a heartbeat request to the configuration server and receive the heartbeat request response returned by the configuration server; the upgrade response module is used to download the upgrade file and suspend sending according to the upgrade instruction carried in the heartbeat request response Heartbeat request and stop collecting new log data, write log data that has been collected but not yet sent to a local file, record the current progress point, and use the downloaded upgrade file to upgrade; upgrade check module is used to check whether the upgrade is successful, If the upgrade is successful, the log data written to the local file will be sent to the data server, and the log data will be collected from the recorded progress point, and work with the upgraded version, otherwise it will fall back to the pre-upgrade version to work.

After the log collection client of this embodiment is started, a guard schedule and a work schedule are created. The following describes the operations performed by each module during the upgrade process.

When the heartbeat request module sends a heartbeat request to the configuration server, it performs the following operations: the work schedule sends a heartbeat request to the configuration server periodically, and the heartbeat request carries the version number of the current log collection client and the IP address of the host for configuration The server sends an empty heartbeat request response without an upgrade API request, and sends a heartbeat request response with an upgrade instruction if there is an upgrade API request. The upgrade instruction includes the version number of the client to be upgraded log collection and its download address .

In this embodiment, before the upgrade response module uses the downloaded upgrade file to upgrade, it also performs the following operations: the work schedule sends the guard schedule a signal SIGUSR1 notifying the upgrade operation.

In this embodiment, when the upgrade response module uses the downloaded upgrade file to upgrade, it performs the following operations: After the guard program receives the SIGUSR1 signal, it sets the global state to DAEMON_UPDATE; when the guard program detects that the current global state is DAEMON_UPDATE in the guard loop , Use the downloaded upgrade file to upgrade; the guard schedule sends a SIGKILL signal to the work schedule, and the work schedule exits.

In this embodiment, when the upgrade response module uses the downloaded upgrade file to upgrade, it also performs the following operations: executes the upgraded log collection client program, creates the guard schedule and work schedule under the new version; the guard under the new version The travel cycle loops to detect the global status; if the work travel under the new version exits abnormally after starting, causing the global status to change to DAEMON_UPDATE_FAIL, then the notification signal SIGUSR2 is sent to the guard travel under the original version with a startup failure message; if the status remains For DAEMON_INIT, if there is no abnormality in the work schedule of the new version in the loop cycle, the notification signal SIGUSR2 and the startup success message are sent to the guard schedule of the original version.

In this embodiment, when the upgrade check module checks whether the upgrade is successful, it performs the following operations: the guard trip cycle under the original version loops to check the notification signal SIGUSR2 from the guard trip under the new version; For the SIGUSR2 of the guard schedule under the new version, the guard schedule under the original version considers that the start of the new version has timed out and sends a SIGKILL command to the schedule group of the guard schedule under the new version to end the operation of the new program, and then the guard schedule under the original version restarts Turn on the working schedule and return to the state before the upgrade; if you receive the SIGUSR2 signal from the guard schedule under the new version and get the start failure message during the loop cycle, the guard schedule under the original version will go to the guard schedule under the new version The trip group sends the SIGKILL command to end the operation of the new program, and then the guard trip under the original version restarts the working trip and returns to the pre-upgrade state; if the SIGUSR2 signal from the guard trip under the new version is received during the loop cycle and If you get the startup success message, the guard program in the original version exits, and the upgrade is successful.

The above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit them. Without departing from the spirit and essence of the present invention, those skilled in the art can make various corresponding changes and modifications according to the present invention. , But these corresponding changes and deformations should belong to the scope of protection of the attached patent application of the present invention.

Claims (4)

A log collection client upgrade method, applied to a log collection client, is characterized in that the method includes: after the log collection client is started, a first guarding process and a first working process are created, and the first guarding process has the following Global status: A, DAEMON_INIT, the guard process is ready to perform initialization work; B, DAEMON_INIT_FAIL, the guard process initialization fails; C, DAEMON_NORMAL, the guard process is initialized successfully, and the guard begins; D, DAEMON_UPDATE, the guard process is ready to perform program upgrades ; E, DAEMON_UPDATE_FAIL, the upgrade of the guard program execution program failed; the first working program periodically sends a heartbeat request to the configuration server, receives the heartbeat request response returned by the configuration server, and downloads the upgrade file according to the upgrade command carried in the heartbeat request response And suspend sending heartbeat requests, and stop collecting new log data, write the collected but not completed log data to the local file, record the current progress point, download the upgrade file to the local; the first work schedule is the first guard schedule Send out the signal SIGUSR1 to notify the upgrade operation. After receiving the SIGUSR1 signal, the first guard trip sets the global status to DAEMON_UPDATE; When the first guardian program detects that the current global status is DAEMON_UPDATE in the guardian loop, the downloaded upgrade file is used to upgrade; the first guardian program sends a SIGKILL signal to the first working program, and the first working program exits; after executing the upgrade Log collection client program to create the new version of the second guard trip and the second work schedule; the second guard trip cycle loops to detect the global status; if the second work process exits abnormally after the start, the global status changes to DAEMON_UPDATE_FAIL , The notification signal SIGUSR2 is sent to the first guard trip under the original version, with a startup failure message; if the status is found to remain DAEMON_INIT, and there is no abnormality in the second work trip under the new version in the loop cycle, the notification signal is sent SIGUSR2 and the startup success message are sent to the first guard trip under the original version; the first guard trip cycle under the original version loops to check the notification signal SIGUSR2 from the second guard trip under the new version; if there is no signal from the new guard trip during the cycle The SIGUSR2 of the second guardian course under the version, the first guardian course under the original version thinks that the start of the new version has timed out and sends a SIGKILL command to the course group of the second guardian course under the new version to end the operation of the new program, and then the original version Restart the first working trip and return to the state before the upgrade; if you receive the SIGUSR2 signal from the second guard trip under the new version and get the start failure message during the loop cycle, the original version will be downloaded The first guardian itinerary of the new version sends a SIGKILL command to the itinerary group of the second guardian itinerary under the new version to end the operation of the new program, and then the first The guard trip restarts the first working trip and returns to the state before the upgrade; if the SIGUSR2 signal from the second guard trip under the new version is received during the loop cycle and the start-up success message is obtained, the first guard in the original version The itinerary exited and the upgrade was successful. According to the log collection client upgrade method described in item 1 of the scope of patent application, the heartbeat request carries the version number of the current log collection client and the IP address of the host, so that the configuration server can be configured without an API request to upgrade Send an empty heartbeat request response, and if there is an upgrade API request, send a heartbeat request response carrying an upgrade instruction. The upgrade instruction includes the version number of the client to be upgraded log collection and its download address. A log collection client is characterized in that the log collection client performs the following operations: after the log collection client is started, a first guardian schedule and a first working schedule are created, and the first guardian schedule has the following global status: A , DAEMON_INIT, guard itinerary is ready to execute initialization work; B, DAEMON_INIT_FAIL, guard itinerary initialization execution failed; C, DAEMON_NORMAL, guard itinerary initialization is successfully executed, and start guarding work; D, DAEMON_UPDATE, guarding itinerary is ready to execute program upgrade work; E, DAEMON_UPDATE_FAIL , The upgrade of the guard program execution program failed; The first work schedule periodically sends heartbeat requests to the configuration server, receives the heartbeat request response returned by the configuration server, downloads the upgrade file and suspends sending the heartbeat request according to the upgrade instructions carried in the heartbeat request response, and stops collecting new log data , Write the collected but not completed log data to the local file, record the current progress point, download the upgrade file to the local; the first work process sends the first guard process the signal SIGUSR1 to notify the upgrade operation, and the first guard process receives After the SIGUSR1 signal, set the global status to DAEMON_UPDATE; when the first guardian program detects that the current global status is DAEMON_UPDATE in the guardian loop, the downloaded upgrade file is used to upgrade; the first guardian program sends the SIGKILL signal to the first working schedule, Exit the first work schedule; execute the upgraded log collection client program to create the second guard schedule and the second work schedule under the new version; the second guard schedule cycles to check the global status; if the second work schedule starts Abnormal exit, causing the global status to change to DAEMON_UPDATE_FAIL, then send the notification signal SIGUSR2 to the first guard trip under the original version, with a startup failure message; if the status is found to remain DAEMON_INIT, the second work schedule under the new version in the loop cycle If no abnormality occurs, the notification signal SIGUSR2 and the start success message are sent to the first guard trip under the original version; the first guard trip cycle under the original version loops to check the notification signal SIGUSR2 from the second guard trip under the new version; If there is no SIGUSR2 from the second guard trip under the new version in the loop cycle, the first guard trip under the original version considers that the start of the new version has timed out and sends a SIGKILL command to the trip group of the second guard trip under the new version. End the operation of the new program, and then restart the first working stroke under the first guard stroke in the original version and return to the state before the upgrade; if the SIGUSR2 signal from the second guard stroke in the new version is received during the loop cycle, and If the startup failure message is obtained, the first guard trip under the original version sends a SIGKILL command to the trip group of the second guard trip under the new version to end the operation of the new program, and then the first guard trip under the original version restarts the first job The itinerary and roll back to the state before the upgrade; if the SIGUSR2 signal from the second guardian course under the new version is received during the cycle and the start success message is obtained, the first guardian course under the original version exits and the upgrade is successful. According to the log collection client described in item 3 of the scope of patent application, the heartbeat request carries the version number of the current log collection client and the IP address of the host, so that the configuration server can send a blank without an upgrade API request. If there is an upgrade API request, it sends a heartbeat request response carrying an upgrade instruction. The upgrade instruction includes the version number of the log collection client to be upgraded and its download address.

Images