Scalable event-driven automated diagnostic system

Abstract

A method (400) for scalable event-driven automated diagnosis includes obtaining a data packet (114) configured to be transmitted from a source address to a destination address over a network (175). The method includes obtaining a list of changes (112) to the network. The method further includes analyzing the data packet using a plurality of analyzers (255) based on a network model (265). The method includes associating the list of changes to the network with the analysis of the data packet. The method further includes determining a configuration state (301) of the network based on a correlation between the list of changes to the network and the analysis of the data packet. The method further includes reporting the configuration state (12) to a user.

Description

Technical Field

[0001] This disclosure relates to a scalable, event-driven automated diagnostic system. Background Technology

[0002] Most network outages (e.g., 60-85%) can be attributed to configuration changes. Due to the complexity of cloud network configurations, network administrators often find it difficult to validate new configurations across many different functional dependencies. Unexpected breakdowns often occur due to changes in different regions for various reasons. Outdated, inconsistent, and / or incomplete configurations also frequently exist; maintaining, discovering, and remediating these configurations is costly, and their presence poses risks to the customer's network. Summary of the Invention

[0003] One aspect of this disclosure provides a method for scalable, event-driven automated diagnostics. When executed by data processing hardware, the method causes the hardware to perform operations including acquiring data packets configured to be transmitted over a network from a source address to a destination address, and a list of network changes. These operations include analyzing the data packets using multiple analyzers based on a network model. These operations also include correlating the network change list with the analysis of the data packets. These operations include determining the network's configuration status based on the correlation between the network change list and packet analysis. These operations include reporting the configuration status to the user.

[0004] Implementations of this disclosure may include one or more of the following optional features. In some implementations, at least one of the plurality of analyzers includes a default analyzer that analyzes a default rule set. In other implementations, at least one of the plurality of analyzers includes a custom analyzer that analyzes a custom rule set provided by a user. In these implementations, the custom rule set may include Internet Protocol (IP) range classifications. Furthermore, the default rule set may include firewall configuration rules. In various implementations, the configuration state may include one or more configuration errors, being subject to one or more lists of configuration errors, or at least one suggestion for adjusting network configuration.

[0005] Furthermore, analyzing data packets may include parsing a network model by multiple analyzers to retrieve network information. In some implementations, operations include obtaining an indication that the network configuration has changed and a second data packet configured for transmission across the network. In these implementations, operations include determining a subset of multiple analyzers based on the changed network configuration. In these implementations, operations include analyzing the second data packet using a subset of multiple data packets based on the network model. In these implementations, operations also include determining a second configuration state of the network based on the analysis of the data packets using a subset of multiple analyzers. In these implementations, operations include reporting the second configuration state to a user.

[0006] In some examples, the operation includes determining a second configuration state of the network based on analysis of a second data packet after a predetermined amount of time has elapsed since the configuration state was reported to the user, and reporting the second configuration state to the user.

[0007] Another aspect of this disclosure provides a system for a scalable, event-driven, automated diagnostic system. The system includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. These operations include acquiring data packets configured to be transmitted over a network from a source address to a destination address, and a list of network changes. These operations include analyzing the data packets using multiple packets based on a network model. The operations also include correlating the network change list with the packet analysis. These operations include determining the network configuration state based on the correlation between the network change list and the packet analysis. These operations include reporting the configuration state to a user.

[0008] This aspect may include one or more of the following optional features. In some implementations, at least one of the multiple analyzers includes a default analyzer that analyzes a default rule set. In other implementations, at least one of the multiple analyzers includes a custom analyzer that analyzes a set of custom rules provided by the user. In these implementations, the custom rule set may include Internet Protocol (IP) range classifications. Furthermore, the default rule set may include firewall configuration rules. In various implementations, the configuration state may include any one of one or more configuration errors, a list of resources affected by one or more configuration errors, or at least one recommendation for adjusting the network configuration.

[0009] Furthermore, analyzing data packets may include parsing a network model by multiple analyzers to retrieve network information. In some implementations, operations include obtaining an indication that the network configuration has changed and a second data packet configured for transmission across the network. In these implementations, operations include determining a subset of multiple analyzers based on the changed network configuration. In these implementations, operations include analyzing the second data packet using a subset of multiple analyzers based on the network model. In these implementations, operations further include determining a second configuration state of the network based on the analysis of the data packet using a subset of multiple analyzers. In these implementations, operations include reporting the second configuration state to a user.

[0010] In some examples, the operation includes determining a second configuration state of the network based on analysis of a second data packet after a predetermined amount of time has elapsed since the configuration state was reported to the user, and reporting the second configuration state to the user.

[0011] Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will become apparent from the description, the drawings, and the claims. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of a scalable, event-driven, automatic diagnostic system for networks.

[0013] Figure 2 yes Figure 1 A schematic diagram of an exemplary component of the system.

[0014] Figure 3 yes Figure 2 A schematic diagram of an exemplary user interface for the system.

[0015] Figure 4 This is a flowchart of an exemplary operational layout for a scalable event-driven automatic diagnostic method.

[0016] Figure 5 This is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0017] The same reference numerals in the various figures indicate the same elements. Detailed Implementation

[0018] Updating network configurations in cloud computing projects can be challenging because even minor errors can lead to network outages. For example, when updating a network firewall, an administrator might inadvertently add a firewall to a default service required for the network to function properly. Manually checking for such errors while updating network configurations can be inefficient and inaccurate. Even if changes don't immediately cause network disruptions, configuration changes may not follow recommended guidelines, leading to problems later. For instance, opening firewall rules that allow untrusted external traffic can degrade the performance of one or more services or compromise security.

[0019] This document describes an implementation of a system that monitors cloud computing project configurations, triggers configuration-based verification based on real-time events (i.e., changes to network settings), identifies errors / failures, correlates failures with changes to identify root causes, and / or provides accurate recommendations to resolve issues. The system is scalable and self-service, covers all network characteristics, helps users avoid common configuration failures or rollbacks, and recommends best practices for improved security and performance.

[0020] Now for reference Figure 1 The scalable event-driven automated diagnostic system 100 includes a user device 16 with a user interface 300. This user device 16 can correspond to any computing device, such as a desktop workstation, laptop workstation, or mobile device (i.e., a smartphone). The user device 16 includes computing resources 17 (e.g., data processing hardware) and / or storage resources 18 (e.g., memory hardware). The user device 16 can be configured to make changes to a network 175. For example, the user device 16 can be configured to have administrative access to a cloud-based computing network 175, where a user 12 can change one or more network configuration settings. Specifically, the user 12 can change any applicable network parameters or settings of the network 175, such as firewall configuration, IP address, hostname, router address, etc.

[0021] In some implementations, user equipment 16 communicates with remote system 150 (also referred to herein as a cloud computing environment) via communication network 140. Remote system 150 may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic resources 152, including computing resources 154 (e.g., data processing hardware) and / or storage resources 156 (e.g., memory hardware). Data storage 158 (i.e., a remote storage device) may overlay storage resources 146 to allow one or more user equipment 16 or computing resources 154 to scalably utilize storage resources 146. In some implementations, network 175 is a cloud computing network within or part of remote system 150. Network 140 may be the same as or different from network 175. In some examples, remote system 150 executes diagnostic module 200 to provide scalable, event-driven automated diagnostics of any configuration changes 112 made to network 175. In other examples, the diagnostic module is executed at least partially on user device 16 (e.g., on data processing hardware 17).

[0022] In some implementations, user 12 of user equipment 16 inputs one or more configuration changes 112 to network 175. For example, user 12 changes firewall settings / rules of network 175. Diagnostic module 200 can obtain a list of changes 112 to network 175 in real time (i.e., when user 12 changes one or more parameters or settings of network 175 or shortly thereafter). Diagnostic module 200 includes a scheduler 210 and a configuration checker 250. Scheduler 210 is responsible for obtaining updates to network 175 (e.g., change list 112) and pushing messages to configuration checker 250. Scheduler 210 can push messages upon receiving updates or can send batch messages periodically. Thus, changes to network 175 can be tested in real time or at specific intervals (e.g., hourly). In response to obtaining change list 112, scheduler 210 can identify one or more analyzers 255 affected by change list 112. Scheduler 210 transmits activation instruction 215 to configuration checker 250, which instructs the analyzer 255 to be activated in response to change list 112. Each analyzer may correspond to a specific configuration verification rule that can generate insights into different causes and severities of failure. For example, a specific analyzer 255 may be for IP address assignments in network 175 and is activated only when IP address assignments are changed. Therefore, analyzer 255 enables diagnostic module 200 to test only the configurations that have been changed in network 175 (as opposed to testing the entire network 175 in response to each change), allowing for more efficient, dynamic, and scalable testing. In some examples, configuration checker 250 activates the appropriate analyzer 255 (i.e., the analyzer 255 indicated by instruction 215) to analyze each change 112 in change list 112 using network model 265 (representing network 175) to determine whether change 112 caused any errors and / or failures. In some implementations, configuration checker 250 uses analyzer 255 and network model 265 to test sample packets 114 based on changes made to network 175 in change list 112. Based on the output of configuration checker 250, diagnostic module 200 can send configuration status 301 to user device 16 for display at user interface 300.

[0023] In some implementations, scheduler 210 acquires packet 114 (or an indication or representation of packet 114) for transmission over network 175 from a source address to a destination address. Packet 114 may be a test message used to test updates to network 175. In other implementations, packet 114 may be a real message (or an indication or representation of a message) to be sent over network 175, provided by user 12 and / or intercepted from network 175. In response to acquiring packet 114, scheduler 210 determines one or more analyzers 255 affected by packet 114. Scheduler 210 may send activation indication 215, which indicates the analyzer 255 activated in response to packet 114. In some examples, configuration checker 250 activates the appropriate analyzer 255 to analyze packet 114 to determine whether transmission of packet 114 over network 175 will result in any errors and / or failures and / or problems. Configuration checker 250 uses network model 265 to simulate / reconstruct network 175. Based on the output of configuration checker 250, diagnostic module 200 sends configuration status 301 to user equipment 16 for display at user interface 300. In some implementations, configuration status 301 is based on the correlation between the change list 112 of network 175 and the analysis of data packets 114 using analyzer 255 and network model 265, as discussed in more detail below. Figure 2 ).

[0024] Configuration status 301 can indicate any applicable information regarding the current or future operability of network 175. Furthermore, configuration status 301 can be presented as a graph, text document, spreadsheet, or any other suitable format. In some implementations, configuration status 301 indicates the current state of network 175 based on one or more recent configuration changes to network 175. For example, scheduler 210 can obtain change list 112 in real time (i.e., as soon as changes are entered by user 12). Diagnostic module 200 can determine the updated configuration status 301 in response to the obtained change list 112. Alternatively, scheduler 210 periodically obtains change list 112 and / or data packets 114 at predetermined intervals and updates the configuration status accordingly.

[0025] Figure 1The system described is presented for illustrative purposes only and is not intended to be limiting. For example, while only a single example of each component is shown, any number of components 16, 175, 200, and 150 can be communicatively coupled to system 100. Furthermore, although some components are shown as residing in cloud computing environment 150, in some embodiments, these components may be hosted on user device 16. Alternatively, although some components are shown as hosted on user device 16, in some embodiments, these components are hosted in cloud computing environment 150. Additionally, in various embodiments, some or all of components 200, 210, and / or 250 are hosted on user device 16, remotely (e.g., in cloud computing environment 150), or in some combination thereof.

[0026] Figure 2 include Figure 1 The diagnostic module 200. As described above, the diagnostic module 200 may implement a scheduler 210 to obtain input, such as a change list 112 for network 175 and / or data packets 114 (or indications of data packets 114) transmitted on network 175. In some embodiments, the scheduler 210 is a separate logic residing outside the diagnostic module 200. In some examples, the scheduler 210 triggers a desired service (i.e., analyzer 255) based on monitoring configuration and event updates (i.e., the obtained inputs 112, 114). In some embodiments, the scheduler 210 is a general-purpose module for multiple networks 175. The scheduler 210 may periodically send indications 215 based on time intervals and / or in response to the obtained inputs 112, 114. For example, the scheduler 210 obtains each change to network 175 in the change list 112 and pushes the indication 215 as a batch message, triggering a test of network 175 and indicating that analyzer 255 is activated during the test. In another example, scheduler 210 sends indication 215 in response to each change made to network 175. Furthermore, each indication 215 may include an indication of packet 114 (test packet 114 or an actual packet being transmitted on network 175). 114) is used to test network 175. Scheduler 210 can obtain inputs 112, 114 from a data source outside of diagnostic module 200 and can implement streaming services to handle real-time events. In other embodiments, scheduler 210 processes snapshots of network 175 periodically (e.g., every hour, every six hours, every day, etc.) for coordination purposes.

[0027] Optionally, scheduler 210 determines one or more default analyzers 255, 255a and / or one or more custom analyzers 255, 255b corresponding to change list 112 and / or packet 114. Default analyzer 255a typically requires no user input / configuration. In other words, default analyzer 255a can be an "out-of-the-box" rule. For example, a common network configuration includes one or more firewall configurations, IP ranges, etc. Default rule 255a is common across these common networks 175 and is generally applicable to different clients and networks. Default analyzer 255a may include analyzers 255 belonging to categories such as service, connectivity, dependency, security, optimization, etc. Custom analyzer 255b is configured by user 12 based on specific network 175 settings. For example, a user network may include custom Internet Protocol (IP) range classifications, where user 12 can configure source IP ranges such that destination IP ranges are reachable, isolated, or reachable via a specific path. Exemplary IP ranges are based on custom values ​​and are unique to user network 175. Therefore, a custom analyzer 255b may be necessary when testing changes to the exemplary network 175 due to a custom IP range. In some implementations, the scheduler 210 stores a list of rule-based triggers 214 that map each analyzer 255 to relevant resources on network 175. For example, the custom analyzer 255b may be configured for a specific organization. When the scheduler 210 receives a packet 114 corresponding to a specific organization, the scheduler 210 can use the rule-based triggers 214 to find the appropriate custom analyzer 255b. The scheduler 210 may send an activation indication 215 indicating which analyzers 255 are suitable for analyzing the obtained change list 112 and / or packet 114.

[0028] In some implementations, scheduler 210 analyzes the received inputs 112, 114 to determine whether configuration checker 250 should perform (i.e., whether analysis using network model 265 should be performed). For example, scheduler 210 receives a first data packet 114 and sends an activation instruction 215 to configuration checker 250 to analyze data packet 114 to determine configuration state 301. If scheduler 210 receives a second data packet 114 that is substantially similar to the first data packet 114, the scheduler determines that configuration state 301 does not need to be updated. Alternatively, if the second data packet 114 is sufficiently different from the first data packet 114, scheduler 210 determines an appropriate analyzer 255 (e.g., using rule-based trigger 214) and sends the activation instruction 215 to configuration checker 250 to update configuration state 301 based on the second data packet 114 (or determine a new configuration state 301). For example, scheduler 210 sends a first activation instruction 215 in response to a first change list 112, instructing multiple configuration checkers 250 to use multiple analyzers 255 and network model 265 to analyze a first data packet 114 transmitted on network 175 to determine configuration state 301. Scheduler 210 then obtains a new change list 112. In response to the new change list 112, scheduler 210 then sends a second activation instruction 215 instructing a second set of multiple analyzers 255. Here, if the new change list 112 includes a portion of the original change list 112, the second set of multiple analyzers 255 may be a subset of the first set of multiple analyzers 255. Configuration checkers 250 then use the second set of multiple analyzers 255 and network model 265 to analyze a second data packet 114 transmitted on network 175 to determine a second configuration state 301. In another example, scheduler 210 sends activation instruction 215 after a predetermined amount of time has elapsed since configuration state 301 was reported.

[0029] Configuration checker 250 can perform diagnostics on network 175 using analyzer 255 and network model 265 based on the obtained inputs 112, 114. In some implementations, configuration checker 250 is communicatively coupled to model data storage 260 to retrieve network model 265 representing network 175 during testing. Configuration checker 250 implements / executes analyzer 255 based on activation instruction 215, thereby efficiently performing diagnostic analysis of changes to network 175 (i.e., triggering only the relevant analyzer 255). For example, configuration checker 250 resolves network model 265 based on the activated analyzer 255, thereby allowing configuration checker 250 to test only the configuration of network 175 that has been changed. Therefore, when analyzing how packet 114 is transmitted on network 175 (using network model 265), configuration checker 250 tests only the changed portions (based on change list 112) rather than the entire network 175. Inspector 250 can manage analyzer 255 during each configuration check (i.e., network diagnostics) and merge and adjust analyzer 255 as needed based on changes to network 175 and / or one or more network models 265.

[0030] Each analyzer 255 can run specific configuration verification rules that can generate insights with varying causes and severities of failures. For example, an Internet Protocol (IP) utilization analyzer can report low-severity insights such as unused external IP addresses or medium-severity insights such as a subnet having more than 80% of its IP address allocation. Analyzers 255 can be categorized as network core or services. For instance, a network core analyzer 255 includes basic Virtual Private Cloud (VPC) setups and connectivity-related configurations such as IP addresses, routing, firewalls, VPC peering, shared VPCs, hybrid connectivity, etc. As another example, a service analyzer 255 includes network services or managed services. For service analyzers 255 focused on verifying connectivity to / from services to other network endpoints, a connectivity correlator 270 can provide packet-based connectivity simulation to identify configuration problems hindering reachability.

[0031] Configuration checker 250 can generate results 225 based on the change list 112 used to analyze network 175 and / or the output of each active analyzer 255 for each data packet 114 sent on network 175. Results 225 may include a highly detailed description of the number of resources in the analyzed network 175 and a summary of the level of the resources involved in the analysis. Results 225 may also include a list of results, including severity type (e.g., low, warning, error, etc.), configuration errors, detailed information (e.g., a list of affected resources, specific changes made to correct the errors), and so on.

[0032] In some implementations, correlator 270 uses fault correlation module 272 and data from insight storage 280 to process result 225. Correlator 270 can be used to provide packet-based (i.e., packet 114) connectivity simulation to identify configuration problems hindering reachability. Fault correlation module 272 can provide root cause analysis, specifically, correlating changes that may be the cause of newly discovered problems / faults in network 175 based on changes from change list 112. Specifically, correlator 270 can correlate result 225 (which indicates analysis of packet 114 transmitted on network 175 using analyzer 255 based on change list 112 and using network model 265 corresponding to network 175) with one or more changes in change list 112. A simple example is that if only a single analyzer 255 is activated to test a single change to network 175 and result 225 indicates a network fault, correlator 270 can associate that fault with the configuration corresponding to the single analyzer 255. Therefore, correlator 270 correlates result 225 with change list 112 to identify changes causing problems on network 175. Scheduler 210 may also send change list 112 when scheduler 210 triggers / instructs analyzer 255. The correlator correlates change list 112 with newly discovered insights (i.e., result 225). Each part of result 225 may include metadata describing the type of failure and what resources are targeted and / or responsible. Therefore, correlator 270 can use the metadata to compare result 225 with change list 112 to identify one or more changes causing failures in network 175. In some examples, correlator 270 provides recommendations to fix, correct, or otherwise mitigate problems on network 175 based on historical data (e.g., by suggesting settings 175 used in previous iterations when no problems existed on the network). Correlator 270 may generate configuration state 301 based on the correlation between result 225 and change list 112.

[0033] In some implementations, the insight store 280 is a persistent database that stores the current and historical results (e.g., result 225) of the analyzer 255 and correlator 270 to enable user queries of historical data. The insight store 280 can support insight state transitions initiated by user 12 and / or automatically detected by system 100. In this way, if a problem is resolved, correlator 270 can be able to use historical data to determine one or more changes that led to the resolution of network 175.

[0034] Figure 3An example user interface 300 is included, displaying configuration status 301. Configuration status 301 may include a list of reports. In some examples, each report includes a specific fault or discovery corresponding to network 175. For example, configuration status 301 indicates a list of configuration errors 304 (i.e., incorrect and / or potentially causing network 175 to malfunction or operate inefficiently or ineffectively) and resources 302 affected by one or more configuration errors 304. In some implementations, configuration status 301 includes one or more recommendations for adjusting the configuration of network 175. For example, configuration status 301 provides alternative configurations (not shown) and / or a series of inputs that can remedy configuration errors 304. In another example, configuration status 301 indicates that a firewall should be enabled or that one or more sources should be allowed through the firewall. Figure 3 The example configuration state 301 is not intended to be restrictive, and any indication of the operability of network 175 may be included as part of configuration state 301. Furthermore, configuration state 301 can be updated upon receiving new input. For example, if one or more changes are made to network 175, diagnostic module 200 obtains change list 112 and updates (or determines new) configuration state 301 accordingly.

[0035] Figure 4 This is a flowchart illustrating an exemplary operational arrangement of method 400 of a scalable event-driven automated diagnostic system. Method 400 can be... Figure 1 Scalable event-driven automated diagnostic system 100 and / or Figure 5 The computing device 500 uses various components to perform the operation. For example, Figure 1 The data processing hardware 154 of the remote system 150 can execute instructions stored on the memory hardware 156 to cause the data processing hardware 154 to perform the operations of method 400. In operation 402, method 400 includes acquiring a data packet 114 configured to be transmitted from a source address to a destination address via network 175. In operation 404, method 400 includes obtaining a change list 112 for network 175. In operation 406, method 400 includes analyzing the data packet 114 using multiple analyzers 255 based on network model 265. In operation 408, method 400 includes modifying the change list for network 175. 112 is associated with the analysis of packet 114. In operation 410, method 400 includes a change list based on network 175. The correlation between the analysis of packet 112 and packet 114 determines the configuration state 301 of network 175. In operation 412, method 400 includes reporting the configuration state 301 to user 12.

[0036] Figure 5This is a schematic diagram of an example computing device 500 that can be used to implement the systems and methods described in this document. The computing device 500 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed in this document.

[0037] The computing device 500 includes: a processor 510 (e.g., data processing hardware), a memory 520, a storage device 530, a high-speed interface / controller 540 connected to the memory 520 and a high-speed expansion port 550, and a low-speed interface / controller 560 connected to a low-speed bus 570 and the storage device 530. Each component 510, 520, 530, 540, 550, and 560 is interconnected using different buses, and each component can be mounted on a common motherboard or otherwise installed as needed. The processor 510 can process instructions that execute within the computing device 500, including instructions stored in the memory 520 or the storage device 530 to display graphical information of a graphical user interface (GUI) on an external input / output device, such as a display 580 coupled to the high-speed interface 540. In other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple types of memory, if desired. Similarly, multiple computing devices 500 can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0038] Memory 520 stores information non-temporarily within computing device 500. Memory 520 may be a computer-readable medium, volatile memory cells(s), or non-volatile memory cells(s). Non-volatile memory 520 may be a physical device for storing programs (e.g., instruction sequences) or data (program state information) used by computing device 500 on a temporary or permanent basis. Examples of non-volatile memory include, but are not limited to: flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used for firmware such as boot programs). Examples of volatile memory include, but are not limited to: random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and optical discs or magnetic tapes.

[0039] Storage device 530 provides massive storage for computing device 500. In some embodiments, storage device 530 is a computer-readable medium. In various embodiments, storage device 530 may be a floppy disk device, hard disk device, optical disk device, magnetic tape device, flash memory or other similar solid-state storage device, or device array, including devices in a storage area network or other configuration. In additional embodiments, the computer program product is tangibly embodied as an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-readable or machine-readable medium, such as memory 520, storage device 530, or memory on processor 510.

[0040] High-speed controller 540 manages bandwidth-intensive operations of computing device 500, while low-speed controller 560 manages lower bandwidth-intensive operations. This functional allocation is merely exemplary. In some embodiments, high-speed controller 540 is coupled to memory 520, display 580 (e.g., via a graphics processor or accelerator) is coupled to high-speed expansion port 550, which can accept various expansion cards (not shown). In some embodiments, low-speed controller 560 is coupled to storage device 530 and low-speed expansion port 590. Low-speed expansion port 590 may include various communication ports (e.g., USB, Bluetooth, Ethernet, and wireless Ethernet) and may be coupled to one or more input / output devices, such as keyboards, pointing devices, scanners, or network devices such as switches or routers, for example, via a network adapter.

[0041] As shown in the figure, the computing device 500 can be implemented in various forms. For example, it can be implemented as a standard server 500a, or multiple times in a group of such servers 500a, or as a laptop computer 500b, or as part of a rack-mounted server system 500c.

[0042] Various implementations of the systems and techniques described herein can be implemented in digital electronic circuit systems and / or optical circuit systems, integrated circuit systems, application-specific integrated circuits (ASICs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be dedicated or general-purpose, and can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0043] A software application (i.e., a software resource) can refer to computer software that instructs a computing device to perform a task. In some examples, a software application may be referred to as an "application," "program," or simply a "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0044] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer-readable medium, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0045] The processes and logic flows described herein can be executed by one or more programmable processors, which execute one or more computer programs to perform functions by manipulating input data and generating output. Processes and logic flows can also be executed by special-purpose logic circuits such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). Processors suitable for executing computer programs include, for example, general-purpose microprocessors, special-purpose microprocessors, and any type of digital computer processor. Generally, the processor receives instructions and data from read-only memory or random access memory, or both. Essential components of a computer are: a processor for executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, or the computer may be operatively coupled to receive data from or transfer data to or both of these mass storage devices, such as magnetic disks, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, including, for example, semiconductor storage devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into a dedicated logic circuit system.

[0046] To provide interaction with a user, one or more aspects of this disclosure can be implemented on a computer having: a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, or a touchscreen, and optionally including a keyboard and pointing device (e.g., a mouse or trackball), through which the user provides input to the computer. Other types of devices can be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound input, voice input, or tactile input. Additionally, the computer can interact by sending documents to and receiving documents from the device used by the user, for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0047] Several embodiments have been described. However, it is understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are within the scope of the appended claims.

Claims

1. A computer-implemented method (400) for scalable event-driven automatic diagnostics, characterized in that, When executed by the data processing hardware (154), the data processing hardware (154) performs operations, the operations including: Obtain the data packet (114) configured to be transmitted over the network (175) from the source address to the destination address; Obtain a change list (112) for the network (175), the change list (112) including one or more configuration changes to the network (175); Based on the change list (112), a plurality of analyzers (255) for analyzing the data packet (114) are selected from the analyzer set, the analyzer set including one or more analyzers not belonging to the selected plurality of analyzers (255), wherein each of the selected plurality of analyzers (255) corresponds to: The corresponding configuration changes in one or more configuration changes in the change list (112); and Specific configuration verification rules are used to determine the cause and severity of the failure, and these specific configuration verification rules are different from the specific configuration verification rules of the other analyzers (255) among the selected plurality of analyzers (255); For each of the selected plurality of analyzers (255), the packet (114) is analyzed using the corresponding analyzer (255) based on the network model (265) by applying only the specific configuration verification rule corresponding to the corresponding analyzer (255) to the analysis of the packet (114); The change list (112) of the network (175) is associated with the analysis of the data packets (114); The configuration state (301) of the network (175) is determined based on the correlation between the change list (112) of the network (175) and the analysis of the data packets (114); and Report the configuration status (301) to the user (12).

2. The method (400) according to claim 1, characterized in that, At least one of the plurality of analyzers (255) includes a default analyzer (255a) that analyzes the default rule set.

3. The method (400) according to claim 2, characterized in that, The default rule set includes firewall configuration rules.

4. The method (400) according to claim 3, characterized in that, At least one of the plurality of analyzers (255) includes a custom analyzer (255b) that analyzes a custom rule set provided by the user (12).

5. The method (400) according to claim 4, characterized in that, The custom rule set includes Internet Protocol (IP) range classifications.

6. The method (400) according to claim 5, characterized in that, The configuration status (301) includes one or more configuration errors (304).

7. The method (400) according to claim 6, characterized in that, The configuration status (301) includes a list of resources (302) affected by the one or more configuration errors (304).

8. The method (400) according to claim 7, characterized in that, Analyzing the data packet (114) includes parsing the network model (265) by the selected plurality of analyzers (255) to retrieve network (175) information.

9. The method (400) according to claim 8, characterized in that, The operation also includes: Obtain an indication that the configuration of the network (175) has been changed; Obtain a second data packet (114) configured to be transmitted through the network (175); Obtain a new list of changes to the network (175); In response to the new change list, a second plurality of analyzers (255) is determined, wherein when the new change list includes a portion of the change list (112), the second plurality of analyzers (255) is a subset of the selected plurality of analyzers (255); Based on the network model (265), the second plurality of analyzers (255) are used to analyze the second data packet (114); The second configuration state (301) of the network (175) is determined based on the analysis of the second data packet (114) by the second plurality of analyzers (255); and Report the second configuration status (301) to the user (12).

10. The method (400) according to claim 9, characterized in that, The operation further includes, after a predetermined amount of time has elapsed since the configuration status (301) was reported to the user (12): The second configuration state (301) of the network (175) is determined based on the analysis of the second data packet (114); and Report the second configuration status (301) to the user (12).

11. The method (400) according to claim 10, characterized in that, The configuration state (301) includes at least one suggestion for adjusting the configuration of the network (175).

12. A scalable event-driven automatic diagnostic system (100), characterized in that, include: Data processing hardware (154); and A memory hardware (156) communicating with the data processing hardware (154), the memory hardware (156) storing instructions that, when executed on the data processing hardware (154), cause the data processing hardware (154) to perform operations, the operations including: Obtain the data packet (114) configured to be transmitted over the network (175) from the source address to the destination address; Obtain a change list (112) for the network (175), the change list (112) including one or more configuration changes to the network (175); Based on the change list (112), a plurality of analyzers (255) for analyzing the data packet (114) are selected from the analyzer set, the analyzer set including one or more analyzers not belonging to the selected plurality of analyzers (255), wherein each of the selected plurality of analyzers (255) corresponds to: The corresponding configuration changes in one or more configuration changes in the change list (112); and Specific configuration verification rules are used to determine the cause and severity of the failure, and these specific configuration verification rules are different from the specific configuration verification rules of the other analyzers (255) among the selected plurality of analyzers (255); For each of the selected plurality of analyzers (255), the packet (114) is analyzed using the corresponding analyzer (255) based on the network model (265) by applying only the specific configuration verification rule corresponding to the corresponding analyzer (255) to the analysis of the packet (114); The change list (112) of the network (175) is associated with the analysis of the data packets (114); The configuration state (301) of the network (175) is determined based on the correlation between the change list (112) of the network (175) and the analysis of the data packets (114); and Report the configuration status (301) to the user (12).

13. The system (100) according to claim 12, characterized in that, At least one of the plurality of analyzers (255) includes a default analyzer (255a) that analyzes the default rule set.

14. The system (100) according to claim 13, characterized in that, The default rule set includes firewall configuration rules.

15. The system (100) according to claim 14, characterized in that, At least one of the plurality of analyzers (255) includes a custom analyzer (255b) that analyzes a custom rule set provided by the user (12).

16. The system (100) according to claim 15, characterized in that, The custom rule set includes Internet Protocol (IP) range classifications.

17. The system (100) according to claim 16, characterized in that, The configuration status (301) includes one or more configuration errors (304).

18. The system (100) according to claim 17, characterized in that, The configuration status (301) includes a list of resources (302) affected by the one or more configuration errors (304).

19. The system (100) according to claim 18, characterized in that, Analyzing the data packet (114) includes parsing the network model (265) by the selected plurality of analyzers (255) to retrieve network (175) information.

20. The system (100) according to claim 19, characterized in that, The operation also includes: Obtain an indication that the configuration of the network (175) has been changed; Obtain a second data packet (114) configured to be transmitted through the network (175); Obtain a new list of changes to the network (175); In response to the new change list, a second plurality of analyzers (255) is determined, wherein when the new change list includes a portion of the change list (112), the second plurality of analyzers (255) is a subset of the selected plurality of analyzers (255); Based on the network model (265), the second plurality of analyzers (255) are used to analyze the second data packet (114); The second configuration state (301) of the network (175) is determined based on the analysis of the second data packet (114) by the second plurality of analyzers (255); and Report the second configuration status (301) to the user (12).

21. The system (100) according to claim 20, characterized in that, The operation further includes, after a predetermined amount of time has elapsed since the configuration status (301) was reported to the user (12): The second configuration state (301) of the network (175) is determined based on the analysis of the second data packet (114); and Report the second configuration status (301) to the user (12).

22. The system (100) according to claim 21, characterized in that, The configuration state (301) includes at least one suggestion for adjusting the configuration of the network (175).

Images