Remote log sending method and device for syslog-ng
By configuring the remote log sending method of the syslog-ng application, using VRF to bind socket sockets, the problem of incorrect log transmission in the network isolation environment is solved, and the flexibility and reliability of logs are achieved to ensure that the logs are restarted on the device can be sent remotely correctly.
Patent Information
- Application Number
- CN202410858223.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-28
- Publication Date
- 2025-01-10
AI Technical Summary
Traditional syslog-ng applications cannot support virtual routing forwarding instances (VRFs) in network isolation environments, resulting in the inability to bind logs to specific VRFs for remote transmission, resulting in incorrect log transmission.
By configuring the relevant information sent by remote logs, including server address, port number, protocol type and VPN instance, generate remote send log configuration files, and bind socket sockets to VPN instances, save them to socket parameter link list to realize log routing Quarantine send.
The correct transmission of logs is realized in a network isolation environment, which enhances the flexibility and reliability of the log system, solves the problem that logs cannot be sent to the corresponding network, and ensures that the logs can be sent correctly and remotely when the device restarts.
Smart Images

Figure CN119299296A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer information processing, and in particular to a remote log sending method and device for syslog-ng. Background Art
[0002] With the advancement of network technology, many application scenarios have put forward higher requirements for network equipment. One of the important requirements is network isolation. Network isolation means separating different networks on the same device so that they do not interfere with each other. To this end, we will create multiple different virtual routing forwarding instances (VRFs) on network devices. Each VRF is like an independent small network with its own exclusive routing table and physical interface. In this way, data from different businesses can be sent to the corresponding servers for processing through different VRFs, ensuring that each business does not interfere with each other. For example, there are multiple independent companies in an office building, each company has its own network system and network equipment, and they do not interfere with each other.
[0003] However, the traditional syslog-ng application cannot support this VRF function, and it cannot bind the log to a specific VRF for remote transmission. This is like you want to send each company's security records to their respective security companies, but the existing system can only send them to one company. How to make the syslog-ng application support binding VRF and send the logs to different remote servers is an urgent problem to be solved.
[0004] The above information disclosed in the Background section is only for enhancement of understanding of the background of the present application and therefore it may contain information that does not constitute the prior art that is already known to a person of ordinary skill in the art. Summary of the invention
[0005] In view of this, the present application provides a remote log sending method and device for syslog-ng, which can realize remote log sending based on VRF, ensure the correct transmission of device logs in a network isolation environment, and enhance the flexibility and reliability of the log system.
[0006] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.
[0007] According to one aspect of the present application, a remote log sending method for syslog-ng is proposed, the method comprising: configuring relevant information for remote log sending, the relevant information comprising: server address, port number, protocol type, VPN instance; generating a remote log sending configuration file according to the relevant information; the syslog-ng system rereads the remote log sending configuration file; the syslog-ng system binds the socket socket and the VPN instance, and saves them to a socket parameter linked list; and sending logs through the socket parameter linked list to implement log routing isolation sending.
[0008] In an exemplary embodiment of the present application, generating a remote sending log configuration file according to the relevant information includes: receiving the relevant information in a background; and generating the remote sending log configuration file according to the relevant information.
[0009] In an exemplary embodiment of the present application, the syslog-ng system rereads the remote sending log configuration file, including: restarting the syslog-ng system so that the syslog-ng system rereads the remote sending log configuration file.
[0010] In an exemplary embodiment of the present application, the syslog-ng system binds a socket socket and a VPN instance and saves them to a socket parameter list, including: the syslog-ng system creates a socket socket; parses the remote sending log configuration file to obtain a VPN instance; binds the socket socket and the VPN instance, and saves them to a socket parameter list.
[0011] In an exemplary embodiment of the present application, the socket socket and the VPN instance are bound and saved to a socket parameter linked list, including: binding the socket socket and the VPN instance; saving the socket socket file descriptor to the socket parameter linked list of the remote sending log configuration file.
[0012] In an exemplary embodiment of the present application, it also includes: configuring a log sending function during device startup; based on the function, creating a thread processing function during the startup or recovery process of the device; the thread processing function periodically traverses the socket parameter linked list to generate log content; and writing the log content into the log of the sockfd parameter sending restart phase.
[0013] In an exemplary embodiment of the present application, the thread processing function periodically traverses the socket parameter linked list to generate log content, including: the thread processing function periodically traverses the socket parameter linked list to obtain socket parameters; based on the socket parameters, the log content is generated by splicing in a preset format.
[0014] In an exemplary embodiment of the present application, the thread processing function regularly traverses the socket parameter linked list to obtain the socket parameters, including: the thread processing function has a timer, and regularly traverses the socket parameter linked list to obtain the socket parameters within a preset time.
[0015] In an exemplary embodiment of the present application, the log content is written into the log of the sockfd parameter sending restart phase, including: writing the log content into the log of the sockfd parameter sending restart phase; adding a mutex lock to the log in the socket parameter linked list; after the log is sent, deleting and unlocking the log in the socket parameter linked list.
[0016] According to one aspect of the present application, a remote log sending device for syslog-ng is proposed, and the device includes: a configuration module, which is used to configure relevant information for remote log sending, and the relevant information includes: server address, port number, protocol type, VPN instance; a file module, which is used to generate a remote log sending configuration file according to the relevant information; a rereading module, which is used for the syslog-ng system to reread the remote log sending configuration file; a binding module, which is used for the syslog-ng system to bind the socket socket and the VPN instance, and save it to the socket parameter linked list; a sending module, which is used to send logs through the socket parameter linked list to realize log routing isolation sending.
[0017] According to one aspect of the present application, an electronic device is proposed, which includes: one or more processors; a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described above.
[0018] According to one aspect of the present application, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, the method described above is implemented.
[0019] According to the remote log sending method and device for syslog-ng of the present application, by configuring the relevant information of remote log sending, the relevant information includes: server address, port number, protocol type, VPN instance; generating a remote log sending configuration file according to the relevant information; the syslog-ng system rereads the remote log sending configuration file; the syslog-ng system binds the socket socket and the VPN instance, and saves them to the socket parameter linked list; sending logs through the socket parameter linked list to realize the log routing isolation sending mode, which can realize remote log sending based on VRF, ensure the correct transmission of device logs in a network isolation environment, and enhance the flexibility and reliability of the log system.
[0020] It should be understood that the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The above and other objects, features and advantages of the present application will become more apparent by describing in detail the exemplary embodiments thereof with reference to the accompanying drawings. The accompanying drawings described below are only some embodiments of the present application, and it is clear to a person skilled in the art that other accompanying drawings can be obtained from these accompanying drawings without creative effort.
[0022] Figure 1 The figure is a flowchart of a remote log sending method for syslog-ng according to an exemplary embodiment.
[0023] Figure 2 The figure is a flowchart of a remote log sending method for syslog-ng according to an exemplary embodiment.
[0024] Figure 3 The figure is a flow chart showing a remote log sending method for syslog-ng according to another exemplary embodiment.
[0025] Figure 4 The figure is a flow chart showing a remote log sending method for syslog-ng according to another exemplary embodiment.
[0026] Figure 5 The figure is a block diagram showing a remote log sending device for syslog-ng according to an exemplary embodiment.
[0027] Figure 6 is a block diagram showing a remote log sending device for syslog-ng according to another exemplary embodiment.
[0028] Figure 7It is a block diagram of an electronic device according to an exemplary embodiment.
[0029] Figure 8 It is a block diagram of a computer-readable medium according to an exemplary embodiment. DETAILED DESCRIPTION
[0030] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this application will be comprehensive and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The same reference numerals in the figures represent the same or similar parts, and thus their repeated description will be omitted.
[0031] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present application. However, those skilled in the art will appreciate that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, known methods, devices, realizations or operations are not shown or described in detail to avoid blurring the various aspects of the application.
[0032] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.
[0033] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.
[0034] It should be understood that although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another component. Therefore, the first component discussed below can be referred to as the second component without departing from the teachings of the concepts of the present application. As used herein, the term "and / or" includes any one of the associated listed items and all combinations of one or more.
[0035] Those skilled in the art will appreciate that the drawings are merely schematic diagrams of example embodiments, and the modules or processes in the drawings are not necessarily necessary for implementing the present application, and therefore cannot be used to limit the scope of protection of the present application.
[0036] The technical abbreviations involved in this application are explained as follows:
[0037] Syslog-ng application: is a flexible and highly scalable logging application that can store messages on the local hard disk. When a connection is established with the server, the syslog-ng application sends the stored messages to the server in the order in which the messages are received.
[0038] VRF: Virtual Routing Forwarding, VPN routing forwarding table, also known as VPN-instance. There can be multiple routing tables in one device. Each routing table is independent of each other and the network segments can be the same.
[0039] Socket: Also commonly known as "socket", it is the basic operating unit of network communication that supports the TCP / IP protocol. It can be regarded as the endpoint of each communication connection when two network applications communicate, and contains two parts: IP address and port.
[0040] In view of the difficulties in the prior art, this application aims to solve two main problems of syslog-ng remote log sending. First, when network devices are in an environment where network isolation is required, remote log sending cannot be specified to the corresponding network for sending. Second, when the device is restarted, the relevant routing configuration is not restored, resulting in network disconnection. The logs generated when the device restarts cannot be sent remotely to the server. At this stage, the server receives fewer logs than the local logs of the device.
[0041] The contents of this application are described in detail below through specific embodiments.
[0042] Figure 1 The flowchart of a remote log sending method for syslog-ng according to an exemplary embodiment is shown. The remote log sending method 10 for syslog-ng at least includes steps S102 to S110.
[0043] like Figure 1 As shown, in S102, the relevant information for sending remote logs is configured, and the relevant information includes: server address, port number, protocol type, and VPN instance.
[0044] The device command line / WEB service program obtains the server IP address src_ip required for remotely sending logs, the server log receiving port number port, the protocol type iptype, and the vrf used by the device to remotely send logs.
[0045] In one embodiment, the administrator can first obtain the IP address of the remote log server, determine the port number that the remote server listens on, select the transport protocol to be used (UDP or TCP), and determine the name of the virtual routing forwarding (VRF) instance on the device used to send logs.
[0046] After that, the administrator can use the device's command line interface or web service program to log in to the device's management interface. In the device's command line interface or web interface, find the corresponding log configuration option. Enter the remote log server's IP address, port number, transport protocol, and VRF name. After confirming that the entered configuration information is correct, save the configuration changes.
[0047] In S104, a remote log sending configuration file is generated according to the relevant information. The system automatically generates a configuration file according to the configuration information input by the administrator, which includes the relevant configuration of the destination and the log source.
[0048] For example, the background receives the relevant information and generates the remote sending log configuration file according to the relevant information. After receiving the configuration, the background generates the remote sending log configuration file and causes the syslog-ng process to reread the configuration file.
[0049] More specifically, the configuration of the destination and log fields can be modified in the configuration file. The destination field mainly saves the configuration of the server, and the vrf is compiled into the destination name field. The destination also contains the localip field corresponding to the server's IP address, the port field corresponding to the server's log receiving port, the udp / tcp field corresponding to the protocol type, and the template field corresponding to the log format. The log field contains the source of the local log and the relevant configuration parameters of the server, destination. The administrator needs to provide the IP address of the remote log server, the port number that the server listens on, and the selected transmission protocol (usually UDP or TCP). In addition, it is necessary to specify the virtual routing forwarding (VRF) instance on the device for sending logs. Once these parameters are received and configured by the device, a configuration file will be generated, which mainly modifies the configuration of the destination and log fields.
[0050] In the configuration file, the destination field is used to define the destination of the log, including the server's configuration information, such as the server's IP address, port number, protocol type used, and log format template. The log field specifies the source of the local log and the related configuration parameters sent to the server.
[0051] For example, suppose there is a network device that needs to send logs to a remote server with IP address 192.168.1.100 and port 514, using UDP protocol and using VRF logs_vrf. The configuration file will contain entries similar to the following:
[0052] In the destination field, a destination named logs_vrf is defined, which contains the relevant configuration information of the remote server, such as the local IP address, port number, protocol used, and log format.
[0053] In the log field, the source of the log is specified as the local device and the log is sent to the logs_vrf destination defined previously.
[0054] In S106, the syslog-ng system rereads the remote sending log configuration file. For example, the syslog-ng system may be restarted to make the syslog-ng system reread the remote sending log configuration file.
[0055] More specifically, it can be set that every time the administrator sends a configuration through the command line or WEB service program, it will trigger the restart of the syslog-ng application and the rereading of the configuration file.
[0056] In S108, the syslog-ng system binds the socket and the VPN instance and saves them to the socket parameter list. For example, the syslog-ng system creates a socket; parses the remote sending log configuration file to obtain the VPN instance; binds the socket and the VPN instance and saves them to the socket parameter list.
[0057] The step of binding the socket to the VPN instance and saving the binding to a socket parameter linked list includes: binding the socket to the VPN instance; and saving the socket file descriptor to the socket parameter linked list of the remotely sent log configuration file.
[0058] More specifically, during the startup of the syslog-ng application, a socket is first created for communication with the remote server. Then, it parses the destination field in the configuration file to obtain the corresponding VRF information. Next, the socket is bound to the corresponding VRF. At the same time, parameters such as the socket file descriptor (sockfd), protocol type (iptype), source IP address (src_ip), port number (port), etc. are saved in the remote log sending configuration socket parameter linked list syslog_socket. When logs need to be sent, the system traverses the linked list through the socket file descriptor (sockfd) to obtain relevant socket parameter information, and uses these parameters to establish a connection with the remote server to send log information.
[0059] In S110, the log is sent through the socket parameter linked list to implement log routing isolation and sending.
[0060] Assume that the administrator needs to send the device logs to two different remote servers, namely log server A and log server B. The administrator sends the configuration through the device's command line interface or web service program. The configuration is as follows:
[0061] The IP address of log server A is 192.168.1.100, the listening port is 514, the UDP protocol is used, and the VRF name is logs_vrf_A.
[0062] The IP address of log server B is 10.0.0.50, the listening port is 5514, the TCP protocol is used, and the VRF name is logs_vrf_B.
[0063] After the administrator issues the configuration, the syslog-ng application restarts and rereads the configuration file. During the application startup process, two sockets are first created, one for communicating with log server A and one for communicating with log server B. Then, the application parses the destination field in the configuration file and obtains the corresponding VRF information, which are logs_vrf_A and logs_vrf_B. Next, the two sockets are bound to the corresponding VRFs.
[0064] At the same time, the system will save the socket file descriptor (sockfd), protocol type (iptype), source IP address (src_ip), port number (port) and other parameters in the remote log sending configuration socket parameter linked list syslog_socket. For the configuration of log server A, the linked list saves the socket parameter information, such as the socket file descriptor is sockfd_A, the protocol type is UDP, the source IP address is the IP address of the device, and the port number is 514; for the configuration of log server B, the socket parameter information is saved, such as the socket file descriptor is sockfd_B, the protocol type is TCP, the source IP address is the IP address of the device, and the port number is 5514.
[0065] When it is necessary to send logs, the system will traverse the syslog_socket linked list through the socket file descriptor to obtain the corresponding socket parameter information. For example, when the device needs to send logs to log server A, it will use sockfd_A, UDP protocol, device IP address, port number 514 to establish a connection and send the log information to log server A; similarly, when it is necessary to send logs to log server B, it will use sockfd_B, TCP protocol, device IP address, port number 5514 to establish a connection and send the log information to log server B.
[0066] According to the remote log sending method for syslog-ng of the present application, by configuring the relevant information of remote log sending, the relevant information includes: server address, port number, protocol type, VPN instance; generating a remote log sending configuration file according to the relevant information; the syslog-ng system rereads the remote log sending configuration file; the syslog-ng system binds the socket socket and the VPN instance, and saves them to the socket parameter linked list; sending logs through the socket parameter linked list to realize the log routing isolation sending mode, which can realize remote log sending based on VRF, ensure the correct transmission of device logs in a network isolation environment, and enhance the flexibility and reliability of the log system.
[0067] Figure 2 The flowchart of a remote log sending method for syslog-ng according to an exemplary embodiment is shown. The remote log sending method 20 for syslog-ng at least includes steps S202 to S208.
[0068] like Figure 2As shown, in S202, the function of sending logs during the device startup process is configured. The administrator can configure whether the device needs to send the logs generated by the device during the startup process through the command line. This can be achieved by modifying the reboot_log_send field in the configuration file, where 1 means enabling the sending of the reboot phase log, and 0 means canceling the sending.
[0069] In S204, based on the function, a thread processing function is created during the startup or recovery process of the device.
[0070] In a specific embodiment, when the device is restarted and the syslog-ng application is reloaded, the system reads the configuration file and checks the value of the reboot_log_send field. If the value of this field is 1, a thread is created in the main processing function of the syslog-ng application to process the logs generated during the restart phase.
[0071] In S206, the thread processing function regularly traverses the socket parameter linked list to generate log content. For example, the thread processing function regularly traverses the socket parameter linked list to obtain socket parameters; and generates the log content based on the socket parameters in a preset format.
[0072] More specifically, the thread processing function has a timer, which periodically traverses the socket parameter linked list to obtain the socket parameters within a preset time.
[0073] In S208, the log content is written into the log of the sockfd parameter sending restart phase. For example, the log content can be written into the log of the sockfd parameter sending restart phase; a mutex is added to the log in the socket parameter linked list; after the log is sent, the log in the socket parameter linked list is deleted and unlocked.
[0074] According to the remote log sending method for syslog-ng of the present application, at the entry in the sending log processing function, it can be checked whether the value of the reboot_log_send field is 1 and whether g_send_context_finish is 0. If the conditions are met, the system will first add a mutex lock to ensure that no log loss occurs when multiple threads call the log interface. Then, the system adds the log content to the linked list syslog_send_context, unlocks it and sets the global variable g_save_context_flag to 1, indicating that the device has added the log during the restart phase. If g_send_context_finish is not 0, the system will traverse the syslog_socket linked list, obtain socket-related parameters, and send the log to the configured destination normally.
[0075] In a network isolation environment, remote log sending can also be achieved by binding vrf, sending logs to the corresponding server through the specified port to achieve routing isolation. At the same time, the logs generated during the restart process of the sending device are saved, and the logs generated by the device during the restart process can be checked, providing a method for troubleshooting problems during the device restart process.
[0076] It should be clearly understood that the present application describes how to form and use specific examples, but the principles of the present application are not limited to any details of these examples. On the contrary, based on the teaching of the content disclosed in the present application, these principles can be applied to many other embodiments.
[0077] Figure 3 The figure is a flow chart showing a remote log sending method for syslog-ng according to another exemplary embodiment. Figure 3 The process 30 shown is for Figure 2 Detailed description of the process shown.
[0078] like Figure 3 As shown, in S302, the command line configures the sending of logs during the reboot phase. The administrator can use the command line to configure whether the device needs to send the logs generated by the device during the boot process. This can be achieved by modifying the reboot_log_send field in the configuration file, where 1 indicates enabling the sending of reboot phase logs, and 0 indicates canceling the sending.
[0079] In S304, the device is restarted.
[0080] In S306, the configuration file is read and assigned values.
[0081] In S308, it is determined whether g_reboot_log_send is 1. When the device is started, the configuration is restored, and the syslog-ng application reads the reboot_log_send field in the configuration file and saves it to the global variable g_reboot_log_send. In the main processing function of the syslog-ng application, the value of the g_reboot_log_send field is determined.
[0082] In S310, a thread processing function is created.
[0083] If the value of the g_reboot_log_send field is 1, a thread will be created to process the logs generated during the restart phase. The processing function of this thread is syslog_reboot_back_thread. At the same time, at the entry of the log sending processing function log_writer_flush_log, it will also be judged whether the g_reboot_log_send field is 1 and whether g_send_context_finish is 0. If the conditions are met, a mutex lock will be added first to prevent partial log loss when multiple threads call the log interface. After adding the lock, the log content is added to the linked list syslog_send_context and then unlocked. At the same time, the global variable g_save_context_flag will be set to 1 to indicate that the linked list has been added to the device restart phase. If g_send_context_finish is not 0, the syslog_socket linked list will be traversed to obtain socket-related parameters and send logs normally.
[0084] Figure 4 The figure is a flow chart showing a remote log sending method for syslog-ng according to another exemplary embodiment. Figure 4 The process 40 shown is for Figure 2 Detailed description of the process shown.
[0085] like Figure 4 As shown, in S402, the device is restarted.
[0086] In S404, it is determined whether log_send_start is 0. When the syslog-ng application is started, a variable log_send_start is saved through the configuration file. When the device is in the startup phase, log_send_start is set to 0, indicating that the device needs to save logs. After the device completes the restart, log_send_start is set to 1, indicating that remote logs can be started.
[0087] In S406, it is determined whether g_send_context_finish is 0. If g_send_context_finish is 0, indicating that the logs in the restart log phase have not been sent completely, the syslog_socket linked list is traversed to obtain socket related parameters.
[0088] In S408, the linked list is traversed and the log is sent.
[0089] In S410 , lock is applied.
[0090] In S412, the linked list is deleted.
[0091] In S414, unlock.
[0092] In S416 , g_send_context_finish is 1.
[0093] Then, the linked list syslog_send_context is traversed, the log content is spliced according to the specified format, and the standard library function write is used to write the log content to the socket descriptor (sockfd) to send the log of the restart phase. After the log is sent, a mutex is added, the linked list is deleted, and the lock is unlocked.
[0094] In S418, g_log_pthread_send_count is incremented by 1.
[0095] In S420, a predetermined time interval is set. In the main function of syslog_reboot_back_thread, a loop is executed every 5 seconds. The number of loops is accumulated and recorded by using the global variable g_log_pthread_send_count to prevent the loop from traversing all the time when the device startup times out abnormally. When the device startup times out abnormally, the linked list is cleared and log sending stops.
[0096] In S422, g_log_pthread_send_count is greater than 180. Inside the loop, first determine whether the local variable send_start_flag is 0. If it is 0, the log_send_start value in the configuration file is read and assigned to send_start_flag. Then, it is determined whether g_log_pthread_send_count is greater than 180 to determine whether the device restart phase exceeds 15 minutes. If it exceeds 15 minutes, it is considered that the device restart phase is abnormal, the linked list is cleared and the log sending is stopped, and the global variable g_send_context_finish is set to 1, indicating that the log sending in the restart phase has been completed, and the loop is exited.
[0097] In S424 , g_send_context_finish is set to 1.
[0098] In S426, lock is applied.
[0099] In S428, the linked list is deleted.
[0100] In S430, unlock.
[0101] In S432, exit.
[0102] Those skilled in the art will appreciate that all or part of the steps for implementing the above embodiments are implemented as a computer program executed by a CPU. When the computer program is executed by the CPU, the above functions defined by the above method provided in the present application are executed. The program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.
[0103] In addition, it should be noted that the above figures are only schematic illustrations of the processes included in the method according to the exemplary embodiments of the present application, and are not intended to be limiting. It is easy to understand that the processes shown in the above figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.
[0104] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.
[0105] Figure 5 FIG. 1 is a block diagram of a remote log sending device for syslog-ng according to an exemplary embodiment. Figure 5 As shown, the remote log sending device 50 for syslog-ng includes: a configuration module 502 , a file module 504 , a rereading module 506 , a binding module 508 , and a sending module 510 .
[0106] The configuration module 502 is used to configure the relevant information of remote log sending, and the relevant information includes: server address, port number, protocol type, VPN instance;
[0107] The file module 504 is used to generate a remote sending log configuration file according to the relevant information; the file module 504 is also used to receive the relevant information in the background; and generate the remote sending log configuration file according to the relevant information.
[0108] The rereading module 506 is used for the syslog-ng system to reread the remote sending log configuration file; the rereading module 506 is also used to restart the syslog-ng system so that the syslog-ng system rereads the remote sending log configuration file.
[0109] The binding module 508 is used by the syslog-ng system to bind the socket and the VPN instance, and save them to the socket parameter list; the binding module 508 is also used by the syslog-ng system to create a socket; parse the remote log configuration file to obtain the VPN instance; bind the socket and the VPN instance, and save them to the socket parameter list.
[0110] The sending module 510 is used to send logs through the socket parameter linked list to achieve log routing isolation and sending.
[0111] Figure 6 FIG. 1 is a block diagram of a remote log sending device for syslog-ng according to another exemplary embodiment. Figure 6 As shown, the remote log sending device 60 for syslog-ng includes: a function module 602 , a creation module 604 , a traversal module 606 , and a writing module 608 .
[0112] Function module 602 is used to configure the function of sending logs during the device startup process;
[0113] The creation module 604 is used to create a thread processing function based on the function during the startup or recovery process of the device;
[0114] The traversal module 606 is used for the thread processing function to periodically traverse the socket parameter list to generate log content; the traversal module 606 is also used for the thread processing function to periodically traverse the socket parameter list to obtain socket parameters; based on the socket parameters, the log content is generated by splicing in a preset format.
[0115] The writing module 608 is used to write the log content into the log of the sockfd parameter sending restart phase. The writing module 608 is also used to write the log content into the log of the sockfd parameter sending restart phase; add a mutex lock to the log in the socket parameter linked list; after the log is sent, delete and unlock the log in the socket parameter linked list.
[0116] According to the remote log sending device for syslog-ng of the present application, by configuring the relevant information of remote log sending, the relevant information includes: server address, port number, protocol type, VPN instance; generating a remote log sending configuration file according to the relevant information; the syslog-ng system rereads the remote log sending configuration file; the syslog-ng system binds the socket socket and the VPN instance, and saves them to the socket parameter linked list; sending logs through the socket parameter linked list to realize the log routing isolation sending mode, which can realize remote log sending based on VRF, ensure the correct transmission of device logs in a network isolation environment, and enhance the flexibility and reliability of the log system.
[0117] In general, the present disclosure solves two main problems of syslog-ng remote log sending. First, when the network device needs network isolation, the remote log sending cannot be specified to the corresponding network for sending. Second, when the device is restarted, the network is not connected because the relevant routing configuration is not restored. The log generated when the device restarts cannot be sent remotely to the server. At this stage, the server receives less logs than the local logs of the device. In the scheme of the present invention, a method for binding vrf to send logs remotely is implemented based on the syslog-ng application. Specifically, the server IP address src_ip required for remote log sending, the server receiving log port number port, the protocol type iptype, and the vrf used by the device to send logs remotely are configured in the device command line / WEB service program. After the background receives the configuration, a remote log sending configuration file is generated, and the syslog-ng process is reread. The configuration file mainly modifies the configuration of the destination and log fields. Among them, the destination field mainly saves the configuration of the server, and the vrf is compiled into the destination name field. The destination also includes the localip field corresponding to the server IP address, the port field corresponding to the server receiving log port, the udp / tcp field corresponding to the protocol type, and the template field of the log corresponding format. The log field contains the source of the local log and the destination parameter of the server. Each time the configuration is issued through the command line / WEB service program, the syslog-ng application will be restarted to reread the configuration file. During the startup of the syslog-ng application, the socket is first created, and then the destination field in the configuration file is parsed to obtain the corresponding vrf, and the socket is bound to the corresponding vrf. At the same time, the socket file descriptor sockfd, iptype, src_ip, and port are saved to the remote log sending configuration socket parameter linked list syslog_socket. When sending logs, the linked list is traversed through the sockfd parameter to obtain the socket-related parameters. You can use the command line to configure whether to send the logs generated during the device startup process. Modify the reboot_log_send field in the configuration file through command configuration. 1 is to enable sending the reboot phase log, and 0 is to cancel sending.When the device starts and the syslog-ng application is configured to be restored, the reboot_log_send field in the configuration file is read and saved to the global variable g_reboot_log_send. In the main function of the syslog-ng application, if the g_reboot_log_send field is 1, the thread processing function syslog_reboot_back_thread is created to process the logs generated in the restart phase. At the entry of the log sending processing function log_writer_flush_log, if the g_reboot_log_send field is 1 and g_send_context_finish is 0, a mutex is added first to prevent part of the log from being lost when multiple threads call the log interface to add logs. After locking, the log content is added to the linked list syslog_send_context, unlocked, and the global variable g_save_context_flag is set to 1 to indicate that the linked list has added logs during the device restart phase. If g_send_context_finish is not 0, the syslog_socket linked list is traversed to obtain socket-related parameters and the log is sent normally. The main process of the log saving and sending thread processing function syslog_reboot_back_thread during the device startup process: save the variable log_send_start through the configuration file, set log_send_start to 0 when starting the syslog-ng application to indicate that the device needs to save logs during the startup phase, and set log_send_start to 1 after the device restarts, indicating that remote logs can be sent. In the main function of this thread processing, it loops every 5 seconds, and uses the global variable g_log_pthread_send_count to accumulate and record the number of loops to prevent the device startup from timing out abnormally. The loop keeps traversing. When the device startup times out abnormally, the linked list is cleared and no logs are sent. Each time in the loop, when the local variable send_start_flag is judged to be 0, the log_send_start value in the configuration file is read and assigned to send_start_flag, and g_log_pthread_send_count is judged to be greater than 180 to determine whether the device restart phase is greater than 15 minutes. If it is greater than 15 minutes, it is considered that the device restart phase is abnormal, the linked list is cleared and no logs are sent, and the global variable g_send_context_finish is set to 1, indicating that the logs in the restart phase have been sent and the loop is exited.If g_send_context_finish is 0, it means that the logs in the restart log phase have not been sent yet, then the syslog_socket linked list is traversed to obtain the socket related parameters, the linked list syslog_send_context is traversed to splice the log content according to the format, and the write standard library function is used to write the log content to sockfd to send the logs in the restart phase. After sending, a mutex is added, the chain is deleted, and the lock is unlocked. In the disclosed implementation, in a network isolated environment, remote log sending can also be achieved by binding vrf, and the logs are sent to the corresponding server through the specified port to achieve routing isolation. At the same time, the logs generated during the restart process of the sending device are saved, and the logs generated by the device during the restart process can be checked, providing a method for troubleshooting problems during the device restart process.
[0118] Figure 7 It is a block diagram of an electronic device according to an exemplary embodiment.
[0119] Refer to the following Figure 7 hereinafter describes an electronic device 700 according to this embodiment of the present application. Figure 7 The electronic device 700 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0120] like Figure 7 As shown, the electronic device 700 is in the form of a general computing device. The components of the electronic device 700 may include, but are not limited to: at least one processing unit 710, at least one storage unit 720, a bus 730 connecting different system components (including the storage unit 720 and the processing unit 710), a display unit 740, etc.
[0121] The storage unit stores a program code, which can be executed by the processing unit 710, so that the processing unit 710 performs the steps described in this specification according to various exemplary embodiments of the present application. For example, the processing unit 710 can perform the following steps: Figures 1 to 4 Follow the steps shown in .
[0122] The storage unit 720 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 7201 and / or a cache memory unit 7202 , and may further include a read-only memory unit (ROM) 7203 .
[0123] The storage unit 720 may also include a program / utility 7204 having a set (at least one) of program modules 7205, such program modules 7205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include the implementation of a network environment.
[0124] Bus 730 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.
[0125] The electronic device 700 may also communicate with one or more external devices 700' (e.g., keyboards, pointing devices, Bluetooth devices, etc.) to enable a user to communicate with the electronic device 700, and / or any device (e.g., routers, modems, etc.) that the electronic device 700 can communicate with one or more other computing devices. Such communication may be performed via an input / output (I / O) interface 750. In addition, the electronic device 700 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 760. The network adapter 760 may communicate with other modules of the electronic device 700 via a bus 730. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0126] Through the above description of the implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by combining software with necessary hardware. Figure 8 As shown, the technical solution according to the implementation mode of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the implementation mode of the present application.
[0127] The software product may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.
[0128] The computer readable storage medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by an instruction execution system, an apparatus, or a device or used in combination with it. The program code contained on the readable storage medium may be transmitted with any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above.
[0129] Program code for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., using an Internet service provider to connect through the Internet).
[0130] The computer-readable medium carries one or more programs. When the one or more programs are executed by a device, the computer-readable medium implements the following functions: configuring relevant information for remote log sending, the relevant information including: server address, port number, protocol type, VPN instance; generating a remote log sending configuration file according to the relevant information; the syslog-ng system rereads the remote log sending configuration file; the syslog-ng system binds the socket and the VPN instance and saves them to a socket parameter linked list; and sending logs through the socket parameter linked list to implement log routing isolation sending.
[0131] The computer-readable medium can also implement the following functions: configure the function of sending logs during device startup; based on the function, create a thread processing function during the startup or recovery process of the device; the thread processing function regularly traverses the socket parameter list to generate log content; and writes the log content into the log of the sockfd parameter sending restart phase.
[0132] Those skilled in the art will appreciate that the above modules can be distributed in the device according to the description of the embodiment, or can be changed accordingly and only used in one or more devices different from the embodiment. The modules of the above embodiments can be combined into one module, or further divided into multiple sub-modules.
[0133] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the embodiment of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a mobile terminal, or a network device, etc.) to execute the method according to the embodiment of the present application.
[0134] The exemplary embodiments of the present application are specifically shown and described above. It should be understood that the present application is not limited to the detailed structures, configurations or implementations described herein; on the contrary, the present application is intended to cover various modifications and equivalent configurations included in the spirit and scope of the appended claims.
Claims
1. A remote log sending method for syslog-ng, characterized in that: include: Configure the relevant information for sending remote logs, including: server address, port number, protocol type, and VPN instance; Generate a remote sending log configuration file according to the relevant information; The syslog-ng system rereads the remote sending log configuration file; The syslog-ng system binds the socket to the VPN instance and saves it to the socket parameter list; Logs are sent through the socket parameter linked list to achieve log routing isolation and sending.
2. The method according to claim 1, characterized in that Generate a remote sending log configuration file based on the relevant information, including: The background receives the relevant information; The remote sending log configuration file is generated according to the relevant information.
3. The method according to claim 1, characterized in that The syslog-ng system rereads the remote log sending configuration file, including: Restart the syslog-ng system to make the syslog-ng system reread the remote log sending configuration file.
4. The method according to claim 1, characterized in that The syslog-ng system binds the socket to the VPN instance and saves it to the socket parameter list, including: The syslog-ng system creates a socket; Parsing the remote sending log configuration file to obtain a VPN instance; Bind the socket to the VPN instance and save them to the socket parameter linked list.
5. The method according to claim 4, characterized in that Binding the socket to the VPN instance and saving to the socket parameter list includes: Binding the socket to the VPN instance; The socket file descriptor is saved to the socket parameter linked list of the remote sending log configuration file.
6. The method according to claim 1, characterized in that Also includes: Configure the function of sending logs during device startup; Based on the functions, a thread processing function is created during the startup or recovery process of the device; The thread processing function periodically traverses the socket parameter linked list to generate log content; The log content is written into the log of the sockfd parameter sending restart phase.
7. The method according to claim 6, characterized in that The thread processing function periodically traverses the socket parameter list to generate log content, including: The thread processing function periodically traverses the socket parameter list to obtain the socket parameters; The log content is generated by splicing based on the socket parameters in a preset format.
8. The method according to claim 7, characterized in that The thread processing function periodically traverses the socket parameter linked list to obtain the socket parameters. It includes: The thread processing function has a timer, which regularly traverses the socket parameter linked list to obtain the socket parameters within a preset time.
9. The method according to claim 6, characterized in that The log content is written into the log of the sockfd parameter sending restart phase, including: Write the log content into the log sent by the sockfd parameter during the restart phase; Add a mutex lock to the log in the socket parameter list; After the log is sent, the log in the socket parameter linked list is deleted and unlocked.
10. A remote log sending device for syslog-ng, characterized in that: include: A configuration module, used to configure the relevant information of remote log sending, the relevant information includes: server address, port number, protocol type, VPN instance; A file module, used to generate a remote sending log configuration file according to the relevant information; A reread module, used for the syslog-ng system to reread the remote sending log configuration file; Binding module, used by the syslog-ng system to bind the socket and VPN instance and save them to the socket parameter list; The sending module is used to send logs through the socket parameter linked list to achieve log routing isolation and sending.