Operator equipment fault positioning method and system, medium and product

Abstract

The embodiment of the invention provides an operator equipment fault positioning method and system, a medium and a product, and relates to the technical field of block chains. The method comprises the following steps: acquiring configuration information of each piece of data center machine room equipment of an operator; according to the configuration information, constructing an index relationship corresponding to the device name and the position; judging whether the configuration information is empty or not; if yes, the actual configuration state of the corresponding equipment is analyzed according to the index relation, and a problem report is generated according to the actual configuration state; if not, constructing a Merkel tree and a block chain block according to the configuration information of the operator equipment; based on the Merkel tree, recursively comparing tree root hash values of the current block and the historical block, and determining a difference block which changes for the first time; comparing the tree nodes of the current block and the difference block layer by layer, and determining difference leaf nodes; and determining equipment information corresponding to the difference leaf nodes through the index relationship, and generating a problem report based on the equipment information. According to the scheme, the inspection efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a method, system, medium, and product for locating faults in operator equipment. Background Technology

[0002] In existing technologies, operators often rely on a customized automated operation and maintenance system for their current maintenance inspections and problem localization. During routine maintenance, system failures caused by configuration changes often require manual backtracking of recent system changes to try and identify potential abnormal configurations. Considering that operators provide public infrastructure services, their business logic is complex, they involve numerous devices, fault localization is difficult, and the impact of outages is widespread. Routine device configuration checks are usually only a supplement to system monitoring and cannot play a crucial role in fault localization, thus reducing the significance of inspection work. Summary of the Invention

[0003] At least one embodiment of this application provides a method, system, medium, and product for locating faults in operator equipment, which addresses the problem that in the prior art, equipment configuration checks are only a supplement to monitoring and cannot play a key role in fault location, resulting in insufficient inspection efficiency.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows:

[0005] In a first aspect, embodiments of this application provide a method for locating faults in operator equipment, including:

[0006] Obtain configuration information of equipment in various data center computer rooms of the operator;

[0007] Based on the configuration information, construct an index relationship between device names and locations;

[0008] Determine whether the configuration information is empty; if it is empty, analyze the actual configuration status of the corresponding device according to the index relationship, and generate a problem report based on the actual configuration status.

[0009] If not empty, construct a Merkle tree and blockchain blocks based on the configuration information of the operator equipment;

[0010] Based on the Merkle tree, the root hash values ​​of the current block and historical blocks are recursively compared to determine the first difference block of the change.

[0011] The tree nodes of the current block and the differing blocks are compared layer by layer to determine the differing leaf nodes;

[0012] The device information corresponding to the differential leaf node is determined through the index relationship, and a problem report is generated based on the device information.

[0013] Optionally, obtain the configuration information of the equipment in each of the operator's data center computer rooms, including:

[0014] Read the predefined collection list;

[0015] Based on the collection list, access the equipment in each data center of the operator via remote connection;

[0016] Persist the runtime configuration in the device's memory to the configuration information;

[0017] When a single device needs to save multiple configuration information, determine the compressed package to be named after the device;

[0018] The configuration information or compressed package is remotely copied to the configuration acquisition server. The configuration information of the equipment in each data center of the operator is obtained through the acquisition server. The configuration information includes at least the configuration information required for the operation of the operator's network and server equipment.

[0019] Optionally, based on the configuration information of the operator's equipment, a Merkle tree and blockchain blocks are constructed, including:

[0020] Perform a hash calculation on the configuration information to determine the hash calculation result;

[0021] Based on the index relationship, the hash calculation result is used as a leaf node, and the hash values ​​of two adjacent leaf nodes are concatenated and serialized. The concatenated and serialized hash value is used as an intermediate node. The Merkle tree is constructed by recursively building from the intermediate node until a single root node is generated.

[0022] Based on the Merkle tree, a blockchain block containing a block header and a block body is generated; the block header contains at least the parent block hash value, the root hash value of the Merkle tree, and a timestamp; the block body contains at least the input list corresponding to the index relationship and the output list corresponding to the Merkle tree structure.

[0023] Optionally, based on the Merkle tree, the root hash values ​​of the current block and historical blocks are recursively compared to determine the first difference block of the change, including:

[0024] Retrieve the first hash value of the parent block stored in the block header of the current block;

[0025] Based on the Merkle tree, match the root hash value of the block header corresponding to the parent block;

[0026] If the root hash value is inconsistent with the first hash value, then the root hash value of the previous level historical block is recursively traced until a block consistent with the first hash value is found.

[0027] The next level block of the consistent block is identified as the difference block that is the first to experience a configuration change.

[0028] Optionally, the tree nodes of the current block and the differing blocks are compared layer by layer to determine the differing leaf nodes, including:

[0029] Determine the corresponding intermediate node hash value between the current block and the differing block;

[0030] Based on the hash value of the intermediate node, the difference branch is determined. Starting from the root node of the Merkle tree, the child nodes at each level are compared downwards along the difference branch until the leaf node level of the Merkle tree is reached. Leaf nodes with inconsistent hash values ​​are identified as difference leaf nodes.

[0031] Optionally, the device information corresponding to the differing leaf node is determined through the index relationship, and a problem report is generated based on the device information, including:

[0032] The device information corresponding to the differing leaf node is determined through the index relationship; the device information includes at least the device name and deployment location information.

[0033] Based on the device information, the hash value changes of the differential leaf nodes, the Merkle tree state information, and the record information of the block header, a problem report containing device identifiers and configuration change information is generated.

[0034] Optionally, based on the index relationship, the actual configuration status of the corresponding device is analyzed, and a problem report is generated based on the actual configuration status, including:

[0035] Based on the index relationship, the collection list is queried by empty file name, and the device configuration status is verified again by remote connection.

[0036] If the device can be logged in but the configuration information is empty, return the device name and an empty file error message.

[0037] If device login fails, the system will return the device name and a message indicating a login connection error.

[0038] If the configuration information is not empty, then switch to the process that is not empty.

[0039] Secondly, embodiments of this application provide a fault location system for operator equipment, comprising:

[0040] The first processing module is used to obtain the configuration information of the equipment in each data center of the operator, and to construct an index relationship between the equipment name and the location based on the configuration information.

[0041] The second processing module is used to determine whether the configuration information is empty;

[0042] The third processing module is used to analyze the actual configuration status of the corresponding device according to the index relationship if the index is empty, and generate a problem report based on the actual configuration status.

[0043] The fourth processing module is used to construct a Merkle tree and blockchain blocks based on the configuration information of the operator's equipment if the information is not empty; recursively compare the root hash values ​​of the current block and historical blocks based on the Merkle tree to determine the first change in the difference block; compare the tree nodes of the current block and the difference block layer by layer to determine the difference leaf nodes; determine the device information corresponding to the difference leaf nodes through the index relationship, and generate a problem report based on the device information.

[0044] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any one of the first aspects.

[0045] Fourthly, embodiments of this application provide a computer program product, including computer instructions that, when executed by a processor, implement the steps of the method as described in any one of the first aspects.

[0046] Compared with existing technologies, the operator equipment fault location method, system, medium and product provided in this application obtains the operator's data center equipment configuration information and constructs an index relationship between equipment name and location. When the configuration is empty, the actual configuration is analyzed according to the index to generate a report. When it is not empty, a Merkle tree and blockchain block of the equipment configuration are constructed. By comparing hashes, the difference leaf node of the first change and the corresponding equipment are located, and a problem report is automatically generated. No manual backtracking is required. The faults caused by configuration changes are accurately delineated, allowing configuration checks to play a key role in fault location and improving inspection efficiency. Attached Figure Description

[0047] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0048] Figure 1 A flowchart illustrating the operator equipment fault location method provided in this application embodiment;

[0049] Figure 2 A schematic diagram of the construction structure of a Merkle tree provided in the embodiments of this application;

[0050] Figure 3 This is a schematic diagram illustrating the changes in the Merkle tree when a new device is added, as provided in an embodiment of this application.

[0051] Figure 4 A comparative schematic diagram of the Merkle tree provided in the embodiments of this application;

[0052] Figure 5 This is a schematic diagram of the structure of the operator equipment fault location device provided in the embodiments of this application.

[0053] Figure 6 This is a schematic diagram of the structure of the operator equipment fault location system provided in the embodiments of this application. Detailed Implementation

[0054] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, without limiting the number of objects; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, "A or B" covers three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0055] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc.; an indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0056] To enable those skilled in the art to better understand the embodiments of this application, the following description is provided first:

[0057] Merkle trees are a mainstream technology in blockchain. They are tree-like data structures where each node is a cryptographic hash of its child nodes. The Merkle root is located at the top of the trees and represents the entire dataset. It is a collision-resistant hash function, denoted by MHT, which accepts n inputs (x1, x2, ..., xn) and outputs the Merkle root hashh = MHT(x1, x2, ..., xn). It is commonly used for storing and verifying transactions. Transactions are first hashed individually, then combined in pairs, and then hashed again to create new nodes. This process is repeated until only one node remains, the Merkle root.

[0058] Hash: Generally translated as hashing, hashing, or transliterated as hash, it is the process of transforming an input of arbitrary length (also called a pre-image) into a fixed-length output through a hash algorithm. This output is the hash value.

[0059] SHA256: SHA-256 is an abbreviation for Secure Hash Algorithm 256-bit. It adopts the Merkle-Damgard structure, processes the input data in blocks, and generates a 256-bit hash value through a series of operations.

[0060] Rollup State Tree is a data structure used to efficiently store and manage the state of a blockchain. Rollup technology reduces the burden on the main chain and improves the throughput and scalability of the blockchain system by compressing and transferring large amounts of transaction data to a secondary chain (also known as a Rollup chain) for processing.

[0061] This application provides a method, system, medium, and product for locating faults in operator equipment. The method and system are based on the same concept, and since the principles underlying the problem-solving are similar, their implementations can be mutually referenced; repeated details will not be elaborated further.

[0062] Please refer to Figure 1 This application provides a method for locating faults in operator equipment, comprising:

[0063] Step 11: Obtain the configuration information of the equipment in each data center of the operator, and construct an index relationship between the equipment name and the location based on the configuration information;

[0064] Step 12: Determine whether the configuration information is empty;

[0065] Step 13: If empty, analyze the actual configuration status of the corresponding device according to the index relationship, and generate a problem report based on the actual configuration status.

[0066] Step 14: If not empty, construct a Merkle tree and blockchain blocks based on the configuration information of the operator's equipment; based on the Merkle tree, recursively compare the root hash values ​​of the current block and historical blocks to determine the first change in the difference block; compare the tree nodes of the current block and the difference block layer by layer to determine the difference leaf nodes; determine the device information corresponding to the difference leaf nodes through the index relationship, and generate a problem report based on the device information.

[0067] In this embodiment, configuration information of all data center equipment is acquired, and an index relationship between equipment names and locations is established. Addressing the challenges of numerous equipment involved in business operations and difficulties in fault localization, the index relationship enables rapid association between equipment information and physical location, laying the foundation for accurate subsequent location of faulty equipment and avoiding location confusion during manual troubleshooting. Null value validation is performed on the acquired configuration information, with two processing scenarios. Addressing the issue that existing configuration checks are merely supplementary to monitoring and lack specificity, categorized processing ensures that different configuration states (empty or non-empty) can be accurately checked, avoiding missed detections caused by uniform processing.

[0068] If the configuration information is empty, based on the index relationship in step 11, analyze the actual configuration status of the corresponding device and generate a problem report. Quickly locate the location of the empty configuration device through the index, directly analyze the actual status and output a report, without the need for manual backtracking, making configuration check the direct basis for fault location.

[0069] In non-empty configuration scenarios, a Merkle tree of device configuration and blockchain blocks are constructed. The first change difference block is located by recursively comparing the root hash value of the tree. Then, the difference leaf node is found by comparing the tree nodes layer by layer. Finally, the device information is associated with the index to generate a report.

[0070] It should be noted that, in response to the issue of manual backtracking required for configuration change failures, the blockchain stores historical configurations, and Merkle tree hash comparison enables automated difference location, replacing manual backtracking of recent changes; in response to the difficulty of fault delimitation, layer-by-layer comparison from block to leaf node accurately identifies the devices with the first change, avoiding large-scale investigation; making configuration inspection a key link in fault location, directly outputting problem reports, and improving inspection efficiency.

[0071] Optionally, based on the index relationship, the actual configuration status of the corresponding device is analyzed, and a problem report is generated based on the actual configuration status, including:

[0072] Based on the index relationship, the collection list is queried by empty file name, and the device configuration status is verified again by remote connection.

[0073] If the device can be logged in but the configuration information is empty, return the device name and an empty file error message.

[0074] If device login fails, the system will return the device name and a message indicating a login connection error.

[0075] If the configuration information is not empty, then switch to the process that is not empty.

[0076] In this embodiment, based on the constructed device name-location index relationship, the configuration collection list is first queried by empty file name to locate the target device with empty configuration for initial collection. The target device is then remotely connected to verify its actual configuration status again to avoid possible errors in the initial collection. The secondary verification result is processed in three categories: Case 1: The device can log in normally, and after verification, it is confirmed that the configuration information is empty, and the device name and empty file error are directly returned; Case 2: The device cannot log in, and the remote connection fails, so the device name and login connection error are returned; Case 3: After verification, it is found that the configuration information is not empty, so the process automatically switches to the non-empty configuration scenario processing flow in step 14, constructs the Merkle tree of the device configuration and the blockchain block, and performs hash comparison to locate the difference.

[0077] Specifically, for cases where the loaded file is empty, the configuration acquisition unit analyzes the cause. The execution method is as follows: First, query the user-defined collection list based on the filename of the empty file; second, remotely connect to the device via API interface call or SSH protocol to re-check the configuration and confirm whether it is empty; third, if the device can log in and the file is empty, return the device name and empty file error to the report generation unit for the user to conduct subsequent troubleshooting; if the device login fails, return the device name and login connection error to the report generation unit; if it is not empty, proceed with step 14.

[0078] Optionally, obtain the configuration information of the equipment in each of the operator's data center computer rooms, including:

[0079] Read the predefined collection list;

[0080] Based on the collection list, access the equipment in each data center of the operator via remote connection;

[0081] Persist the runtime configuration in the device's memory to the configuration information;

[0082] When a single device needs to save multiple configuration information, determine the compressed package to be named after the device;

[0083] The configuration information or compressed package is remotely copied to the configuration acquisition server. The configuration information of the equipment in each data center of the operator is obtained through the acquisition server. The configuration information includes at least the configuration information required for the operation of the operator's network and server equipment.

[0084] In this embodiment, a predefined collection list is read, which contains key information such as the collection object and collection method, clarifying the scope of devices to be collected and the operation method. Based on the collection list, the corresponding remote connection method is selected according to the device type. Network devices use API interface calls, and server devices use the SSH protocol to access the target devices in each data center. The configuration running in the device's memory in real time is first persisted to the configuration file to avoid the collection being invalid due to temporary loss of memory configuration. If a single device needs to save multiple configuration files, they are packaged and compressed, and the compressed package is named with the device name, which contains the hierarchical information of data center-server room-rack-device name. The single configuration file or compressed package is remotely copied to the configuration collection server. The server creates a directory to store files according to the current timestamp. Finally, the configuration information of all devices is uniformly obtained from the server. The configuration information includes the configuration required for the operation of network devices and server devices.

[0085] This process involves several key aspects. First, reading a predefined collection list allows for clear identification of collection targets and methods, preventing indiscriminate traversal of all devices and ensuring precise target identification. This addresses the challenge of dealing with numerous devices used by operators, reducing unnecessary operations, improving collection efficiency, and laying the foundation for rapid subsequent processing. Second, adaptive remote connection selects appropriate remote connection methods based on differences in network and server devices, ensuring successful access for various device types. This resolves potential issues related to complex device types and insufficient collection compatibility, guaranteeing comprehensive collection coverage, preventing configuration omissions due to device incompatibility, and improving the completeness of inspections. Third, persistently storing the running configuration in memory ensures that the collected configuration is the current, valid, and stable running configuration for the device. This addresses the issue of insufficient accuracy in existing configuration checks, providing reliable raw data for subsequent Merkle tree construction and hash comparison, and preventing misjudgments in fault location due to invalid collected data.

[0086] Packaging and compressing configuration files reduces file transfer volume and storage redundancy, facilitating management. Device names contain hierarchical location information, and compressed packages are named after device names, allowing direct association of device physical locations through filenames. This addresses the difficulty of fault delimitation and provides a natural naming association foundation for subsequent device name-location index construction, eliminating the need for additional cumbersome matching and improving subsequent location efficiency.

[0087] Configuration files are centrally stored on the server for easy retrieval later, such as for building blockchain blocks and comparing historical configurations, avoiding retrieval difficulties caused by scattered configuration storage; the timestamp directory distinguishes different collection batches and clearly records the configuration collection time, providing a time dimension basis for comparing the current block with historical blocks, solving the problem of difficult traceability of configuration changes, supporting automated difference positioning, replacing manual backtracking, and improving the systematicness and traceability of inspection.

[0088] Optionally, based on the configuration information of the operator's equipment, a Merkle tree and blockchain blocks are constructed, including:

[0089] Perform a hash calculation on the configuration information to determine the hash calculation result;

[0090] Based on the index relationship, the hash calculation result is used as a leaf node, and the hash values ​​of two adjacent leaf nodes are concatenated and serialized. The concatenated and serialized hash value is used as an intermediate node. The process is repeated layer by layer from the intermediate node until a single root node is generated, thus constructing a Merkle tree.

[0091] Based on the Merkle tree, a blockchain block containing a block header and a block body is generated; the block header contains at least the parent block hash value, the root hash value of the Merkle tree, and a timestamp; the block body contains at least the input list corresponding to the index relationship and the output list corresponding to the Merkle tree structure.

[0092] It should be noted that the mapping relationship between device names and logical locations can be implemented with reference to the "Rollup StateTree". For the key-value pairs in the mapping relationship, after sorting according to preset rules (such as lexicographical order of device names), a unique index relationship is established, as shown in the following example: Index relationship: {sz-xcdc-c05-server8:0,sz-xqdc-b03-switch2:1,sz-yqdc-a02-route1:2,sz-yqdc-d05-route2:3}. The "Rollup StateTree" here is the core data structure used in blockchain scaling technology to manage the state of off-chain transactions. Its evolution mainly involves two mainstream algorithms: Optimistic Rollup and ZK Rollup, which ensure state correctness through fraud proof and validity proof, respectively. These will not be explained in detail here.

[0093] In this embodiment, the data directory corresponding to the latest timestamp of the configuration collection server is loaded. The configuration information of each data center device of the operator within the directory is then hashed. Here, SHA256 hash calculation can be performed. By default, the device must have initial configuration; the absence of a configuration file is considered an anomaly. The hash calculation result is then determined. Once the device file collection is normal (not empty) and the index relationship is established, the blockchain data structure construction process is initiated. The blockchain core consists of two parts: the block header and the block body, specifically defined as follows:

[0094] The block header is used to store metadata information and contains at least three core fields. After serializing the data by concatenating the three fields, the current block hash value is generated by SHA256 hash calculation. The block body is used to store file association information and contains at least an input list and an output list, which correspond to the index relationship and the complete Merkle tree structure, respectively. The Merkle tree contains leaf nodes and intermediate nodes.

[0095] It should be noted that the block header and block body are shown in Table 1.

[0096] Table 1:

[0097]

[0098] The block header includes at least the hash value of the previous block header (i.e., the hash value of the parent block), the root hash value of the Merkle tree of the block's transactions, and a Unix timestamp accurate to the second generated by the block. By concatenating these three fields, the serialized block header data is obtained, and then a SHA256 hash calculation is performed to obtain the block hash value at the current time, as shown in Table 2.

[0099] Table 2:

[0100]

[0101] Furthermore, during the construction of the Merkle tree, the leaf nodes are initialized as follows: At the bottom level of the Merkle tree, the SHA256 hash calculation results of each device configuration file are used as leaf nodes according to the index order in the generated index relationship. Intermediate node calculation (first level): The hash values ​​of two adjacent leaf nodes are concatenated and serialized. SHA256 hash calculation is performed on the serialized result to generate the first-level intermediate nodes. Intermediate node recursive calculation: The above concatenation, serialization, and hash calculation logic is repeated to generate higher-level intermediate nodes layer by layer. If the number of nodes at a certain level is odd, the rightmost node does not need to be concatenated; its hash value is directly retained as the corresponding level's intermediate node. Root node generation: The recursive calculation continues to the top level to obtain a unique single root node (Merkle-root), whose hash value is Merkle-root-Hash, and is written to the block header. Through the above process, the Merkle tree is constructed.

[0102] Reference Figure 2The diagram illustrates the Merkle Tree structure. Through layer-by-layer hash calculations, the original configuration data is aggregated into a unique root hash, used to verify data integrity. The layers are explained below: The bottom layer: Original data (configuration files). This layer is the original data source of the Merkle Tree, containing four configuration files: Configg1, Configg2, Configg3, and Configg4. These can be understood as the specific configuration files for the operator's equipment. The second layer: Leaf nodes (hash values ​​of the original data). A hash calculation is performed on each original configuration file to obtain the leaf nodes of the Merkle Tree: Hash Configg1 → Hashg0 (labeled hash(Config)); Hash Configg2 → Hashg1 (labeled hash(Config)); Hash Configg3 → Hashb0 (labeled hash(Config)); Hash Configg4 → Hashb1 (labeled hash(Config)). The third layer: intermediate nodes (the hash concatenation result of adjacent leaf nodes). The hash values ​​of two adjacent leaf nodes are concatenated and then hashed again to obtain the intermediate node: concatenating Hashg0 + Hashg1 and hashing → Hashn (labeled hash(g0+g1)); concatenating Hashb0 + Hashb1 and hashing → Hashb (labeled hash(b0+b1)). The top layer: root node (Merkel root). The hash values ​​of adjacent intermediate nodes are concatenated and then hashed again to obtain the Merkle tree root hash (RootHash): concatenating Hashn + Hashb and hashing → RootHash (labeled hash(n+b)). Merkle trees are used because any modification to the original configuration file (such as Configg1) will change the hash of the corresponding leaf node, leading to changes in the results of all nodes in the upper layer (up to the root hash). By verifying the root hash, it is possible to quickly confirm whether the underlying configuration data is complete and has not been tampered with.

[0103] It should be noted that when the operator's network topology changes and new devices are added, the configuration tree generation unit typically inserts a new path on the right side of the Merkle tree. By performing a hash calculation with the previous Merkle root hash value, the changes to the values ​​of intermediate and leaf nodes in the tree can be minimized. This can be combined with... Figure 2 and Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the changes in the Merkle tree when a new device is added.

[0104] Optionally, based on the Merkle tree, the root hash values ​​of the current block and historical blocks are recursively compared to determine the first difference block of the change, including:

[0105] Retrieve the first hash value of the parent block stored in the block header of the current block;

[0106] Based on the Merkle tree, match the root hash value of the block header corresponding to the parent block;

[0107] If the root hash value is inconsistent with the first hash value, then the root hash value of the previous level historical block is recursively traced until a block consistent with the first hash value is found.

[0108] The next level block of the consistent block is identified as the difference block that is the first to experience a configuration change.

[0109] In this embodiment, by comparing the Merkle root hash, the block where the operator's equipment configuration has changed for the first time is located. This is performed by the chain acquisition unit, which obtains the parent block hash (H0) of the current block, reads the block header of the current block, and extracts the Merkle root hash of the parent block recorded therein, denoted as H0. This is the root hash that the current block believes the parent block should have. The actual root hash (H1) of the parent block is matched, and the chain acquisition unit initially finds the parent block corresponding to the current block. The actual Merkle root hash in the parent block header is read and denoted as H1. If H0 = H1, it means that the equipment configuration from the parent block to the current block has not changed, and the query is directly terminated, returning these two blocks. If H0 ≠ H1, it means that the configuration from the parent block to the current block has changed, and it is necessary to continue tracing back to earlier historical blocks. The process recursively traces back to the previous block, locating the starting point of the difference and continuously searching upwards for the parent block of the parent block. The Merkle root hashes of these historical blocks (denoted as H2, H3…HN) are read sequentially and compared with H0 one by one until a historical block is found whose root hash equals H0 (i.e., H0=HN). At this point, the next-level block of this block with root hash HN is the difference block where the device configuration change first occurred.

[0110] Based on the parent hash (H0) of the current block, recursively match the root hash of historical blocks; the first block whose root hash does not match H0 is the parent block of the final node whose configuration has not changed, and it itself is the first changed difference block.

[0111] Assume the operator's blockchain sequence, from earliest to latest generation time: Block A (root hash Ha), Block B (root hash Hb, parent hash Ha), Block C (root hash Hc, parent hash Hb), current Block D (root hash Hd, parent hash Hc), where the parent hash H0 of current Block D is equal to Hc (the parent block hash recorded in the Block D header); matching the actual root hash H1 of parent Block C to Hc' (≠ H0) indicates a change from Block C to D, so the tracing continues; recursively searching for the parent block B of Block C, whose root hash H2 is equal to Hb (≠ H0), the tracing continues; searching for the parent block A of Block B, if the root hash Hb of Block B is finally found to be H0, the query stops; at this point, the next level after Block B (Block C) is the first difference block where the configuration change occurred.

[0112] Optionally, the tree nodes of the current block and the differing blocks are compared layer by layer to determine the differing leaf nodes, including:

[0113] Determine the corresponding intermediate node hash value between the current block and the differing block;

[0114] Based on the hash value of the intermediate node, the difference branch is determined. Starting from the root node of the Merkle tree, the child nodes at each level are compared downwards along the difference branch until the leaf node level of the Merkle tree is reached. Leaf nodes with inconsistent hash values ​​are identified as difference leaf nodes.

[0115] In this embodiment, by tracing the Merkle tree nodes from root to leaf, layer by layer, the hash values ​​of the current block and the difference block are compared to accurately locate the device with the configuration change (corresponding to the difference leaf node). Tracing downwards from the top root node of the Merkle tree, the specific leaf node with the configuration change is identified. The leaf node corresponds to the configuration file hash of a single device. The execution logic is as follows: Extracting intermediate node hash values: The configuration tree query unit first obtains the hash values ​​of the intermediate nodes at each level in the Merkle tree of the current block and the difference block. Locating the difference branch: Comparing the hash values ​​of intermediate nodes at the same level, the first node with an inconsistent hash value is found. The branch containing this node is the difference branch, indicating that the configuration change occurred under this branch. Tracing downwards layer by layer: Starting from the difference branch, the hash values ​​of each level of child nodes (intermediate node → child intermediate node) are compared downwards along this branch, continuously narrowing the investigation scope. Determining the difference leaf node: After tracing to the Merkle tree leaf node level, the leaf node with inconsistent hash values ​​is determined as the difference leaf node. The device indexed by this leaf node is the device with the configuration change.

[0116] The configuration tree query unit first extracts the hash values ​​of intermediate and leaf nodes of the Merkle tree in the block bodies of the current block and the difference block, and then completes precise positioning in the following two steps: Step 1: Locate the difference branch starting from the root node. Starting from the root node level of the Merkle tree, compare the hash values ​​of the intermediate nodes associated with the root nodes of the current block and the difference block. In the example, this is the child node corresponding to Hash a. It is found that the hash value of the right intermediate node has changed from Hash b to Hash c. The hash values ​​of this node are inconsistent between the two blocks, so the right branch is determined to be the difference branch, and the configuration change occurred within the device range covered by this branch. Step 2: Trace along the difference branch to the leaf node. Starting with the intermediate node (Hash b or Hash c) of the right-hand difference branch, continue comparing the hash values ​​of the next-level intermediate nodes in the Merkle tree of the two blocks, narrowing the search scope layer by layer until finally tracing back to the leaf node level: It is found that the original leaf node hash value hash b1 has changed to hash d1, and the index position of this leaf node in the Merkle tree is 3, corresponding to the previously established Map index: {sz-yqdc-d05-route2:3}. Therefore, it is determined that the leaf node corresponding to hash d1 is the difference leaf node, meaning that the sz-yqdc-d05-route2 device corresponding to this index has undergone a configuration change. The characteristics of the Merkle tree determine that any change in a leaf node (device configuration) will cause a change in the hashes of all intermediate nodes above it. Therefore, comparing downwards from the root node can quickly pinpoint the difference branch, and then tracing layer by layer can accurately find the unique changed device, avoiding the inefficient operation of comparing configuration files for each device individually.

[0117] Reference Figure 4 The diagram illustrates the changes in the tree structure and the positioning logic when the device configuration changes. Figure 4 The left side of the diagram is the original Merkle tree structure, with the root node being hash(root1), which is composed of the left middle node Hash a (corresponding to hash(Hash 1+Hash2)) and the right middle node Hash b (corresponding to hash(Hash 3+Hash 4)). The leaf nodes are the configuration hashes of devices 1-4, hash(Config1)-hash(Config4), corresponding to indices 1-4. Figure 4 The right side of the diagram shows the Merkle tree after the device configuration changes. The root node becomes hash(root2) because the middle node on the right is updated from Hash b to Hash c (corresponding to hash(Hash 3+Hash 5)). In the leaf nodes, the configuration hash of device 4 changes from hash(Config4) to hash(Config5), while the configurations of the other devices remain unchanged.

[0118] During the process of locating the differential leaf node, by comparing the root node subtree, it was found that the right middle node Hash b ≠ Hash c, thus locking the right branch; by comparing the middle node of the right branch, it was found that the leaf node hash(Config4) ≠ hash(Config5), thus determining that index 4 is the differential leaf node, and the corresponding device 4 has undergone configuration changes.

[0119] For example, such as Figure 4 As shown, starting from the Merkle root node, the values ​​of Hash a and Hash b in the Merkle trees of the two blocks are compared respectively. It is found that the value on the right side has changed to Hash c, so the difference device is the right branch. Starting from the middle node of Hash b and Hash c on the right side of the two blocks, the values ​​of the middle nodes in the Merkle trees of the two blocks are compared downwards. The difference node is found, and finally the configuration leaf hash b1 is located to hash d1. That is, hash d1 is the node with configuration change, and its index position is located at position 3 in the Merkle tree.

[0120] Optionally, the device information corresponding to the differing leaf node is determined through the index relationship, and a problem report is generated based on the device information, including:

[0121] The device information corresponding to the differing leaf node is determined through the index relationship; the device information includes at least the device name and deployment location information.

[0122] Based on the device information, the hash value changes of the differential leaf nodes, the Merkle tree state information, and the record information of the block header, a problem report containing device identifiers and configuration change information is generated.

[0123] In this embodiment, the process from the leaf node of the difference to device location and then to the generation of the problem report utilizes the index relationship established in the early stage to transform the technical hash differences into a feasible device problem report. By leveraging the mapping relationship between device name and logical index built in the index relationship, the index of the leaf node of the difference is associated with the device information: first, the index value corresponding to the located leaf node of the difference is obtained; then, using the index relationship, the device information corresponding to that index is directly locked; the final device information includes at least: device name and deployment location. The state information, index information, block header record information, and device configuration information of the Merkle tree along the analysis path are summarized to generate a problem report detail, providing a basis for the user's subsequent repair work.

[0124] like Figure 5 As shown, the present invention proposes a fault location device for operator equipment, comprising:

[0125] The configuration acquisition unit 100 is used to acquire key configuration information of equipment in various data center computer rooms of the operator; the key configuration information includes at least the configuration information required for the operation of equipment such as the operator's network and servers. The tasks performed include at least remotely connecting to the device through device API interfaces, SSH protocols, etc., and saving and remotely copying the running configuration to the configuration acquisition server.

[0126] The configuration tree generation unit 200 is used to calculate the key configuration information of operator equipment and construct a Merkle tree structure. The calculation results include at least the SHA256 hash values ​​of the configuration information required for the operation of the operator network and server equipment. It also constructs the block header and block body according to the blockchain data structure. The block header includes at least the hash value of the previous block header (i.e., the hash value of the parent block), the root hash value of the Merkle tree of the block transactions, and a Unix timestamp accurate to the second generated by the block. The block body includes at least an input list and an output list, i.e., the structure of the Merkle tree, including intermediate nodes and leaf nodes. Simultaneously, it constructs the Map index for the leaf nodes, realizing the mapping between device names and location indexes.

[0127] The chain retrieval unit 300 is used to find the block header content of the parent block based on the parent block hash value stored in the current block header. If the Merkle root hash value in the current block header is the same as the Merkle root hash value in the parent block header, the search for the Merkle root hash value of the parent's parent block header is performed recursively until a block with a different Merkle root hash value is found.

[0128] The configuration tree query unit 400 is used to obtain the values ​​of intermediate nodes and leaf nodes in the Merkle tree. Starting from the Merkle root node, by comparing the values ​​of intermediate nodes in the Merkle trees of two blocks layer by layer, the difference node is found, and finally the position of the leaf node causing the difference is located. The device name corresponding to the position of the difference leaf node is retrieved through the Map index, thus completing the location of the device where the configuration change has occurred.

[0129] The report generation unit 500 is used to generate problem details information from the Merkle tree status information, index information, block header record information, device configuration information, etc.

[0130] In summary, the solution presented in this application combines blockchain Merkle Tree technology and its evolved solution (Rollup StateTree) to achieve information immutability and ensure the trustworthiness of data sources. By constructing a Merkle Tree view of device configurations across the entire operator's jurisdiction, all device configuration information in each region is uniformly uploaded to the blockchain. Given the high availability characteristics of blockchain technology, this method and device incur no additional maintenance costs. Through device configuration acquisition units, configuration tree generation units, chain acquisition units, configuration tree query units, and report generation units, the application enables rapid inspection and problem localization of operator device configurations, effectively supplementing the operator's existing operation and maintenance system. This application fully leverages the immutability and continuous operation of blockchain, combined with the current situation of operators managing massive numbers of devices, to effectively locate device configuration changes caused by configuration modifications, human error, system bugs, etc.

[0131] The various methods described above are based on embodiments of this application. A system for implementing the above methods will be further provided below.

[0132] Please refer to Figure 6 This application also provides a fault location system for operator equipment, including:

[0133] The first processing module 61 is used to obtain the configuration information of the equipment in each data center of the operator, and to construct an index relationship between the equipment name and the location based on the configuration information.

[0134] The second processing module 62 is used to determine whether the configuration information is empty;

[0135] The third processing module 63 is used to analyze the actual configuration status of the corresponding device according to the index relationship if the index is empty, and generate a problem report according to the actual configuration status.

[0136] The fourth processing module 64 is used to construct a Merkle tree and blockchain blocks based on the configuration information of the operator equipment if the information is not empty; recursively compare the root hash values ​​of the current block and historical blocks based on the Merkle tree to determine the first change of the difference block; compare the tree nodes of the current block and the difference block layer by layer to determine the difference leaf nodes; determine the device information corresponding to the difference leaf nodes through the index relationship, and generate a problem report based on the device information.

[0137] Optionally, the first processing module 61 is specifically used for:

[0138] Read the predefined collection list;

[0139] Based on the collection list, access the equipment in each data center of the operator via remote connection;

[0140] Persist the runtime configuration in the device's memory to the configuration information;

[0141] When a single device needs to save multiple configuration information, determine the compressed package to be named after the device;

[0142] The configuration information or compressed package is remotely copied to the configuration acquisition server. The configuration information of the equipment in each data center of the operator is obtained through the acquisition server. The configuration information includes at least the configuration information required for the operation of the operator's network and server equipment.

[0143] Optionally, the second processing module 62 is specifically used for:

[0144] Perform a hash calculation on the configuration information to determine the hash calculation result;

[0145] Based on the index relationship, the hash calculation result is used as a leaf node, and the hash values ​​of two adjacent leaf nodes are concatenated and serialized. The concatenated and serialized hash value is used as an intermediate node. The Merkle tree is constructed by recursively building from the intermediate node until a single root node is generated.

[0146] Based on the Merkle tree, a blockchain block containing a block header and a block body is generated; the block header contains at least the parent block hash value, the root hash value of the Merkle tree, and a timestamp; the block body contains at least the input list corresponding to the index relationship and the output list corresponding to the Merkle tree structure.

[0147] Optionally, the second processing module 62 is also specifically used for:

[0148] Retrieve the first hash value of the parent block stored in the block header of the current block;

[0149] Based on the Merkle tree, match the root hash value of the block header corresponding to the parent block;

[0150] If the root hash value is inconsistent with the first hash value, then the root hash value of the previous level historical block is recursively traced until a block consistent with the first hash value is found.

[0151] The next level block of the consistent block is identified as the difference block that is the first to experience a configuration change.

[0152] Optionally, the second processing module 62 is also specifically used for:

[0153] Determine the corresponding intermediate node hash value between the current block and the differing block;

[0154] Based on the hash value of the intermediate node, the difference branch is determined. Starting from the root node of the Merkle tree, the child nodes at each level are compared downwards along the difference branch until the leaf node level of the Merkle tree is reached. Leaf nodes with inconsistent hash values ​​are identified as difference leaf nodes.

[0155] Optionally, the second processing module 62 is also specifically used for:

[0156] The device information corresponding to the differing leaf node is determined through the index relationship; the device information includes at least the device name and deployment location information.

[0157] Based on the device information, the hash value changes of the differential leaf nodes, the Merkle tree state information, and the record information of the block header, a problem report containing device identifiers and configuration change information is generated.

[0158] Optionally, the third processing module 63 described above is specifically used for:

[0159] Based on the index relationship, the collection list is queried by empty file name, and the device configuration status is verified again by remote connection.

[0160] If the device can be logged in but the configuration information is empty, return the device name and an empty file error message.

[0161] If device login fails, the system will return the device name and a message indicating a login connection error.

[0162] If the configuration information is not empty, then switch to the process that is not empty.

[0163] It should be noted that the system in this embodiment corresponds to the above-described operator equipment fault location method. The implementation methods in the above embodiments are all applicable to the embodiments of this system and can achieve the same technical effect. The system provided in this application embodiment can implement all the method steps implemented in the above method embodiments and can achieve the same technical effect. Therefore, the parts that are the same as those in the method embodiments and the beneficial effects will not be described in detail here.

[0164] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described operator equipment fault location method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may include read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0165] This application also provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the above-described operator equipment fault location method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0166] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0167] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0168] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for locating faults in operator equipment, characterized in that, include: Obtain the configuration information of the equipment in each data center of the operator, and construct an index relationship between the equipment name and the location based on the configuration information; Determine whether the configuration information is empty; If the index is empty, the actual configuration status of the corresponding device is analyzed according to the index relationship, and a problem report is generated based on the actual configuration status. If not empty, construct a Merkle tree and blockchain blocks based on the configuration information of the operator equipment; based on the Merkle tree, recursively compare the root hash values ​​of the current block and historical blocks to determine the first change in the difference block; compare the tree nodes of the current block and the difference block layer by layer to determine the difference leaf nodes; The device information corresponding to the differential leaf node is determined through the index relationship, and a problem report is generated based on the device information.

2. The method according to claim 1, characterized in that, Obtain the configuration information of equipment in each data center of the operator, including: Read the predefined collection list; Based on the collection list, access the equipment in each data center of the operator via remote connection; Persist the runtime configuration in the device's memory to the configuration information; When a single device needs to save multiple configuration information, determine the compressed package to be named after the device; The configuration information or compressed package is remotely copied to the configuration acquisition server. The configuration information of the equipment in each data center of the operator is obtained through the acquisition server. The configuration information includes at least the configuration information required for the operation of the operator's network and server equipment.

3. The method according to claim 1, characterized in that, Based on the configuration information of the operator's equipment, a Merkle tree and blockchain blocks are constructed, including: Perform a hash calculation on the configuration information to determine the hash calculation result; Based on the index relationship, the hash calculation result is used as a leaf node, and the hash values ​​of two adjacent leaf nodes are concatenated and serialized. The concatenated and serialized hash value is used as an intermediate node. The Merkle tree is constructed by recursively building from the intermediate node until a single root node is generated. Based on the Merkle tree, a blockchain block containing a block header and a block body is generated; the block header contains at least the parent block hash value, the root hash value of the Merkle tree, and a timestamp; the block body contains at least the input list corresponding to the index relationship and the output list corresponding to the Merkle tree structure.

4. The method according to claim 1, characterized in that, Based on the Merkle tree, the root hash values ​​of the current block and historical blocks are recursively compared to determine the first difference block after the change, including: Retrieve the first hash value of the parent block stored in the block header of the current block; Based on the Merkle tree, match the root hash value of the block header corresponding to the parent block; If the root hash value is inconsistent with the first hash value, then the root hash value of the previous level historical block is recursively traced until a block consistent with the first hash value is found. The next level block of the consistent block is identified as the difference block that is the first to experience a configuration change.

5. The method according to claim 1, characterized in that, By comparing the tree nodes of the current block with those of the differing blocks layer by layer to determine the differing leaf nodes, the process includes: Determine the corresponding intermediate node hash value between the current block and the differing block; Based on the hash value of the intermediate node, the difference branch is determined. Starting from the root node of the Merkle tree, the child nodes at each level are compared downwards along the difference branch until the leaf node level of the Merkle tree is reached. Leaf nodes with inconsistent hash values ​​are identified as difference leaf nodes.

6. The method according to claim 1, characterized in that, Based on the index relationship, the device information corresponding to the differing leaf node is determined, and a problem report is generated based on the device information, including: The device information corresponding to the differing leaf node is determined through the index relationship; the device information includes at least the device name and deployment location information. Based on the device information, the hash value changes of the differential leaf nodes, the Merkle tree state information, and the record information of the block header, a problem report containing device identifiers and configuration change information is generated.

7. The method according to claim 1, characterized in that, Based on the index relationship, analyze the actual configuration status of the corresponding device, and generate a problem report based on the actual configuration status, including: Based on the index relationship, the collection list is queried by empty file name, and the device configuration status is verified again by remote connection. If the device can be logged in but the configuration information is empty, return the device name and an empty file error message. If device login fails, the system will return the device name and a message indicating a login connection error. If the configuration information is not empty, then switch to the process that is not empty.

8. A fault location system for operator equipment, characterized in that, include: The first processing module is used to obtain the configuration information of the equipment in each data center of the operator, and to construct an index relationship between the equipment name and the location based on the configuration information. The second processing module is used to determine whether the configuration information is empty; The third processing module is used to analyze the actual configuration status of the corresponding device according to the index relationship if the index is empty, and generate a problem report based on the actual configuration status. The fourth processing module is used to construct a Merkle tree and blockchain blocks based on the configuration information of the operator equipment if the data is not empty; recursively compare the root hash values ​​of the current block and historical blocks based on the Merkle tree to determine the first change of the difference block; and compare the tree nodes of the current block and the difference block layer by layer to determine the difference leaf nodes. The device information corresponding to the differential leaf node is determined through the index relationship, and a problem report is generated based on the device information.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 7.

Images