SONIC log system level control method, device, electronic device and storage medium

Abstract

The present application relates to a SONIC log system level control method, device, electronic device and storage medium. The method includes: using the configuration service in docker to write the log level configuration data of the module that the native tool does not support into the submodule log configuration file in the docker, and setting the log level of the module that the native tool does not support; using the first log level monitoring service to call the native tool, synchronizing the log level configuration data of the module supported by the native tool into the log level database, and setting the log level of the module supported by the native tool. This method can realize the dynamic setting and modification of the log level of the module that the native tool does not support, and also solves the problem that the module log level configuration data is lost after the system is restarted when the native tool is used to directly set the log level.

Description

Technical Field

[0001] The present application relates to the field of system log management, and in particular to a SONIC log system level management method, device, electronic device and storage medium. Background Art

[0002] SONIC (Software for Open Networking in the Cloud) is an innovative software system that decomposes traditional switch operating system software into multiple containerized components. SONIC makes extensive use of existing open source projects and technologies, such as Docker (containers), Redis (a high-performance key-value database), Quagga (open source routing software), and LLDPD (Link Layer Discovery Protocol), as well as automated configuration tools such as Ansible, Puppet, and Chef. SONIC's network applications are all built on Docker, making it very convenient to deploy and upgrade applications in production environments without downtime. SONIC has achieved rapid development in a short period of time, but due to its brand-new architecture, it is still in its early stages of development. Currently, the officially released version of the SONIC community still contains missing features and bugs. For software operating systems, log monitoring, recording, and collection are among their most important functions, and a comprehensive logging system is a crucial prerequisite for efficient development. Future large-scale networking solutions will require top-level functional design and functionality for unified monitoring and visualization of all devices in the entire network cluster. This places certain demands on the SONIC system's log level settings and log collection.

[0003] The SONIC system is essentially a system image based on the Linux kernel, with various SONIC-related applications added to it. It has some of SONIC's own functional features. For example, the key database in the SONIC architecture, the module containers (docker), and the corresponding sub-module functions in each container, all of which together make up the entire SONIC system. In this system, the containers and modules do not communicate directly with each other, but instead store and use data in a centralized database. The SONIC system solution can avoid complex process communication between sub-modules as much as possible, instead using a data-responsible approach to ensure flexible reading and writing of data such as network switch configurations.

[0004] The SONIC system provides six different databases for storing different data, including config_DB (config database) and loglvel_DB (loglevel database). config_DB stores module-specific configuration data, while loglvel_DB primarily stores data related to log level settings. The current community SONIC system provides a swssloglevelL tool interface, which allows users to issue commands to directly modify a module's log output level at runtime. Once set, the module's log level takes effect immediately. The native swssloglevelL tool provides code to read and write data to the system's loglvel_DB. swss docker (Switch State Service docker) is a set of tools that allows all SONiC modules to communicate effectively, primarily providing mechanisms to facilitate communication and arbitration between all different parties. The modules directly supported by the native swssloglevelL tool in the SONIC system generally rely on swss docker services.

[0005] However, the swssloglevel tool currently covers a limited number of modules, and its configuration and modification methods are cumbersome, making it extremely inconvenient for developers. Due to limitations inherent in certain modules within the system, it is impossible to directly expand upon the swssloglevel implementation mechanism. For example, using the swssloglevel tool to set the level of a critical supervisord process within each Docker container requires a supervisord process restart for the change to take effect. For such critical processes, each restart means the loss of a significant amount of process logs, making the operation extremely inconvenient and resulting in data loss.

[0006] In addition, there are currently dozens of software application modules related to the SONIC system, and the swssloglevel tool can only cover a small part of them. Most modules are still unable to implement dynamic setting and modification of log levels, resulting in a large lack of log level setting function in the current SONIC system. Any top-level application design based on this function cannot be implemented. For example, the current community's SONIC system cannot meet the application requirements of future log system visualization. Summary of the Invention

[0007] In view of this, the present application aims to propose a SONIC log system level management method, device, electronic device and storage medium to solve the problem that some application modules in the current SONIC system cannot dynamically set and modify the log level through the system native tools, and after the system native tools configure and modify the log level of some modules that support the tool, data loss occurs after the system is restarted.

[0008] In a first aspect, an embodiment of the present application provides a SONIC log system level management method, the method comprising:

[0009] Use the configuration service in Docker to write the log level configuration data of the module not supported by the native tool into the submodule log configuration file in the Docker, and set the log level of the module not supported by the native tool;

[0010] The first log level monitoring service is used to call the native tool, synchronize the log level configuration data of the module supported by the native tool to the log level database, and set the log level of the module supported by the native tool.

[0011] Optionally, set the log level for modules not supported by the native tool, including:

[0012] Using the configuration service in the docker, when the docker is started, according to the log level of the docker submodule in the log level database, a log level output configuration of the corresponding submodule is added to the submodule log configuration file in the docker, and a log processing process is started to make it effective;

[0013] Using the configuration service in the docker, the log level control variable of the docker submodule in the log level database is monitored. When the log level control variable changes, the corresponding content of the submodule log configuration file in the docker is modified, and the log processing process is restarted to take effect;

[0014] The docker in-configuration service is set in the corresponding docker and starts with the corresponding docker.

[0015] Optionally, set the log level of the modules supported by the native tool, including:

[0016] Using the first log level monitoring service, when swss docker is started, calling the native tool, and synchronizing the log level configuration data of the modules supported by the native tool from the configuration database to the log level database;

[0017] Using the first log level monitoring service, monitoring the log level control variable of the module supported by the native tool in the configuration database, when the log level control variable changes, calling the native tool to update the log level control variable of the changed module to the log level database;

[0018] The first log level monitoring service is set in swss docker and started with swss docker.

[0019] Optionally, the SONIC log system level management method further includes:

[0020] The second log level monitoring service is used to write the log level configuration data of the module not supported by the native tool in the configuration database into the log level database.

[0021] Optionally, writing the log level configuration data of the module not supported by the native tool in the configuration database into the log level database includes:

[0022] Using the second log level monitoring service, when the SONIC system is started, the log level configuration data of the module not supported by the native tool is synchronized from the configuration database to the log level database;

[0023] Using the second log level monitoring service, monitoring the log level control variable of the module not supported by the native tool in the configuration database, and when the log level control variable changes, using a variable write instruction to update the log level control variable of the changed module to the log level database;

[0024] The second log level monitoring service is set at the host port of the SONIC system and is started along with the SONIC system.

[0025] Optionally, the SONIC log system level management method further includes:

[0026] A log level variable table is set in the configuration database to store log level control variables of modules supported by the native tool and log level control variables of modules not supported by the native tool.

[0027] Optionally, the SONIC log system level management method further includes:

[0028] Using the configuration confirmation service, when the SONIC system is started, check whether the log level control variable data of each module in the system exists in the log level variable table of the configuration database;

[0029] If the log level control variable data of each module in the system exists in the log level variable table, it means that the data has been established and no modification is required;

[0030] If the log level control variable data of at least one module is missing in the log level variable table, the configuration confirmation service creates a log level control variable for the corresponding module in the log level variable table and sets the default value to NOTICE;

[0031] The configuration confirmation service is set at the host port of the SONIC system and starts with the SONIC system.

[0032] Optionally, the SONIC log system level management method further includes:

[0033] Set the log level modification tool in the CLI interactive window of the SONIC system to set the log level of all modules in the system;

[0034] The log level modification tool is used to write the log level configuration data of the corresponding module into the configuration database according to the instruction information input by the user.

[0035] According to a second aspect of an embodiment of the present application, a SONIC log system level management and control device is provided, the device comprising:

[0036] The docker internal level configuration module is configured to use the docker internal configuration service to write the log level configuration data of the module not supported by the native tool into the submodule log configuration file in the docker, thereby setting the log level of the module not supported by the native tool;

[0037] A compatible log level configuration module is configured to use a first log level monitoring service, call the native tool, synchronize the log level configuration data of the module supported by the native tool to the log level database, and set the log level of the module supported by the native tool.

[0038] According to a third aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the method described in the first aspect of the present application are implemented.

[0039] According to a fourth aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps in the method described in the first aspect of the present application are implemented.

[0040] The SONIC log system level management method provided in this application is adopted. By setting up a docker configuration service in the docker where the module not supported by the native tool is located, the log level configuration data of the module not supported by the native tool is written into the sub-module log configuration file in the corresponding docker, thereby realizing the setting of the log level of the module not supported by the native tool; by setting a first log level listening service, calling the native tool, and synchronizing the log level configuration data of the module supported by the native tool to the log level database, the log level setting of the module supported by the native tool is realized, and a compatible solution is achieved.

[0041] The SONIC log system level control method provided by this application introduces a log level modification tool in the CLI (command-line interface) interactive window. The user issues a log level setting instruction through the log level modification tool, and uses the modification tool as a unified interface for setting the log level of all modules in the system, so that the user can modify the log level of all modules in the system in the CLI interactive window, which is convenient for the user to operate;

[0042] This application implements the dynamic setting and modification of the log level of modules that are not supported by native tools by adding corresponding listening services in the system's host port, swss docker, and the docker where the modules are located that are not supported by native tools, for changes in the module's log level control variables in the corresponding database; and by setting the corresponding listening service, the module's log level initialization configuration is implemented when the system starts, while solving the problem of the loss of log level configuration data of modules supported by native tools after the system is restarted. In summary, the present application solution implements the dynamic setting and modification of the log level of modules that are not supported by native tools, while also solving the problem of the loss of module log level configuration data after the system is restarted for some modules that use native tools to set log levels. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments of the present application. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0044] Figure 1 This is a flowchart of the SONIC log system level control method proposed in one embodiment of the present application;

[0045] Figure 2This is a flow chart of dynamically modifying the log level proposed in one embodiment of the present application;

[0046] Figure 3 Schematic diagram of a SONIC log system level control device proposed in one embodiment of the present application. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0048] It should be understood that references throughout this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic associated with the embodiment is included in at least one embodiment of the present application. Therefore, the appearances of "in one embodiment" or "in an embodiment" throughout this specification do not necessarily refer to the same embodiment. Furthermore, these particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0049] In the various embodiments of the present application, it should be understood that the size of the serial numbers of the following processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0050] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0051] It should be noted that, unless there is any conflict, the embodiments and features in the embodiments of this application can be combined with each other.

[0052] This application is based on the native swssloglevel tool of the SONIC system. It will use the native solution of the swssloglevel tool to manage the log level of the system module, and combine it with the rsyslog system log control solution. On the basis of full compatibility with the native SONIC log system solution, it adopts the rsyslog.conf control solution to control the log level of system software application modules that are not supported by the swssloglevel tool.

[0053] This embodiment uses loglevel_DB as a log level control variable storage, and other log-related ones, such as config_DB, are used to store the user's configuration of a certain module level. In this embodiment, all configurations made by the user to the module will be written directly to config_DB, and then synchronously written to loglevel_DB. Only when the data is written to loglevel_DB, the configuration will officially take effect. Each time the system restarts, only config_DB will be saved, and the data in loglevel_DB will be destroyed due to the restart. Therefore, this application sets up a related monitoring service to automatically execute data synchronization from config_DB to loglevel_DB after the system restarts.

[0054] In this embodiment, in order to be compatible with the dynamic setting and modification of the log level of the module directly set by the swssloglevel tool, the system CLI operation window is introduced with the syslog severity tool interface for configuring the log level for all modules in the system. The syslog severity tool can directly call the SONIC native swssloglevel tool, but the swssloglevel tool will not be exposed to the user. In actual use, the user only needs to enter the module configuration information in the system CLI interactive operation window to configure the module log level for the corresponding module through the syslog severity tool.

[0055] Figure 1 This is a flow chart of the dynamic setting and modification of log levels proposed in one embodiment of the present application. Figure 1 As shown, in step S101, the configuration service in docker is used to write the log level configuration data of the module not supported by the native tool into the sub-module log configuration file in the docker, and the log level of the module not supported by the native tool is set; in step S102, the first log level monitoring service is used to call the native tool, and the log level configuration data of the module supported by the native tool is synchronized to the log level database, and the log level of the module supported by the native tool is set.

[0056] In this embodiment, by setting up a docker internal configuration service inside docker, the log level setting of modules that are not supported by the native swssloglevel tool is realized. Specifically, in this embodiment, the docker internal configuration service is named after docker.

[0057] For example, in the ICCPD (Inter-Chassis Communication Protocol Docker) docker, set up a docker configuration service named ICCPD_config_rsyslog_conf.py to configure the log levels of all submodules in ICCPD.

[0058] In this embodiment, the configuration service in docker modifies the log level of the corresponding sub-module by modifying the content of the sub-module log configuration file in docker. Specifically, each docker has an rsyslog.conf configuration file for storing the configuration data of all sub-modules in the docker. When the docker is started, the configuration service in docker writes the initial configuration data of the sub-module in the docker into the rsyslog.conf configuration file to implement the initial configuration of the log level of the sub-module in the docker; when the log level of the sub-module in the docker is modified, the configuration service in docker writes the modified log level control variable data into the rsyslog.conf configuration file to update the log level configuration.

[0059] It should be noted that when dynamically setting and modifying the log level for modules that are not supported by the native swssloglevel tool, each time the docker configuration service is used to write data to the submodule log configuration file in docker, the log processing process in docker needs to be restarted for the changed configuration to take effect. In this embodiment, the log processing process in docker is the rsyslogd process service. In the local instance, the docker_name_config_rsyslog_conf.py service writes the log level control variable data of the submodule in docker to the rsyslog.conf configuration file, and then restarts the rsyslogd process service for it to take effect.

[0060] Optionally, in this embodiment, when the docker is started, according to the log level of the docker submodule in the log level database, a log level output configuration of the corresponding submodule is added to the submodule log configuration file in the docker, and the log processing process is started to take effect;

[0061] Using the configuration service in the docker, the log level control variable of the docker submodule in the log level database is monitored. When the log level control variable changes, the corresponding content of the submodule log configuration file in the docker is modified, and the log processing process is restarted to take effect;

[0062] The docker in-configuration service is set in the corresponding docker and starts with the corresponding docker.

[0063] In this embodiment, loglevel_DB is set as the log level database to store configuration data related to the log levels of modules in the system, including the log level control variables of the modules. The log level control variables here include not only the log level control variables of modules that the native swssloglevel tool supports direct modification, but also the log level control variables of other modules in the system that are not supported by the native swssloglevel tool. When dynamically setting and modifying the log level of a module that is not supported by the native swssloglevel tool, use the docker_name_config_rsyslog_conf.py service in the docker where the module is located. When the docker starts, write the log level configuration data of the corresponding module in loglevel_DB to the rsyslog.conf configuration file, and then restart the rsyslogd process service for it to take effect; the docker_name_config_rsyslog_conf.py service will also monitor the log level control variables of the submodules in this docker to see if there are any changes in loglevel_DB. If the log level control variables are found to have changed, the content in the rsyslog.conf configuration file will be modified accordingly, and the rsyslogd process service will be restarted for it to take effect, thereby realizing the dynamic setting and modification of the log level of modules that are not supported by the native swssloglevel tool.

[0064] Optionally, in this embodiment, the first log level monitoring service is used. When swss docker is started, the native tool is called to synchronize the log level configuration data of the modules supported by the native tool from the configuration database to the log level database.

[0065] Using the first log level monitoring service, monitoring the log level control variable of the module supported by the native tool in the configuration database, when the log level control variable changes, calling the native tool to update the log level control variable of the changed module to the log level database;

[0066] The first log level monitoring service is set in swss docker and started with swss docker.

[0067] In the present embodiment, since the modules supported by native swssloglevel tool basically rely on the service of swss docker, a first log level monitoring service, i.e. swss_loglevelmgrd service, is set in swss docker. This service is started as swss docker starts. When it starts, native swssloglevel tool is called to synchronize the log level configuration data of the related modules supported by native swssloglevel tool in config_DB from config_DB to loglevel_DB, so that it takes effect. In the present embodiment, config_DB is the configuration database, which is mainly used for storing the configuration data related to the module, including data related to the log level setting of the module synchronized to loglevel_DB.

[0068] In this embodiment, the swss_loglevelmgrd service also monitors the log level control variables of the modules supported by the native swssloglevel tool in config_DB. When it is found that the log level control variables of these modules have changed, the native swssloglevel tool is called to write the changed log level control variables into loglevel_DB to make them effective.

[0069] Optionally, in this embodiment, a log level variable table SYSLOG_SEVERITY_TABLE is set in the configuration database (i.e., config_DB) for storing variable values ​​related to log levels. When the first log level monitoring service swss_loglevelmgrd modifies the log level of a module supported by the native swssloglevel tool, when it monitors that the log level control variable in the SYSLOG_SEVERITY_TABLE table has changed, it calls the native swssloglevel tool and writes the changed log level control variable into loglevel_DB to take effect.

[0070] Optionally, in this embodiment, a configuration confirmation service is used to check whether the log level control variable data of each module in the system exists in the log level variable table of the configuration database when the SONIC system is started;

[0071] If the log level control variable data of each module in the system exists in the log level variable table, it means that the data has been established and no modification is required;

[0072] If the log level control variable data of at least one module is missing in the log level variable table, the configuration confirmation service creates a log level control variable for the corresponding module in the log level variable table and sets the default value to NOTICE;

[0073] The configuration confirmation service is set at the host port of the SONIC system and starts with the SONIC system.

[0074] In this embodiment, a configuration confirmation service, namely the config_checker.py service, is set at the host port of the system. The service is started when the SONIC system is started. When the service is started, it checks whether the log level setting variables of the submodules under each docker in the system exist in the SYSLOG_SEVERITY_TABLE table in the current config_DB; if the log level setting variables of all modules in the system exist in the table, no changes are required; if the log level setting variables of some modules in the system do not exist in the table, the config_checker.py service creates a new log level setting variable for the missing module in the table, and sets the default value of the variable to NOTICE, ensuring that before the log level of the module in the system is subsequently configured, the log level setting variables of all modules in the system exist in the SYSLOG_SEVERITY_TABLE table of config_DB.

[0075] Optionally, in this embodiment, a second log level monitoring service is used to write the log level configuration data of the modules not supported by the native tool in the configuration database into the log level database:

[0076] Using the second log level monitoring service, when the SONIC system starts, the log level configuration data of the modules not supported by the native tool is synchronized from the configuration database to the log level database;

[0077] Use the second log level monitoring service to monitor the log level control variables of modules not supported by native tools in the configuration database. When the log level control variables change, use the variable write instruction to update the log level control variables of the changed modules to the log level database.

[0078] The second log level monitoring service is set at the host port of the SONIC system and is started along with the SONIC system.

[0079] In this embodiment, a second log level monitoring service, namely the loglevelmgrd service, is set at the system host port to monitor the log level configuration data of the modules that the native swssloglevel tool in config_DB does not support. The loglevelmgrd service starts with the SONIC system and starts later in the order. When the loglevelmgrd service starts, a write instruction is called to synchronize the log level configuration data of the modules that the native swssloglevel tool in config_DB does not support to loglevel_DB.

[0080] Optionally, in this embodiment, when the loglevelmgrd service is started, it calls a write instruction to write the log level configuration data of the modules not supported by the native swssloglevel tool in the SYSLOG_SEVERITY_TABLE table of config_DB into loglevel_DB. In this embodiment, the write instruction can be divided into hset instruction, teamdctl instruction and vtysh instruction according to the type of configuration data.

[0081] In this embodiment, the loglevelmgrd service also monitors the log level control variables of modules not supported by the native swssloglevel tool in config_DB. That is, when it monitors the SYSLOG_SEVERITY_TABLE table and finds that the log level control variables of modules not supported by the native swssloglevel tool change, it calls the write instruction to write the corresponding variables into loglevel_DB.

[0082] Optionally, this embodiment provides a log level modification tool in the CLI interactive window of the SONIC system, which is used to set the log level of all modules in the system;

[0083] The log level modification tool is used to write the log level configuration data of the corresponding module into the configuration database according to the instruction information input by the user.

[0084] In this embodiment, in order to uniformly manage the log level settings of modules supported and unsupported by the native swssloglevel tool and facilitate user operations, the syslogseverity tool is introduced in the CLI interactive window of the SONIC system to modify the log levels of all modules in the system. In the CLI interactive window, the user issues log level-related instructions by calling the syslogseverity tool, thereby achieving unified management of the log levels of each module in the system. Based on the user's instructions, the syslogseverity tool writes the log configuration data of the corresponding module to config_DB.

[0085] In this embodiment, the syslog severity tool is the only operation interface provided to users by the entire system. It can call related tools of the Sonic native swssloglevel tool internally, but this tool will not be exposed to users. When users dynamically set and modify the log level of modules in the system, they can perform operations uniformly through the syslog severity tool without having to worry about whether the module is supported by the native swssloglevel tool.

[0086] Figure 2 This is a flow chart of the dynamic modification of log levels proposed in one embodiment of the present application, as shown in FIG. Figure 2 As shown in the figure, the user enters the log level setting instruction in the system CLI window, and the syslog severity tool writes the corresponding log level configuration data into config_DB.

[0087] Figure 2 In , when the user modifies a module supported by the native swssloglevel tool, the swss_loglevelmgrd service monitors the change of the log level control variable of the corresponding module in config_DB, calls the native swssloglevel tool, and writes the changed variable to loglevel_DB to make it effective;

[0088] When the user modifies a module that is not supported by the native swssloglevel tool, the loglevelmgrd service monitors the change in the log level control variable of the corresponding module in config_DB, and uses the write instruction (hset instruction, teamdctl instruction or vtysh instruction) to write the changed variable to loglevel_DB. Then, the docker_name_config_rsyslog_conf.py service set in docker monitors the change in the log level control variable of the submodule in docker in loglevel_DB, and writes the changed variable to the rsyslog.conf configuration file in docker, and restarts the rsyslogd process service to make it take effect.

[0089] Based on the same inventive concept, an embodiment of the present application provides a SONIC log system level management and control device 300. Figure 3 This is a schematic diagram of a SONIC log system level control device proposed in one embodiment of the present application. Figure 3 As shown, the device includes:

[0090] The docker internal level configuration module 301 is configured to use the docker internal configuration service to write the log level configuration data of the module not supported by the native tool into the submodule log configuration file in the docker, and set the log level of the module not supported by the native tool;

[0091] The compatible log level configuration module 302 is configured to use the first log level monitoring service, call the native tool, synchronize the log level configuration data of the modules supported by the native tool to the log level database, and set the log level of the modules supported by the native tool.

[0092] Optionally, the docker internal level configuration module 301 further includes:

[0093] The docker level synchronization submodule is used to add the log level output configuration of the corresponding submodule in the submodule log configuration file in the docker according to the log level of the docker submodule in the log level database;

[0094] The level update module in Docker is used to monitor the log level control variable of the Docker submodule in the log level database. When the log level control variable changes, the corresponding content of the submodule log configuration file in Docker is modified and the log processing process is restarted to take effect.

[0095] The log process processing submodule is used to restart the log processing process to make the changes to the log configuration file take effect after the content of the submodule log configuration file in Docker is changed.

[0096] Optionally, the compatible log level configuration module 302 further includes:

[0097] The first-level synchronization submodule is used to call the native tool when the swss docker is started, and synchronize the log level configuration data of the modules supported by the native tool from the configuration database to the log level database;

[0098] The first level update submodule is used to use the first log level monitoring service to call the native tool when the log level control variable of the module supported by the native tool in the configuration database changes, and update the log level control variable of the changed module into the log level database;

[0099] Optionally, the SONIC log system level control device 300 further includes:

[0100] The second log level configuration module is used to write the log level configuration data of the modules not supported by the native tool in the configuration database into the log level database.

[0101] Optionally, the second log level configuration module includes:

[0102] The second-level synchronization submodule is used to synchronize the log level configuration data of modules not supported by native tools from the configuration database to the log level database using the second-level log listening service when the SONIC system is started;

[0103] The second level update submodule is used to use the second log level monitoring service to update the log level control variable of the changed module into the log level database through the variable write instruction when the log level control variable of the module that is not supported by the native tool in the configuration database changes.

[0104] Optionally, the SONIC log system level control device 300 further includes:

[0105] The log level confirmation module is used to use the configuration confirmation service to check whether the log level control variable data of each module in the system exists in the log level variable table of the configuration database when the SONIC system is started. If the log level control variable data of each module in the system exists in the log level variable table, it means that the data has been established and no change is required; if the log level control variable data of at least one module is missing in the log level variable table, the configuration confirmation service will create a new log level control variable for the corresponding module in the log level variable table and set the default value to NOTICE.

[0106] Based on the same inventive concept, another embodiment of the present application provides a readable storage medium having a computer program stored thereon. When the program is executed by a processor, the steps in the SONIC log system level control method as described in any of the above embodiments of the present application are implemented.

[0107] Based on the same inventive concept, another embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes, the steps in the SONIC log system level control method described in any of the above embodiments of the present application are implemented.

[0108] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0109] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

[0110] For the sake of simplicity, the method embodiments are described as a series of action combinations. However, those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and components involved are not necessarily required by this application.

[0111] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the embodiments of the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0112] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0113] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0114] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0115] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic inventive concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0116] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0117] The above is a detailed introduction to the SONIC log system level control method, device, electronic device and storage medium provided by this application. Specific examples are used in this article to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core idea of ​​this application. At the same time, for general technical personnel in this field, according to the ideas of this application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on this application.

Claims

1. A SONIC log system level management method, characterized in that: Including: Using the configuration service within Docker, write the log level configuration data of the modules not supported by the native tool into the sub-module log configuration file in the Docker, and set the log levels of the modules not supported by the native tool. Specifically, it includes: Using the configuration service within Docker, when the Docker starts, according to the log levels of the Docker sub-modules in the log level database, add the log level output configurations corresponding to the sub-modules in the sub-module log configuration file in the Docker, and start the log processing process to make it effective; Using the configuration service within Docker, monitor the log level control variables of the Docker sub-modules in the log level database. When the log level control variables change, modify the corresponding content of the sub-module log configuration file in the Docker, and restart the log processing process to make it effective; The configuration service within Docker is set in the corresponding Docker and starts following the corresponding Docker. Using the first log level monitoring service, call the native tool to synchronize the log level configuration data of the modules supported by the native tool to the log level database, and set the log levels of the modules supported by the native tool. Specifically, it includes: Using the first log level monitoring service, when the swss Docker starts, call the native tool to synchronize the log level configuration data of the modules supported by the native tool from the configuration database to the log level database; Using the first log level monitoring service, monitor the log level control variables of the modules supported by the native tool in the configuration database. When the log level control variables change, call the native tool to update the log level control variables of the changed modules to the log level database; The first log level monitoring service is set in the swss Docker and starts following the swss Docker.

2. The SONIC log system level management method according to claim 1, characterized in that: It also includes: Using the second log level monitoring service, write the log level configuration data of the modules not supported by the native tool in the configuration database into the log level database.

3. The SONIC log system level control method according to claim 2, characterized in that: Writing the log level configuration data of the modules not supported by the native tool in the configuration database into the log level database includes: Using the second log level monitoring service, when the SONIC system starts, synchronize the log level configuration data of the modules not supported by the native tool from the configuration database to the log level database; Using the second log level monitoring service, monitor the log level control variables of the modules not supported by the native tool in the configuration database. When the log level control variables change, use the variable writing instruction to update the log level control variables of the changed modules to the log level database; The second log level monitoring service is set at the host port of the SONIC system and starts following the SONIC system.

4. The SONIC log system level control method according to claim 1, characterized in that: It also includes: A log level variable table is set in the configuration database to store log level control variables of modules supported by the native tool and log level control variables of modules not supported by the native tool.

5. The SONIC log system level control method according to claim 4, characterized in that: Also includes: Using the configuration confirmation service, when the SONIC system is started, check whether the log level control variable data of each module in the system exists in the log level variable table of the configuration database; If the log level control variable data of each module in the system exists in the log level variable table, it means that the data has been established and no modification is required; If the log level control variable data of at least one module is missing in the log level variable table, the configuration confirmation service creates a log level control variable for the corresponding module in the log level variable table and sets the default value to NOTICE; The configuration confirmation service is set at the host port of the SONIC system and starts with the SONIC system.

6. The SONIC log system level management and control method according to claim 1, characterized in that: Also includes: Set the log level modification tool in the CLI interactive window of the SONIC system to set the log level of all modules in the system; The log level modification tool is used to write the log level configuration data of the corresponding module into the configuration database according to the instruction information input by the user.

7. A SONIC log system level control device, characterized in that: The device comprises: Docker internal level configuration module is configured to use the Docker internal configuration service to write the log level configuration data of the module not supported by the native tool into the submodule log configuration file in the Docker, and set the log level of the module not supported by the native tool, specifically comprising: using the Docker internal configuration service, when the Docker is started, according to the log level of the Docker submodule in the log level database, adding the log level output configuration of the corresponding submodule to the submodule log configuration file in the Docker, and starting the log processing process to make it effective; using the Docker internal configuration service to monitor the log level control variable of the Docker submodule in the log level database, modifying the corresponding content of the submodule log configuration file in the Docker when the log level control variable changes, and restarting the log processing process to make it effective; the Docker internal configuration service is set in the corresponding Docker and starts with the corresponding Docker; A compatible log level configuration module is configured to use a first log level monitoring service to call the native tool, synchronize the log level configuration data of the modules supported by the native tool to the log level database, and set the log level of the modules supported by the native tool, specifically including: using the first log level monitoring service, calling the native tool when swssdocker is started, synchronizing the log level configuration data of the modules supported by the native tool from the configuration database to the log level database; using the first log level monitoring service to monitor the log level control variables of the modules supported by the native tool in the configuration database, calling the native tool when the log level control variables change, and updating the log level control variables of the changed modules to the log level database; the first log level monitoring service is set in swss docker and starts following swss docker.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

Images