Command validation for quick error detection

Abstract

To provide a system for testing a discovery order to a set of a predetermined network addresses, a computer execution method, and a manufacturing component.SOLUTION: A method by a discovery validation application, includes steps of: reading a list of a discovery command related to a list of each network address and a list of each network address from a permanent storage; transmitting a discovery command to each network address in the list of network addresses related to them via one or a plurality of proxy servers in each discovery command in the list of the discovery commands; receiving a discovery result indicating any one of a success or a failure of the discovery command corresponded to each of the transmitted discovery commands via the one or plurality of proxy servers; and writing the discovery result into the permanent storage.SELECTED DRAWING: Figure 10

Description

[Background technology]

[0001] Discovery is an automated or semi-automated process that can determine and characterize computing devices and the software applications installed and / or running on those computing devices. Representations of such devices and software can be stored in a database as configuration items. Relationships between configuration items can also be determined and stored in a database. Discovery is typically applied to managed networks or public cloud services to not only provide a list of these configuration items and relationships, but also serve as a foundation to enable higher-level applications to manage the information technology (IT) infrastructure.

[0002] Nevertheless, in certain environments, it can be difficult to configure discovery to work correctly. In particular, discovery patterns (script-like lists of commands that provide a step-by-step process for discovering a particular device or system) can fail due to misconfiguration. However, these failures typically go unnoticed for hours or days, and thus the device or system for which discovery was attempted remains unrepresented in the database. Summary of the Invention

[0003] Embodiments herein address these and possibly other technical problems by providing a mechanism by which discovery procedures can be tested for a given set of network addresses. In some examples, such a mechanism can take the form of a software-based validation tool (also called a "discovery validation application") that receives as input a list of discovery commands and a set of network addresses. The validation tool then uses a discovery infrastructure to test the discovery commands with the network addresses. The validation tool can provide an indication of success or failure of these command / address pairs, for example, in a database table, in a file, or through a graphical user interface.

[0004] Thus, a user can test a discovery pattern against a set of network addresses before committing to a discovery procedure. Output from the validation tool may indicate any cause of failure, such as an unsupported command, an unreachable network address, authentication failure, or authorization failure. The user receives a prompt indication of any failure and can take steps to correct or mitigate the failure. Once a discovery pattern can be executed by the validation tool without failure, the pattern can be added to a periodic automated discovery procedure with a high degree of confidence of successful completion.

[0005] Thus, the first exemplary embodiment may include a persistent storage including a list of discovery commands each associated with a list of network addresses. The first exemplary embodiment may also include one or more processors and a discovery verification application, which, when executed by the one or more processors, is configured to read the list of discovery commands and the list of network addresses from the persistent storage, and for each discovery command in the list of discovery commands, send a discovery command to each network address in the list of associated network addresses respectively via one or more proxy servers deployed outside the system, receive discovery results respectively corresponding to each of the sent discovery commands via the one or more proxy servers, the discovery results indicating either a success or failure of the discovery command, and write the discovery results to the persistent storage.

[0006] The second exemplary embodiment may include reading, by the discovery verification application, from the persistent storage, a list of discovery commands, each associated with a list of network addresses, and a list of network addresses. The second exemplary embodiment may also include, for each discovery command in the list of discovery commands, sending, by the discovery verification application, via one or more proxy servers, a discovery command to each network address in the list of network addresses, each associated with. The second exemplary embodiment may also include receiving, by the discovery verification application, via one or more proxy servers, a discovery result, each corresponding to each of the sent discovery commands, where the discovery result indicates either a success or failure of the discovery command. The second exemplary embodiment may also include writing, by the discovery verification application, the discovery result to the persistent storage.

[0007] In a third exemplary embodiment, an article of manufacture may include a non-transitory computer readable medium having program instructions stored thereon that, when executed by a computing system, cause the computing system to perform operations in accordance with the first and / or second exemplary embodiments.

[0008] In a fourth exemplary embodiment, a computing system may include at least one processor, as well as a memory and program instructions that are stored in the memory and that, when executed by the at least one processor, cause the computing system to perform operations according to the first and / or second exemplary embodiments.

[0009] In the fifth exemplary embodiment, the system may include various means for performing each of the operations of the first and / or second exemplary embodiments.

[0010] These and other embodiments, aspects, advantages, and alternatives will become apparent to those skilled in the art upon reading the following detailed description, with reference to the accompanying drawings, as appropriate. Moreover, this summary and other descriptions and drawings provided herein are intended to illustrate embodiments by way of example only, and thus many variations are possible. For example, structural elements and process steps can be rearranged, combined, distributed, eliminated, or otherwise modified while remaining within the scope of the claimed embodiments. [Brief description of the drawings]

[0011] [Figure 1] 1 is a schematic diagram of a computing device in accordance with an exemplary embodiment. [Diagram 2] 1 is a schematic diagram of a server device cluster according to an example embodiment. [Diagram 3] FIG. 1 illustrates a remote network management architecture, according to an example embodiment. [Figure 4] FIG. 1 illustrates a communication environment including a remote network management architecture, according to an example embodiment. [Diagram 5] FIG. 1 illustrates another communication environment including a remote network management architecture, according to an exemplary embodiment. [Figure 6A] FIG. 2 illustrates a virtual machine cluster, according to an example embodiment. [Figure 6B] FIG. 6B illustrates a simple discovery pattern for the virtual machine cluster of FIG. 6A, according to an example embodiment. [Figure 7] FIG. 1 illustrates a communication environment including a remote network management architecture that hosts a validation tool, according to an exemplary embodiment. [Figure 8] FIG. 1 illustrates a validation tool interacting with a database table in accordance with an exemplary embodiment. [Figure 9] FIG. 2 illustrates operation of a validation tool in accordance with an exemplary embodiment. [Figure 10] 1 is a flowchart according to an example embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Exemplary methods, devices, and systems are described herein. It should be understood that, as used herein, the words "example" and "exemplary" are used to mean "serving as an example, instance, or illustration." Any embodiment or feature described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or features, unless expressly stated. Accordingly, other embodiments may be utilized, and other changes may be made, without departing from the scope of the subject matter presented herein.

[0013] Accordingly, the exemplary embodiments described herein are not meant to be limiting. It will be readily understood that the aspects of the present disclosure as generally described herein and illustrated in the Figures can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of functionality into "client" and "server" components can be accomplished in a number of ways.

[0014] Moreover, unless the context indicates otherwise, features shown in each figure can be used in combination with each other. Thus, the drawings should be viewed generally as component aspects of one or more overall embodiments, with the understanding that not all illustrated features are required for each embodiment.

[0015] Moreover, any recitation of elements, blocks, or steps in the specification or claims is for the purpose of clarity, and thus such recitation should not be construed as requiring or implying that those elements, blocks, or steps follow a particular arrangement or be performed in a particular order.

[0016] (I. Introduction) Large enterprises are complex entities with many interrelated activities. Some of these activities can be found throughout the enterprise, such as human resources (HR), supply chain, information technology (IT), finance, etc. However, each enterprise also has unique activities that provide critical functions and / or create competitive advantage.

[0017] To support commonly performed operations, enterprises typically use off-the-shelf software applications, such as customer relationship management (CRM) and human capital management (HCM) packages. However, custom software applications may be needed to meet unique requirements. Large enterprises often have dozens or even hundreds of such custom software applications. Nevertheless, advantages provided by embodiments herein are not limited to large enterprises and may be applicable to enterprises of any size or any other type of organization.

[0018] Many such software applications are developed by individual departments within an enterprise. These range from simple spreadsheets to custom-built software tools and databases. However, the proliferation of siloed, custom software applications has many drawbacks. It negatively impacts an enterprise's ability to perform its operations, grow, innovate, and meet regulatory requirements. Without a single system to centralize subsystems and data, enterprises can find it difficult to consolidate, streamline, and enhance their operations.

[0019] To efficiently create custom applications, enterprises benefit from remotely hosted application platforms that eliminate unnecessary development complexity. The goal of such platforms is to reduce time-consuming, repetitive application development tasks, allowing software engineers and other roles to focus on developing unique, high-value functionality.

[0020] To achieve this goal, the concept of aPaaS (Application Platform as a Service) has been introduced to intelligently automate workflows across an enterprise. The aPaaS system is hosted remotely from the enterprise but can access data, applications, and services within the enterprise through a secure connection. Such an aPaaS system may have many advantageous features and characteristics. These advantages and characteristics may enable improving enterprise operations and workflows related to IT, HR, CRM, customer service, application development, and security. Nevertheless, the embodiments herein are not limited to enterprise applications or environments and may be more broadly applicable.

[0021] aPaaS systems may support the development and execution of model-view-controller (MVC) applications. MVC applications divide their functionality into three interconnected parts (model, view, and controller) to separate the representation of information from the manner in which the information is presented to the user, thereby enabling efficient code reuse and parallel development. These applications may be web-based and provide create, read, update, and delete (CRUD) functionality. This allows new applications to be built on a common application infrastructure. In some cases, applications with a different structure than MVC may be adopted, such as applications that use unidirectional data flow.

[0022] An aPaaS system may support standardized application components, such as a standardized set of widgets for GUI (graphical user interface) development. In this way, applications built using an aPaaS system have a common look and feel. Other software components and modules may be standardized as well. In some cases, this look and feel can be branded or skinned with a company's custom logo and / or color scheme.

[0023] aPaaS systems may support the ability to configure application behavior using metadata, allowing application behavior to be rapidly adapted to specific needs. Such an approach reduces development time and increases flexibility. Additionally, aPaaS systems may support GUI tools that make it easier to create and manage metadata, thus reducing errors in the metadata.

[0024] An aPaaS system may support well-defined interfaces between applications so that software developers can avoid undesirable dependencies between applications. Thus, an aPaaS system may implement a service layer in which persistent state information and other data are stored.

[0025] An aPaaS system may support a rich set of integration capabilities to allow applications on the system to interact with legacy and third-party applications. For example, an aPaaS system may support a custom employee onboarding system that integrates with legacy HR, IT, and accounting systems.

[0026] aPaaS systems may support enterprise-grade security. Additionally, because aPaaS systems may be hosted remotely, they should utilize security procedures when interacting with systems within the enterprise or with third-party networks and services hosted outside the enterprise. For example, aPaaS systems may be configured to share data between the enterprise and other parties to detect and identify common security threats.

[0027] There may be other features, functions, and advantages of an aPaaS system. This description is for illustrative purposes and is not intended to be limiting.

[0028] As an example of an aPaaS development process, a software developer may be tasked with creating a new application using an aPaaS system. First, the developer may define a data model that specifies the types of data the application will use and the relationships between them. Then, through the aPaaS system's GUI, the developer inputs (e.g., uploads) the data model. The aPaaS system automatically creates all of the corresponding database tables, fields, and relationships, which can be accessed through an object-oriented services layer.

[0029] Additionally, the aPaaS system may also build a fully-featured application with a client-side interface and server-side CRUD logic. This generated application may serve as a basis for further development for the user. Advantageously, the developer does not need to spend a great deal of time on the basic application functionality. Furthermore, the application may be web-based, so that it can be accessed from any internet-enabled client device. Alternatively or additionally, it may be possible to access a local copy of the application, for example, when internet service is not available.

[0030] aPaaS systems may also support a rich set of predefined functionality that can be added to applications, including support for search, email, templates, workflow design, reporting, analytics, social media, scripting, mobile-friendly output, and customized GUIs.

[0031] Such an aPaaS system may represent the GUI in a variety of ways. For example, a server device of an aPaaS system may generate a representation of the GUI using a combination of HyperText Markup Language (HTML) and JAVASCRIPT. The JAVASCRIPT may include client-side executable code, server-side executable code, or both. The server device may transmit or otherwise provide this representation to the client device so that the client device may display it on its screen according to a locally defined look and feel. Alternatively, the representation of the GUI may take other forms, such as an intermediate format (e.g., JAVA bytecode) that the client device can use to directly generate graphical output. Other possibilities exist.

[0032] Additionally, user interaction with a GUI element, such as a button, menu, tab, slider, checkbox, toggle, etc., may be referred to as its "selection," "activation," or "actuation." These terms can be used regardless of whether the GUI element is interacted with via a keyboard, a pointing device, a touch screen, or another mechanism.

[0033] The aPaaS architecture is particularly powerful when integrated with an enterprise's network and used to manage such a network. The following embodiments describe architectural and functional aspects of an exemplary aPaaS system, as well as its features and advantages.

[0034] II. Exemplary Computing Devices and Cloud-Based Computing Environments 1 is a simplified block diagram illustrating a computing device 100 and illustrates some of the components that may be included in a computing device configured to operate according to embodiments herein. Computing device 100 may be a client device (e.g., a device that is actively operated by a user), a server device (e.g., a device that provides computational services to client devices), or some other type of computing platform. Some server devices may sometimes act as client devices to perform certain operations, and some client devices may incorporate server functionality.

[0035] In this example, computing device 100 includes a processor 102, memory 104, a network interface 106, and input / output units 108, all of which may be coupled by a system bus 110 or similar mechanism. In some embodiments, computing device 100 may include other components and / or peripheral devices (e.g., removable storage devices, printers, etc.).

[0036] The processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a coprocessor (e.g., a mathematical, graphics, or encryption coprocessor), a digital signal processor (DSP), a network processor, and / or in the form of an integrated circuit or controller that performs processor operations. In some cases, the processor 102 may be one or more single-core processors. In other cases, the processor 102 may be one or more multi-core processors with multiple independent processing units. The processor 102 may also include a register memory for temporarily storing instructions and associated data being executed, as well as a cache memory for temporarily storing recently used instructions and data.

[0037] Memory 104 may be any form of computer usable memory, including, but not limited to, RAM (random access memory), ROM (read only memory), and non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, CDs (compact discs), DVDs (digital video discs), and / or tape storage, etc.). Memory 104 thus represents both primary and long-term storage. Other types of memory may include biological memory.

[0038] The memory 104 may store program instructions and / or data on which the program instructions can operate. By way of example, the memory 104 may store these program instructions on a non-transitory computer-readable medium such that the instructions are executable by the processor 102 to perform any of the methods, processes, or operations disclosed herein or in the accompanying drawings.

[0039] As shown in FIG. 1, memory 104 may include firmware 104A, kernel 104B, and / or applications 104C. Firmware 104A may be program code used to boot or otherwise start part or all of computing device 100. Kernel 104B may be an operating system that includes modules for memory management, process scheduling and management, input / output, and communications. Kernel 104B may also include device drivers that allow the operating system to communicate with hardware modules (e.g., memory units, networking interfaces, ports, and buses) of computing device 100. Applications 104C may be one or more user space software programs, such as a web browser or email client, as well as any software libraries used by these programs. Memory 104 may also store data used by these and other programs and applications.

[0040] The network interface 106 may take the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet, etc.). The network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cable or power line, or over broadband media, such as SONET (Synchronous Optical Networking) or DSL (Digital Subscriber Line) technologies. The network interface 106 may also take the form of one or more wireless interfaces, such as IEEE 802.11 (WiFi), BLUETOOTH, GPS (Global Positioning System), or broadband wireless interfaces. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used over the network interface 106. Furthermore, the network interface 106 may comprise multiple physical interfaces. For example, some embodiments of the computing device 100 may include Ethernet, BLUETOOTH, and WiFi interfaces.

[0041] The input / output unit 108 may facilitate interaction between a user and peripheral devices and the computing device 100. The input / output unit 108 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, etc. Similarly, the input / output unit 108 may also include one or more types of output devices, such as a screen, a monitor, a printer, and / or one or more LEDs (Light Emitting Diodes). Additionally or alternatively, the computing device 100 may also communicate with other devices using, for example, a Universal Serial Bus (USB) or a High Definition Multimedia Interface (HDMI) port interface.

[0042] In some embodiments, one or more computing devices, such as computing device 100, may be deployed to support an aPaaS architecture. The exact physical location, connectivity, and configuration of these computing devices may be unknown and / or unimportant to the client devices. Thus, the computing devices may be referred to as "cloud-based" devices that may be housed in various remote data center locations.

[0043] 2 illustrates a cloud-based server cluster 200 according to an example embodiment. In FIG. 2, operations of a computing device (e.g., computing device 100) may be distributed among server devices 202, data storage 204, and routers 206, all of which may be connected by a local cluster network 208. The number of server devices 202, data storage 204, and routers 206 in the server cluster 200 may depend on the computing tasks and / or applications assigned to the server cluster 200.

[0044] For example, server devices 202 may be configured to perform various computing tasks of computing device 100. Thus, computing tasks may be distributed to one or more server devices 202. To the extent that these computing tasks may be performed in parallel, such distribution of tasks may reduce the total time to complete these tasks and return results. For simplicity, both server cluster 200 and individual server devices 202 may be referred to as "server devices." It should be understood that this nomenclature suggests that one or more individual server devices, data storage devices, and cluster routers may be involved in server device operations.

[0045] The data storage 204 may be a data storage array that includes a drive array controller configured to manage read and write access to a group of hard disk drives and / or solid state drives. The drive array controller, alone or in conjunction with the server device 202, may also be configured to manage backup or redundant copies of data stored in the data storage 204 to prevent drive failure or other types of failures that prevent one or more server devices 202 from accessing units of the data storage 204. Other types of memory other than drives may also be used.

[0046] The router 206 may include networking equipment configured to provide internal and external communications for the server cluster 200. For example, the router 206 may include one or more packet switching and / or routing devices (including switches and / or gateways) configured to provide (i) network communications between the server devices 202 and the data storage 204 via a local cluster network 208, and / or (ii) network communications between the server cluster 200 and other devices via a communication link 210 to a network 212.

[0047] Additionally, the configuration of the router 206 may be based at least in part on the data communication requirements of the server devices 202 and data storage 204, the latency and throughput of the local cluster network 208, the latency, throughput, and cost of the communication links 210, and / or other factors that may contribute to the cost, speed, fault tolerance, resilience, efficiency, and / or other design goals of the system architecture.

[0048] As one possible example, data storage 204 may include any type of database, such as a SQL (Structured Query Language) database. Various types of data structures may store information in such a database, including but not limited to tables, arrays, lists, trees, and tuples. Additionally, any database in data storage 204 may be monolithic or distributed across multiple physical devices.

[0049] The server device 202 may be configured to transmit data to and receive data from the data storage 204. This transmission and retrieval may take the form of SQL queries or other types of database queries, and the output of such queries, respectively. Additional text, images, video, and / or audio may also be included. Additionally, the server device 202 may organize the received data into a web page or web application representation. Such a representation may take the form of a markup language, such as HTML, eXtensible Markup Language (XML), or some other standardized or proprietary format. Additionally, the server device 202 may have the capability to execute various types of computerized scripting languages, including, but not limited to, Perl, Python, PHT Hypertext Preprocessor (PHP), Active Server Pages (ASP), JAVASCRIPT, and the like. Computer program code written in these languages ​​may facilitate the provision of web pages to client devices and the client device's interaction with the web pages. Alternatively or additionally, JAVA may be used to facilitate the generation of web pages and / or provide web application functionality.

[0050] III. Exemplary Remote Network Management Architecture 3 illustrates a remote network management architecture, according to an example embodiment. The architecture includes three main components: a managed network 300, a remote network management platform 320, and a public cloud network 340, all connected via the Internet 350.

[0051] (A. Managed Network) Managed network 300 may be, for example, an enterprise network used by an entity for computing and communication tasks and storage of data. Thus, managed network 300 may include client devices 302, server devices 304, routers 306, virtual machines 308, firewalls 310, and / or proxy servers 312. Client devices 302 are embodied by computing devices 100, server devices 304 are embodied by computing devices 100 or server clusters 200, and routers 306 may be any type of router, switch, or gateway.

[0052] The virtual machine 308 may be embodied by one or more of the computing devices 100 or the server cluster 200. In general, a virtual machine is an emulation of a computing system that mimics the functionality (e.g., processor, memory, and communication resources) of a physical computer. A single physical computing system, such as the server cluster 200, can support up to thousands of individual virtual machines. In some embodiments, the virtual machines 308 may be managed by a centralized server device or application that facilitates allocation of physical computing resources to individual virtual machines as well as performance and error reporting. Enterprises often employ virtual machines to efficiently allocate computing resources as needed. Providers of virtualized computing systems include VMWARE® and MICROSOFT®.

[0053] Firewall 310 may be one or more specialized router or server devices that protect managed network 300 from unauthorized attempts to access devices, applications, and services within managed network 300 while allowing authorized communications initiated from managed network 300. Firewall 310 may also provide intrusion detection, web filtering, virus scanning, application layer gateways, and other applications or services. In some embodiments not shown in FIG. 3, managed network 300 may include one or more VPN (Virtual Private Network) gateways for communicating with a remote network management platform 320 (see below).

[0054] The managed network 300 may also include one or more proxy servers 312. An embodiment of the proxy server 312 may be a server application that facilitates communication and movement of data between the managed network 300, the remote network management platform 320, and the public cloud network 340. In particular, the proxy server 312 may be capable of establishing and maintaining secure communication sessions with one or more computing instances of the remote network management platform 320. Such sessions may enable the remote network management platform 320 to discover and manage aspects of the architecture and configuration of the managed network 300 and its components.

[0055] The remote network management platform 320, possibly with the assistance of a proxy server 312, may also be able to discover and manage aspects of the public cloud networks 340 used by the managed network 300. Although not shown in FIGURE 3, one or more proxy servers 312 may be located in any of the public cloud networks 340 to facilitate this discovery and management.

[0056] A firewall, such as firewall 310, typically rejects all communication sessions coming in via Internet 350 unless the session is ultimately initiated from behind the firewall (i.e., from a device on managed network 300) or the firewall is explicitly configured to support the session. By locating proxy server 312 behind firewall 310 (e.g., within managed network 300 and protected by firewall 310), it may be possible for proxy server 312 to initiate these communication sessions through firewall 310. Thus, firewall 310 may not need to be specifically configured to support incoming sessions from remote network management platform 320, thereby avoiding potential security risks to managed network 300.

[0057] In some cases, the managed network 300 may consist of a small number of devices and a small number of networks. In other deployments, the managed network 300 may span multiple physical locations and include hundreds of networks and hundreds of thousands of devices. Thus, the architecture shown in FIG. 3 is capable of scaling up or down by several orders of magnitude.

[0058] Further, a varying number of proxy servers 312 may be deployed within the network depending on the size, architecture, and connectivity of the managed network 300. For example, each proxy server 312 may be responsible for communicating with a remote network management platform 320 for a portion of the managed network 300. Alternatively or additionally, a set of two or more proxy servers may be assigned to such portion of the managed network 300 for load balancing, redundancy, and / or high availability purposes.

[0059] (B. Remote Network Management Platform) The remote network management platform 320 is a hosted environment that provides aPaaS services to users, particularly operators of the managed network 300. These services may take the form of a web-based portal, for example using the web-based technologies described above. Thus, users may securely access the remote network management platform 320 from, for example, the client device 302, or possibly from client devices outside the managed network 300. The web-based portal allows users to design, test, and deploy applications, generate reports, view analytics, and perform other tasks. The remote network management platform 320 may also be referred to as a multi-application platform.

[0060] As shown in FIG. 3, the remote network management platform 320 includes four compute instances 322, 324, 326, and 328. Each of these compute instances may represent one or more server nodes and / or one or more database nodes operating a dedicated copy of the aPaaS software. The placement of the servers and database nodes on physical server devices and / or virtual machines may be flexible and may vary based on the needs of the enterprise. These nodes may combine to provide a set of web portals, services, and applications (e.g., a fully-featured aPaaS system) available to a particular enterprise. In some cases, a single enterprise may use multiple compute instances.

[0061] For example, managed network 300 may be an enterprise customer of remote network management platform 320 and may use compute instances 322, 324, and 326. The reason for providing multiple compute instances to one customer is that the customer may want to develop, test, and deploy its applications and services independently. Thus, compute instance 322 may be dedicated to developing applications related to managed network 300, compute instance 324 may be dedicated to testing these applications, and compute instance 326 may be dedicated to live operation of the tested applications and services. Compute instances may also be referred to as hosted instances, remote instances, customer instances, or some other name. Any application deployed to a compute instance may be a scoped application in that access to a database in that compute instance may be restricted to specific elements in the database (e.g., one or more specific database tables, or specific rows in one or more database tables).

[0062] For ease of understanding, the disclosure herein refers to the arrangement of application nodes, database nodes, the aPaaS software running thereon, and the underlying hardware as a "compute instance." Note that users may colloquially refer to the graphical user interface provided thereby as an "instance." However, unless otherwise defined herein, a "compute instance" is a computing system disposed within the remote network management platform 320.

[0063] The multi-instance architecture of the remote network management platform 320 contrasts with traditional multi-tenant architectures, which have several advantages over traditional multi-tenant architectures. In a multi-tenant architecture, data from various customers (e.g., businesses) is mixed in a single database. These customers' data are isolated from one another, but that isolation is achieved by the software that operates the single database. As a result, a security breach in this system can affect the data of all customers, creating additional risks, especially for entities subject to government, healthcare, and / or financial regulations. Furthermore, any database operation that affects one customer will likely affect all customers sharing that database. Thus, if there is an outage due to a hardware or software error, this outage will affect all such customers. Similarly, if a database is to be upgraded to meet the needs of one customer, the database will be unavailable to all customers during the upgrade process. Often, the size of the shared database makes such maintenance periods long.

[0064] In contrast, a multi-instance architecture gives each customer its own database within a dedicated compute instance. This prevents commingling of customer data and allows each instance to be managed independently. For example, when one customer's instance goes down due to an error or upgrade, other compute instances are not affected. Because the database contains only one customer's data, maintenance downtime is limited. Additionally, the simpler design of a multi-instance architecture allows for redundant copies of each customer database and instance to be deployed geographically diversely. This promotes high availability, allowing the live version of a customer's instance to be moved when a failure is detected or maintenance is being performed.

[0065] In some embodiments, the remote network management platform 320 may include one or more central instances controlled by the entity that operates the platform. Similar to the compute instances, the central instance may include several application and database nodes disposed on several physical server devices or virtual machines. Such a central instance may serve as a repository for the specific configuration of the compute instances and for data that may be shared among at least some of the compute instances. For example, definitions of common security threats that may occur on the compute instances, software packages commonly found on the compute instances, and / or an application store for applications that may be deployed on the compute instances may reside on the central instance. The compute instances may communicate with the central instance via a well-defined interface to obtain this data.

[0066] To efficiently support multiple compute instances, remote network management platform 320 may implement multiple of these instances on a single hardware platform. For example, when implemented on a server cluster, such as server cluster 200, the aPaaS system may run virtual machines that reserve different amounts of compute, storage, and communication resources for the instances. However, full virtualization of server cluster 200 may not be required, and other mechanisms may be used to isolate instances. In some examples, each instance may have a dedicated account and one or more dedicated databases on server cluster 200. Alternatively, compute instances, such as compute instance 322, may span multiple physical devices.

[0067] In some cases, a single server cluster of the remote network management platform 320 may support multiple independent enterprises. Additionally, as described below, the remote network management platform 320 may include multiple server clusters deployed in different geographic data centers to facilitate load balancing, redundancy, and / or high availability.

[0068] (C. Public Cloud Network) The public cloud network 340 may be a remote server device (e.g., multiple server clusters such as server cluster 200) that can be used for outsourced computing, data storage, communication, and service hosting operations. These servers may be virtualized (i.e., the servers may be virtual machines). Examples of the public cloud network 340 may include AMAZON WEB SERVICES® and MICROSOFT® AZURE®. Similar to the remote network management platform 320, the multiple server clusters supporting the public cloud network 340 may be deployed in different geographic locations for load balancing, redundancy, and / or high availability purposes.

[0069] The managed network 300 can deploy applications and services to its clients and customers using one or more public cloud networks 340. For example, if the managed network 300 provides an online music streaming service, the public cloud network 340 can store the music files and provide a web interface and streaming functionality. In this way, the enterprise of the managed network 300 does not need to build and maintain its own servers for these operations.

[0070] The remote network management platform 320 may include modules that integrate with the public cloud network 340 to expose internal virtual machines and managed services to the managed network 300. These modules may enable users to request virtual resources, discover allocated resources, and provide flexible reports on the public cloud network 340. To establish this functionality, a user from the managed network 300 may first establish an account with the public cloud network 340 and request a set of related resources. The user may then enter the account information into the appropriate modules of the remote network management platform 320. These modules may then automatically discover manageable resources in that account and provide reports on usage, performance, and billing.

[0071] D. Communications Support and Other Operations The Internet 350 may represent a portion of the global Internet, but may alternatively represent a different type of network, such as a private wide-area or local-area packet-switched network.

[0072] 4 further illustrates a communication environment between managed network 300 and compute instances 322, introducing additional functionality and alternative embodiments. In FIG. 4, compute instances 322 are replicated, in whole or in part, across data centers 400A and 400B. These data centers are geographically separated from one another and may be in different cities or different countries. Each data center includes supporting equipment that facilitates communication with managed network 300 and remote users.

[0073] In data center 400A, network traffic to and from external devices flows through either VPN gateway 402A or firewall 404A. VPN gateway 402A can peer with VPN gateway 412 of managed network 300 by security protocols such as Internet Protocol Security (IPsec) or Transport Layer Security (TLS). Firewall 404A can be configured to allow access from authorized users, such as user 414 and remote user 416, and deny access to unauthorized users. Firewall 404A allows these users to access compute instance 322 and possibly other compute instances. Load balancer 406A can be used to distribute traffic among one or more physical or virtual server devices hosting compute instance 322. Load balancer 406A can simplify user access by hiding the internal configuration of data center 400A (e.g., compute instance 322) from client devices. For example, if the compute instance 322 includes multiple physical or virtual computing devices that share access to multiple databases, the load balancer 406A can distribute network traffic and processing tasks across these computing devices and databases so that one computing device or database is not significantly busier than others. In some embodiments, the compute instance 322 may include a VPN gateway 402A, a firewall 404A, and a load balancer 406A.

[0074] Data center 400B may include its own versions of components in data center 400A. Thus, VPN gateway 402B, firewall 404B, and load balancer 406B may perform the same or similar operations as VPN gateway 402A, firewall 404A, and load balancer 406A, respectively. Additionally, with real-time or near real-time database replication and / or other operations, compute instances 322 may exist simultaneously in data centers 400A and 400B.

[0075] The data centers 400A and 400B shown in Figure 4 can facilitate redundancy and high availability. In the configuration of Figure 4, data center 400A is active and data center 400B is passive. Thus, data center 400A serves all traffic to and from managed network 300, and the versions of compute instances 322 in data center 400B are updated in near real-time. Other configurations, such as a configuration in which both data centers are active, may also be supported.

[0076] If data center 400A experiences some kind of failure or becomes unavailable to users for other reasons, data center 400B can take over as the active data center. For example, a Domain Name System (DNS) server that associates the domain name of compute instance 322 with one or more Internet Protocol (IP) addresses of data center 400A may reassociate the domain name with one or more IP addresses of data center 400B. After this reassociation is complete (which may take less than a second or a few seconds), users can access compute instance 322 through data center 400B.

[0077] 4 also illustrates possible configurations of the managed network 300. As described above, the proxy server 312 and the user 414 can access the compute instance 322 through the firewall 310. The proxy server 312 can also access the configuration items 410. In FIG. 4, the configuration items 410 may represent any or all of the client device 302, the server device 304, the router 306, and the virtual machine 308, any components thereof, any applications or services running thereon, and relationships between the devices, components, applications, and services. Thus, the term "configuration item" may be shorthand for any physical or virtual device, or any application or service remotely discoverable or managed by the compute instance 322, or some of the relationships between the discovered devices, applications, and services. The configuration items may be represented in a configuration management database (CMDB) of the compute instance 322.

[0078] When stored or transmitted, a configuration item may be a list of attributes that characterize the hardware or software that it represents. These attributes may include manufacturer, vendor, location, owner, unique identifier, description, network address, operational status, serial number, last update time, etc. The class of a configuration item may determine what subset of attributes is present for that configuration item (e.g., a software configuration item and a hardware configuration item may have different attribute lists).

[0079] As described above, VPN gateway 412 may provide a dedicated VPN for VPN gateway 402A. Such a VPN may be useful when there is a large amount of traffic between managed network 300 and compute instance 322, or when security policies suggest or require the use of a VPN between these sites. In some embodiments, any device in managed network 300 and / or compute instance 322 that communicates directly through the VPN is assigned a public IP address. Other devices in managed network 300 and / or compute instance 322 may be assigned private IP addresses (e.g., IP addresses selected from the ranges 10.0.0.0 - 10.255.255.255 or 192.168.0.0 - 192.168.255.255, abbreviated as subnets 10.0.0.0 / 8 and 192.168.0.0 / 16, respectively). In various alternatives, devices in the managed network 300, such as the proxy server 312, can communicate directly with one or more data centers using a secure protocol (eg, TLS).

[0080] IV. EXEMPLARY DISCOVERY In order for the remote network management platform 320 to manage the devices, applications, and services of the managed network 300, the remote network management platform 320 may first determine the devices present in the managed network 300, their configurations, configuration components, and operational status, as well as the applications and services provided by those devices. The remote network management platform 320 may also determine the relationships between the discovered devices, their components, applications, and services. The representation of each device, component, application, and service may be referred to as a configuration item. The process of determining the configuration items and relationships in the managed network 300 is referred to as discovery, and may be facilitated at least in part by the proxy server 312. The representations of the configuration items and relationships are stored in the CMDB.

[0081] Although this section describes discovery occurring on the managed network 300, the same or similar discovery procedures may also be used on the public cloud network 340. Thus, in some environments, "discovery" may refer to the discovery of configuration items and relationships on the managed network and / or one or more public cloud networks.

[0082] For purposes of embodiments herein, an "application" may represent one or more processes, threads, programs, client software modules, server software modules, or any other software running on a device or group of devices. A "service" may represent a higher level of functionality provided by one or more applications running on one or more devices working in conjunction with each other. For example, a web service may include multiple web application server threads running on one device and accessing information from a database application running on another device.

[0083] 5 illustrates in a logical diagram how configuration items and relationships can be discovered and how information relating to them can be stored. For simplicity, remote network management platform 320, public cloud network 340, and Internet 350 are not shown.

[0084] 5, the CMDB 500, task list 502, and identification and reconciliation engine (IRE) 514 are disposed within and / or operate within the compute instance 322. The task list 502 forms a connection point between the compute instance 322 and the proxy server 312. The task list 502 may also be referred to as a queue, or more specifically, an external communication channel (ECC) queue. The task list 502 may represent the queue itself as well as any associated processing, such as adding, removing, and / or manipulating information in the queue.

[0085] When discovery occurs, the compute instance 322 may store discovery tasks (jobs) in a task list 502 for the proxy server 312 to execute until the proxy server 312 requests these tasks in one or more batches. Placing tasks in the task list 502 may trigger or otherwise cause the initiation of those discovery operations by the proxy server 312. For example, the proxy server 312 may poll the task list 502 periodically or from time to time, or may be notified of a discovery command in the task list 502 in some other manner. Alternatively or additionally, discovery may be triggered manually or automatically based on a trigger event (e.g., discovery may begin automatically once a day at a particular time).

[0086] In any case, the compute instance 322 may send these discovery commands to the proxy server 312 upon request. For example, the proxy server 312 may repeatedly query the task list 502 to obtain the next task in the task list 502 and execute this task until the task list 502 is empty or another stop condition is reached. In response to receiving the discovery command, the proxy server 312 may query various devices, components, applications, and / or services in the managed network 300 (represented by devices 504, 506, 508, 510, and 512 in FIG. 5 for simplicity). These devices, components, applications, and / or services may provide responses to the proxy server 312 regarding their configuration, operation, and / or status. The proxy server 312 may then provide this discovered information to the task list 502 (i.e., the task list 502 may have an outgoing queue for holding discovery commands until requested by the proxy server 312 and an incoming queue for holding discovery information until read).

[0087] IRE 514 may be a software module that removes discovery information from task list 502 and formulates this discovery information into configuration items (e.g., representing devices, components, applications, and / or services discovered on managed network 300) and relationships between them. IRE 514 may then provide these configuration items and relationships to CMDB 500 for storage therein. The operation of IRE 514 is described in more detail below.

[0088] In this manner, the configuration items stored in CMDB 500 represent the environment of managed network 300. As an example, these configuration items may represent a set of physical and / or virtual devices (e.g., client devices, server devices, routers, or virtual machines), applications running thereon (e.g., web servers, email servers, databases, or storage arrays), and services that include multiple individual configuration items. Relationships may be pairwise definitions of placement or dependencies between configuration items.

[0089] To perform discovery as described above, the proxy server 312, the CMDB 500, and / or one or more credential stores may be configured with credentials for devices to be discovered. The credentials may include any type of information needed to access the devices. They may include user ID / password pairs, certificates, etc. In some embodiments, these credentials may be stored in encrypted fields in the CMDB 500. The proxy server 312 may include a decryption key for the credentials so that they can be used to log on to or otherwise access the devices being discovered.

[0090] There are two general types of discovery: horizontal and vertical (top-down), each of which is discussed below.

[0091] (A. Horizontal Discovery) Horizontal discovery is used to scan the managed network 300, find devices, components, and / or applications, and then populate the CMDB 500 with configuration items that represent these devices, components, and / or applications. Horizontal discovery also creates relationships between configuration items. For example, this can be a "runs on" relationship between a configuration item that represents a software application and a configuration item that represents the server device on which it runs. Typically, horizontal discovery is not service aware and does not create relationships between configuration items based on the services on which they run.

[0092] There are two versions of horizontal discovery: one relies on probes and sensors, and the other also employs patterns. Probes and sensors can be scripts (e.g., written in JAVASCRIPT) that collect and process discovery information on devices and then update the CMDB 500 accordingly. More specifically, probes explore or probe devices on the managed network 300, and sensors analyze the discovery information returned by the probes.

[0093] A pattern is also a script that collects data on one or more devices, processes that data, and updates the CMDB. Patterns differ from probes and sensors in that they are written in a specific discovery programming language and are used to perform detailed discovery procedures on specific devices, components, and / or applications that often cannot be reliably (or at all) discovered by more general probes and sensors. In particular, a pattern may specify a set of operations that define how to discover a particular deployment of devices, components, and / or applications, what credentials to use, and which CMDB tables to populate with the configuration items resulting from this discovery.

[0094] Both versions may proceed in four logical phases: scanning, classification, identification, and exploration. Both versions may also require specification of one or more ranges of IP addresses on the managed network 300 where discovery will occur. Each phase may involve communication between devices on the managed network 300 and the proxy server 312, and between the proxy server 312 and the task list 502. Some phases may involve storing partial or preliminary configuration items in the CMDB 500, which may be updated in later phases.

[0095] In the scan phase, the proxy server 312 may probe each IP address within a specified range of IP addresses for open TCP (Transmission Control Protocol) and / or UDP (User Datagram Protocol) ports to determine the general type of device and its operating system. The presence of such open ports at an IP address may indicate that a particular application is running on the device assigned to that IP address, which may further identify the operating system used by the device. For example, if TCP port 135 is open, the device is likely running a WINDOWS operating system. Similarly, if TCP port 22 is open, the device is likely running a UNIX operating system such as LINUX. If UDP port 161 is open, the device may be able to be further identified via SNMP (Simple Network Management Protocol). Other possibilities exist.

[0096] In the classification phase, the proxy server 312 may further probe each discovered device to determine its operating system type. The probes used for a particular device are based on information collected about the device during the scan phase. For example, if a device is found with TCP port 22 open, a set of UNIX-specific probes may be used. Similarly, if a device is found with TCP port 135 open, a set of WINDOWS-specific probes may be used. In either case, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to log on to or otherwise access information from a particular device. For example, if TCP port 22 is open, the proxy server 312 may be instructed to initiate an SSH (Secure Shell) connection to the particular device and retrieve information about a particular type of operating system on that device from a particular location in the file system. Based on this information, the operating system may be determined. As an example, a UNIX® device with TCP port 22 open may be classified as AIX®, HPUX, LINUX®, MACOS®, or SOLARIS®. This classification information may be stored in CMDB 500 as one or more configuration items.

[0097] In the identification phase, the proxy server 312 may determine certain details about the classified device. The probes used during this phase may be based on information collected about the particular device during the classification phase. For example, if the device is classified as LINUX, a set of LINUX-specific probes may be used. Similarly, if the device is classified as WINDOWS 10, a set of WINDOWS-specific probes may be used. As with the classification phase, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks will enable the proxy server 312 to read information from the particular device, such as BIOS (basic input / output system) information, serial numbers, network interface information, media access control addresses assigned to these network interfaces, IP addresses used by the particular device, etc. This identification information, along with any significant relationships between them, may be stored in the CMDB 500 as one or more configuration items. This implementation may include passing the identification information through the IRE 514 to avoid the creation of duplicate configuration items for disambiguation purposes and / or to determine the tables in the CMDB 500 to which the discovery information should be written.

[0098] In the discovery phase, the proxy server 312 may determine further details regarding the operational state of the classified device. The probes used during this phase may be based on information collected about the particular device during the classification and / or identification phases. Again, an appropriate set of tasks may be placed in the task list 502 for the proxy server 312 to execute. These tasks enable the proxy server 312 to read additional information from the particular device, such as processor information, memory information, a list of running processes (software applications), etc. Again, the discovered information may be stored in the CMDB 500 as one or more configuration items, and relationships.

[0099] Performing horizontal discovery on certain devices, such as switches and routers, may utilize SNMP. Instead of or in addition to determining a list of running processes or other application-related information, discovery may determine additional subnets known to the router and the operational state of the router's network interfaces (e.g., active, inactive, queue lengths, number of dropped packets, etc.). The IP addresses of the additional subnets may become candidates for further discovery procedures. Thus, horizontal discovery may proceed iteratively or recursively.

[0100] Patterns are only used during the identification and exploration phases. Under pattern-based discovery, the scanning and classification phases proceed in the same way as when probes and sensors are used. After the classification phase is complete, a pattern probe is designated as the probe to use during identification. The pattern probe and the pattern it designates are then activated.

[0101] Patterns, through their discovery programming language, support many features that are not available or difficult to achieve with discovery using probes and sensors. For example, discovery of devices, components, and / or applications in public cloud networks, as well as tracking of configuration files, can be achieved much more easily using pattern-based discovery. Furthermore, these patterns are more easily customized by users than probes and sensors. Furthermore, patterns are more focused on specific devices, components, and / or applications, and therefore may execute faster than the more general approach used by probes and sensors.

[0102] Once horizontal discovery is complete, a configuration item representation of each discovered device, component, and / or application is available in CMDB 500. For example, after discovery, operating system versions, hardware configurations, and network configuration details for client devices, server devices, and routers in managed network 300, and the applications running thereon, may be stored as configuration items. This collected information is presented to the user in various ways to allow the user to view the hardware configuration and operational status of devices.

[0103] Further, the CMDB 500 may include entries regarding relationships between configuration items. More specifically, assume that a server device includes a number of hardware components (e.g., a processor, memory, a network interface, storage, and a file system) and has several software applications installed or running. The relationships between the components and the server device (e.g., a "contains" relationship), and the relationships between the software applications and the server device (e.g., a "runs" relationship) may themselves be represented in the CMDB 500.

[0104] More generally, the relationships of software configuration items installed on or running on a hardware configuration item may take various forms, such as "hosted," "runs," or "depends on." Thus, a database application installed on a server device may have a "hosted" relationship with the server device, indicating that the database application is hosted on the server device. In some embodiments, the server device may have a "used" mutual relationship with the database application, indicating that the server device is used by the database application. These relationships may be discovered automatically using the discovery procedures described above, although it is also possible to set the relationships manually.

[0105] In this manner, the remote network management platform 320 is able to discover and inventory the hardware and software deployed on and provided by the managed network 300 .

[0106] (B. Vertical Discovery) Vertical discovery is a technique used to find and map configuration items that are part of an entire service, such as a web service. For example, vertical discovery can map a web service by showing the relationships between web server applications, LINUX server devices, and databases that store data about the web service. Typically, horizontal discovery is performed first to discover configuration items and the basic relationships between the configuration items, and then vertical discovery is performed to establish the relationships between the configuration items that make up the service.

[0107] Patterns can be programmed to look for specific arrangements of hardware and software that fit a description of how the service will be deployed, and therefore can be used to discover specific types of services. Alternatively or additionally, traffic analysis (e.g., inspection of network traffic between devices) can be used to facilitate vertical discovery. In some cases, parameters of a service can be manually configured to assist in vertical discovery.

[0108] In general, vertical discovery attempts to find certain types of relationships between devices, components, and / or applications. Some of these relationships may be inferred from configuration files. For example, a configuration file for a web server application may reference the IP addresses and port numbers of databases it relies on. A vertical discovery pattern can be programmed to look for such references and infer relationships from them. Relationships can also be inferred from traffic between devices. For example, a load balancer and a web server may have a relationship if there is a large amount of web traffic (e.g., TCP port 80 or 8080) occurring between the load balancer and a device hosting the web server.

[0109] Relationships found by vertical discovery may take a variety of forms. As an example, an email service may include an email server software configuration item and a database application software configuration item, each installed on different hardware device configuration items. The email service may have a "depends on" relationship with both of these software configuration items, and the software configuration items have a "uses" interrelationship with the email service. Such services may not be fully determinable by a horizontal discovery procedure, and may rely on vertical discovery and possibly some degree of manual configuration.

[0110] (C. Benefits of Discovery) Regardless of how discovery information is obtained, it can be valuable to the operation of a managed network. In particular, IT personnel can quickly determine where a particular software application is deployed and what configuration items make up the service. This allows for faster identification of the root cause of a service outage or degradation. For example, if two different services have slow response times, a CMDB can be queried (perhaps among other activity) and it can be determined that a database application with high processor utilization used by both services is the root cause. Thus, IT personnel can address the database application without wasting time considering the health and performance of the other configuration items that make up the service.

[0111] In another example, assume that a database application is running on a server device and that the database application is used by an employee onboarding service and a payroll service. Therefore, if the server device is taken out of operation for maintenance, it is clear that the employee onboarding service and the payroll service will be affected. Similarly, dependencies and relationships between configuration items may be able to represent the services that are affected when a particular hardware device fails.

[0112] Typically, configuration items and / or relationships between configuration items may be displayed and represented in a hierarchical format on a web-based interface, and changes to such configuration items and / or relationships in the CMDB may be accomplished through this interface.

[0113] Additionally, users from the managed network 300 can develop workflows that allow specific coordinated activities to occur across multiple discovered devices. For example, an IT workflow might allow a user to change a common administrator password to all discovered LINUX devices in a single operation.

[0114] (V.CMDB Identification Rules and Reconciliation) A CMDB such as CMDB 500 provides a repository of configuration items and relationships that, when properly provisioned, can play a critical role in higher-tier applications that are deployed within or involve the compute instance. These applications may relate to enterprise IT service management, operations management, asset management, configuration management, compliance, etc.

[0115] For example, an IT service management application may use information in a CMDB to determine which applications and services may be affected by a component (e.g., a server device) that is malfunctioning, crashing, or experiencing high load. Similarly, an asset management application may use information in a CMDB to determine which hardware and / or software components are being used to support a particular enterprise application. Due to the importance of the CMDB, it is desirable for the information stored in the CMDB to be accurate, consistent, and up-to-date.

[0116] A CMDB can be populated in a variety of ways. As discussed above, discovery procedures can automatically store information, including configuration items and relationships, in the CMDB. However, the CMDB can also be populated, in whole or in part, by manual input, configuration files, and third-party data sources. Given that multiple data sources may be able to update the CMDB at any time, it is possible that one data source may overwrite the entries of another. Also, two data sources may each create slightly different entries for the same configuration item, resulting in a CMDB that contains duplicate data. When any of these events occur, it can reduce the health and usefulness of the CMDB.

[0117] To mitigate this situation, these data sources may not write configuration items directly to the CMDB, but instead may write to an Identification and Reconciliation Application Programming Interface (API) of IRE 514. IRE 514 can then use a set of configurable identification rules to uniquely identify configuration items and determine whether and how to write them to the CMDB.

[0118] In general, an identification rule specifies a set of configuration item attributes that can be used for this unique identification. Identification rules may also have a priority, with rules with higher priority being considered before rules with lower priority. Additionally, rules may be independent in that they identify some configuration items independently from other configuration items. Alternatively, rules may be dependent in that they first use metadata rules to identify dependent configuration items.

[0119] Metadata rules describe which other configuration items are contained within a particular configuration item or on which hosts a particular configuration item is deployed (for example, a network directory service configuration item may contain a domain controller configuration item, and a web server application configuration item may be hosted on a server device configuration item).

[0120] The goal of each identification rule is to use a combination of attributes that can clearly distinguish a configuration item from all other configuration items and that are expected not to change during the lifetime of the configuration item. Some possible attributes for an example server device can include serial number, location, operating system, operating system version, memory capacity, etc. If a rule specifies an attribute that does not uniquely identify a configuration item, multiple components may be represented as the same configuration item in the CMDB. Also, if a rule specifies an attribute that changes for a particular configuration item, duplicate configuration items may be created.

[0121] Thus, when a data source provides information about a configuration item to IRE 514, IRE 514 may attempt to match that information against one or more rules. If a match is found, the configuration item is written to the CMDB or updated if already in the CMDB. If no match is found, the configuration item may be held for further analysis.

[0122] A configuration item reconciliation procedure can be used to ensure that only trusted data sources are allowed to overwrite configuration item data in the CMDB. This reconciliation can be rule-based. For example, a reconciliation rule may specify that a particular data source is trusted for a particular configuration item type and set of attributes. The IRE 514 can then allow only this trusted data source to write to a particular configuration item and can prevent writes from unauthorized data sources. Thus, the authorized data source becomes the single source of truth for a particular configuration item. In some cases, unauthorized data sources may be allowed to write to a configuration item if they are creating the configuration item or if the attribute to write to is empty.

[0123] Furthermore, multiple data sources may be authoritative for the same configuration item or its attributes. To avoid ambiguity, these data sources may be assigned a priority that is considered while writing a configuration item. For example, an authorized secondary data source may be allowed to write to an attribute of a configuration item until an authorized primary data source writes to this attribute. After that, further writing to the attribute by the authorized secondary data source may be prevented.

[0124] In some cases, duplicate configuration items may be detected automatically or otherwise by IRE 514. These configuration items may be deleted or flagged for manual de-duplication.

[0125] (VI. Discovery Command Verification Tool) The discovery procedures discussed here greatly facilitate the maintenance and operation of various types of IT systems. Nevertheless, these systems are becoming increasingly complex and are often customized in such a way that discovering them using traditional pattern-less discovery is impossible or inefficient. Thus, over the last few years, patterns have gained importance and usage.

[0126] One example of the power and usefulness of pattern-based discovery can be understood in the context of a virtual machine cluster. In such a cluster, virtual machines may be spun up (activated) or spun down (deactivated) over time, so it may be difficult for a traditional discovery procedure to locate and probe each of these virtual machines. However, most virtual machine clustering techniques use some form of control node (e.g., a hypervisor) that manages the virtual machines. The control node may be aware of the number and location of these virtual machines, their roles, their redundancy schemes, etc. The control node may also be able to query each virtual machine to determine this information or real-time performance data, such as uptime, load, utilization, or other factors. To do this, the control node may be configured with a command line or a representational state transfer (REST) ​​interface from which commands can be received.

[0127] In this case, discovery of a virtual machine cluster may involve accessing a control node through its interface and querying information about its supported virtual machines. To do so may require that the control node be reachable by the discovery infrastructure (e.g., by a proxy server), that appropriate credentials (e.g., user ID and password) be provided to the control node, that these credentials are authorized to perform any commands issued to the control node, and that the commands are properly formatted. If any of these requirements are not met, discovery will most likely fail. It is therefore advantageous for patterns to be properly tested or validated before being deployed.

[0128] In some cases, a discovery pattern includes a list of commands that are intended to be performed in a given order, possibly with dependencies between the commands. In the example of a control node of a virtual machine cluster, a first command may request a list of virtual machines managed by the control node, and a subsequent command may request details about each virtual machine. If an earlier command in the sequence fails, the entire pattern may terminate without even attempting to execute subsequent commands. Thus, failure of some discovery patterns may result in some commands not being executed, leaving their validity in an indeterminate state.

[0129] As an example, Figure 6A shows a virtual machine cluster 600. Virtual machine cluster 600 includes a control node 602, as well as M processing nodes (labeled 604-1 through 604-M) and N storage nodes (labeled 606-1 through 606-N). The processing and storage nodes are assumed to be virtual machines. The use of ellipsis indicates that M and N can take any value equal to or greater than 1.

[0130] The control node 602 may, for example, <address>The hypervisor may use a network address indicated by: This network address may be an IP address (e.g., IPv4 or IPv6) or any other type of network address. In the following description, IP addresses are used for simplicity, but the embodiments herein are not limited in this manner.

[0131] Control node 602 may dynamically manage processing nodes 604-1-604-M and storage nodes 606-1-606-N. The values ​​of M and N at a given time may be based on actual demand, expected demand, past demand, or other factors. Additionally, processing nodes 604-1-604-M may employ a redundancy scheme with several running virtual machines and one or more idle virtual machines ready to take over the role of a running virtual machine if the running virtual machine fails, is deactivated, or is otherwise unable to perform its task. Similarly, storage nodes 606-1-606-N may employ similar redundancy mechanisms.

[0132] These processing and storage nodes may be capable of determining various characteristics related to uptime, load, utilization, etc. Furthermore, each processing and storage node is assumed to have a unique identifier that can be referenced by the control node 602.

[0133] 6B illustrates a discovery pattern 610 for discovering components of a virtual machine cluster 600. The pattern is expressed at a high level for clarity. An actual discovery pattern may be written in a discovery programming language with commands and execution flow control features (e.g., branching or looping) similar to off-the-shelf scripting languages.

[0134] Additionally, the commands of the discovery pattern 610 may be formatted and communicated via a command line interface, a REST interface, an SNMP interface, or a Windows Management Instrumentation (WMI) interface. Other types of interfaces may be supported instead of or in addition to any of these interfaces. Depending on system requirements, the same or different credentials may appear in each command. Alternatively, some commands may not require credentials.

[0135] Command 1 of discovery pattern 610 causes a computing device (e.g., a proxy server) to request credentials <credentials>Network address <address>Log on to As mentioned above, <address>may be the IP address of the control node 602, <credentials>may be a user ID / password pair or some other form of authentication token that grants access to the control node 602.

[0136] Command 2 causes the computing device to request a list of processing nodes from control node 602. This list may include a unique identifier for each of processing nodes 604-1 through 604-M.

[0137] Command 3 causes the computing device to request the uptime and load of each of the processing nodes 604-1 through 604-M in the list. For example, command 3 may actually be multiple commands for each processing node (e.g., a "get uptime" and a "get load" command for each processing node in the list).

[0138] Command 4 causes the computing device to request a list of storage nodes from the control node 602. This list may include a unique identifier for each of the storage nodes 606-1 through 606-N.

[0139] Command 5 causes the computing device to request the utilization of each of the storage nodes 606-1 through 606-N in the list. For example, command 5 may actually be one command for each storage node (e.g., a “get utilization” command for each processing node in the list).

[0140] Other commands not shown may also be employed to determine relationships between nodes of virtual machine cluster 600 and / or obtain other information from any of the nodes. Additionally, additional commands may write the results from commands 2-5, and any information inferred therefrom, to various database tables (e.g., in a CMDB).

[0141] Because discovery is typically performed infrequently (e.g., once every few hours, once a day, or once a week), debugging a pattern through a discovery procedure is a time-consuming process that may take days or even weeks. A pattern failure may not clearly identify the cause of the failure. Furthermore, changes intended to repair a defect in a pattern are not guaranteed to address this cause and may even introduce additional defects that are not found until a later discovery run.

[0142] Embodiments herein address these and possibly other limitations by introducing a validation tool for discovery commands. Essentially, the validation tool is software that takes a list of one or more discovery commands (e.g., entered manually or parsed from a discovery pattern) and a list of one or more network addresses for each discovery command. Parsing the discovery commands from the pattern may include iterating through the pattern, identifying commands in the pattern (e.g., based on syntax and / or keywords), and extracting these commands. Advantageously, the analysis can be performed dynamically each time the validation tool is used, so that changes to the pattern are automatically incorporated into the validation tool's process.

[0143] The validation tool then attempts to execute each discovery command against each network address in its associated list and reports the results of the execution for each command / address pair. These results may include an indication of success (e.g., a Boolean value representing successful execution of the command, response code, command output, other text, etc.) or an indication of failure (e.g., a Boolean value representing unsuccessful execution of the command, error code, command output, other text, etc.). In some embodiments, a common list of network addresses may be used for all discovery commands.

[0144] As mentioned above, a discovery pattern is not required: the validation tool may also run with one or more related or unrelated discovery commands that do not appear in the discovery pattern.

[0145] A verification tool may also be referred to herein as a "discovery verification application," a "verification application," or some other name. Such a verification tool may include software configured to run on a remote network management platform or possibly some other type of platform.

[0146] The validation tool is intended to be used before a pattern is added to a scheduled discovery procedure, independent of these procedures. For example, a user can test commands from a pattern on a list of IP addresses, debug the pattern if necessary, and finally determine that the pattern is working as expected, and then deploy the pattern for the next scheduled discovery procedure. However, the validation tool can also be used against deployed patterns in an attempt to reproduce any failures. In any case, the validation tool provides results much more quickly than discovery procedures (e.g., in seconds or minutes instead of days), thus significantly improving the ability to develop, test, and successfully deploy patterns.

[0147] FIG. 7 illustrates an exemplary architecture in which a validation tool 700 is configured to execute within a compute instance 322. This architecture is essentially the same as the architecture of FIG. 5, except that it illustrates the validation tool 700 and does not illustrate the task list 502 or the IRE 514. In particular, the validation tool 700 receives as input a discovery command and a network address, transmits a representation of the discovery command and the network address to one of the proxy servers 312, receives discovery information from the proxy server, and provides the results to the CMDB 500. The proxy server 312 can apply the discovery command to the network address via an appropriate discovery interface. As previously mentioned, each discovery command can apply to the same or different lists of one or more network addresses. Furthermore, in some environments the use of a proxy server is not required and the validation tool may communicate in a more direct manner with the computing device on which discovery is performed.

[0148] In FIG. 7, the discovery commands may take the form of, for example, individual commands, a list of commands, or the entire discovery pattern. The network address may be a list of such addresses. Using the example of IP addresses, the network address may be a single IP address (e.g., "10.172.43.167"), a list of IP addresses (e.g., "10.172.43.167", "10.172.43.168", "10.172.44.17"), or a range of IP addresses (e.g., "10.172.43.0-10.172.43.255" or "10.172.43 / 24").

[0149] As discussed above, types of discovery failures that may be detected by the validation tool 700 include unreachable network addresses, authentication failures, authorization failures, and / or unsupported commands. Additional types of failures may also be detected.

[0150] A network address may be considered unreachable when one or more attempts to issue a command to a computing device purportedly at that address are unsuccessful. Reasons for such failure may include the address not being in use, the address not being routable from the proxy server issuing the command, a typographical error in the way the address is specified to the verification tool, or the computing device at the address not responding to the attempts. An unreachable network address is typically detected when one or more attempts to issue a command receive no response, or when the commands receive a response from a nearby router or switch indicating that the router or switch does not know how to forward the command to the network address. Alternatively, a proxy server (e.g., one of proxy servers 312) may be unreachable from the verification tool (e.g., verification tool 700).

[0151] An authentication failure occurs when a network address is reachable, but the credentials provided are not accepted by the computing device at that address. For example, the credentials may not be configured on the computing device. In some cases, an authentication failure occurs when credentials are required for a command to be executed by the computing device at that address, but the credentials were not provided. An authentication failure is typically detected by the validation tool 700 receiving an error message indicating that authentication has failed for the issued command.

[0152] Unlike an authentication failure, an authorization failure occurs when a command is successfully authenticated by a computing device at its address (if such authentication is required), but the account or user ID from which the command is issued does not have permission to execute the command. For example, the verification tool 700 may be logged into a non-privileged account, but a command (e.g., a UNIX "sudo" command) can only be executed by a privileged (e.g., superuser or root) account. An authorization failure is detected by the verification tool 700 receiving an error message indicating that authorization has failed for the issued command.

[0153] Unsupported commands include commands that are not supported by the computing device at the address, and unsupported options or parameters for supported commands. A command with a typographical error is one possible example of an unsupported command. An unsupported command is detected by the validation tool 700 receiving an error message indicating that the issued command resulted in an indication that the command was not found or unknown. Note that the validation tool may not know if a command is not supported and may only be notified if it is not supported by receiving an error message. On the other hand, the validation tool may be configured with a list of supported commands and may proactively flag errors for commands that are not on this list.

[0154] In some cases, the validation tool may read the discovery command and network addresses from a table in a database (e.g., CMDB 500). Additionally, the validation tool may write to temporary tables in a database (e.g., CMDB 500) configured to store results and / or specific discovery information.

[0155] 8 shows validation tool 700 reading discovery commands and network addresses from database table 800 and writing corresponding discovery results to database table 802. Database table 800 and database table 802 may be part of the same database (e.g., CMDB 500) or may be part of different databases.

[0156] [Table 1]

[0157] An example of a possible schema for database table 800 is shown in Table 1. For example, each entry in database table 800 may include some of the attributes listed in Table 1 (i.e., number, ip_address, os_class, command_type, command, proxy_server, progress, status, credentials, and / or is_automated). In Table 1, each of these attributes is specified in terms of a name, label, type, and description. Examples are provided for some of the attributes.

[0158] The number attribute may be a unique identifier for the entry. The ip_address attribute may specify one or more IP addresses. The os_class attribute may specify the type of operating system on which the command is executed. The command_type attribute may specify whether the command can be delivered via shell (CLI), SNMP, WMI, or HTTP GET (e.g., via a web-based REST interface). The command attribute may specify the actual command to issue to the IP address. The proxy_server attribute may specify a proxy server to route the command to (if no proxy server is specified, a default proxy server may be used). The progress attribute may specify what percentage of results have been received for an executing command. The status attribute may specify whether command execution is complete and all results have been received. The credentials attribute may specify a reference to a set of credentials stored in another database table. The is_automated attribute may specify whether automated command validation is used (to parse commands from patterns) or whether the command is provided as user input.

[0159] Notably, Table 1 is only one example of the types of attributes that may be present: in various embodiments, there may be more or fewer attributes.

[0160] [Table 2]

[0161] An example of a possible schema for database table 802 is shown in Table 2. For example, each entry in database table 802 may include some of the attributes listed in Table 2 (i.e., command_validation, ip_address, os_class, command_type, command, proxy_server, state, result, result_details, and / or steps_to_remediate). In Table 2, each of these attributes is specified in terms of a name, label, type, and description. Examples are provided for some of the attributes.

[0162] In particular, a single entry in database table 800 may generate multiple entries in database table 802 based on the number of IP addresses on which the command is to be executed. For example, if an entry in database table 800 specifies that the command may be executed on 10 IP addresses, then there will be 10 entries in database table 802, one for each of those IP addresses.

[0163] The command_validation attribute may specify an entry in database table 800 that contains the command and the IP address of the computing device on which the command that produced this result was executed. The ip_address attribute may specify the IP address of the computing device on which the command was executed. The os_class attribute may specify the type of operating system of this computing device. The command_type attribute may specify how the command was delivered, such as shell (CLI), SNMP, WMI, or HTTP GET (e.g., via a web-based REST interface). The command attribute may specify the actual command that was issued. The proxy_server attribute may specify a proxy server that routed the command. The state attribute may specify whether the command is waiting for processing at the IP address, is processing at the IP address, or has completed processing at the IP address. The result attribute may specify whether the command succeeded or failed to execute. The result_details attribute may specify a reason for failure (if the command failed) or an indication of the output of the command (if the command succeeded). The steps_to_remediate attribute can specify or link to instructions about what can be done to address any failures that have been encountered, if such information is available.

[0164] Like Table 1, Table 2 is only one example of the types of attributes that may be present. In various embodiments, there may be more or fewer attributes.

[0165] 9 illustrates the operation of a validation tool that brings these functions together. Process 900 includes a command launcher 910 receiving a user-provided list 902 of discovery commands and network addresses, and / or discovery commands and network addresses 908 extracted from patterns 904 by a pattern parser 906.

[0166] Command launcher 910 launches a series of probes 912A, 912B, 912C, and 912D by sending discovery commands to network addresses (e.g., via a proxy server). Thus, for example, probe 912A sends command cmd1 to network address addr1, probe 912B sends command cmd2 to network address addr1, probe 912C sends command cmd1 to network address addr2, and probe 912D sends command cmd2 to network address addr2. More probes may be used, as indicated by the ellipsis.

[0167] In accordance with the above discussion, if the command launcher 910 receives i commands and j addresses, then i×j probes may be used. Alternatively, some commands may be associated with their own address list, and thus the probes for each of these commands may be used only for their associated addresses.

[0168] Additionally, each probe may be accompanied by or associated with a sensor (not shown in FIG. 9) configured to receive and analyze results of command execution or attempted execution and write these results to a database table 914, which may be identical to and / or subsumes the role of database table 802.

[0169] VII. EXEMPLARY OPERATIONS Figure 10 is a flow chart illustrating an exemplary embodiment. The process illustrated by Figure 10 may be performed by a computing device, such as computing device 100, and / or a cluster of computing devices, such as server cluster 200. However, the process may also be performed by other types of devices or device subsystems. For example, the process may be performed by a compute instance of a remote network management platform, or a portable computer, such as a laptop or tablet device.

[0170] The embodiments of Figure 10 may be simplified by removing any one or more of the features shown therein. Additionally, these embodiments may be combined with features, aspects, and / or embodiments of any of the previous figures or described herein.

[0171] Block 1000 may include reading, by the discovery verification application, from persistent storage, a list of discovery commands, each associated with a list of network addresses, and a list of network addresses. Block 1002 may include, for each discovery command in the list of discovery commands, sending, by the discovery verification application, via one or more proxy servers, a discovery command to each network address in the list of network addresses, each associated with. Block 1004 may include receiving, by the discovery verification application, via one or more proxy servers, a discovery result respectively corresponding to each of the sent discovery commands, where the discovery result indicates either a success or failure of the discovery command. Block 1006 may include writing, by the discovery verification application, the discovery result to persistent storage.

[0172] In some embodiments, the discovery verification application is executed independently of discovery procedures scheduled to be executed by the system.

[0173] In some embodiments, the list of network addresses is specified as a common list of network addresses associated with each of the discovery commands.

[0174] In some embodiments, each of the discovery commands is one of a command line interface command, a simple network management protocol (SNMP) command, a command deliverable via a web-based interface, or a Windows Management Instrumentation (WMI) command.

[0175] In some embodiments, the discovery command and the network address are stored in a first database table in persistent storage, and the discovery results are stored in a second database table in persistent storage.

[0176] In some embodiments, each entry in the first database table includes an indication of a class of operating system on which the particular discovery command is to be executed, a type of particular discovery command that specifies the network protocol used to deliver the particular discovery command, one of the proxy servers to which the particular discovery command is to be sent, or authentication credentials to use with the particular discovery command.

[0177] In some embodiments, each entry of the discovery results in the second database table includes a specification of the particular discovery command that was executed, the network address to which the particular discovery command was sent, or the proxy server to which the particular discovery command was sent.

[0178] In some embodiments, the discovery verification application is configured to send discovery commands in successive batches, where each batch may include, for example, between 5 and 25 discovery command / network address pairs.

[0179] In some embodiments, the list of discovery commands has an ordering, and the discovery verification application is configured to send a discovery command for each associated network address according to the ordering. Alternatively, the list of discovery commands may be unordered and thus may be sent in any order.

[0180] In some embodiments, the indication of a successful discovery result includes output from execution of a particular discovery command on a computing device associated with a particular network address.

[0181] In some embodiments, the indication of failure in the discovery result specifies whether the particular discovery command failed due to a particular network address to which the particular discovery command was sent being unreachable, the particular discovery command not being supported by the computing device associated with the particular network address, a failure to authenticate credentials used by the particular discovery command to access the computing device, or a failure to authorize credentials when the computing device attempted to execute the particular discovery command.

[0182] (VIII. Conclusion) The present disclosure is not limited to the specific embodiments described in this application, which are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the scope thereof. In addition to those described herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to be included within the scope of the appended claims.

[0183] In the above detailed description, various features and operations of the disclosed systems, devices, and methods have been described with reference to the accompanying drawings. The exemplary embodiments described herein and in the drawings are not intended to be limiting. Other embodiments may be utilized and other changes may be made without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure as generally described herein and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a variety of different configurations.

[0184] With respect to any or all of the message flow diagrams, scenarios, and flowcharts in the figures and discussed herein, each step, block, and / or communication may represent the processing of information and / or the transmission of information according to the exemplary embodiments. Alternative embodiments are included within the scope of these exemplary embodiments. In these alternative embodiments, operations described as, for example, steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed in a different order than that shown or discussed, or may be performed substantially simultaneously or in the reverse order, depending on the functionality involved. Furthermore, more or fewer blocks and / or operations may be used with any of the message flow diagrams, scenarios, and flowcharts discussed herein, and these message flow diagrams, scenarios, and flowcharts may be combined with each other, either partially or in whole.

[0185] A step or block representing the processing of information may correspond to a circuit that can be configured to perform a particular logical function of a method or technique described herein. Alternatively or additionally, a step or block representing the processing of information may correspond to a module, segment, or portion of a program code (including associated data). The program code may include one or more instructions executable by a processor to perform a particular logical operation or action in a method or technique. The program code and / or associated data may be stored in any type of computer-readable medium, such as a storage device including a RAM, a disk drive, a solid-state drive, or another storage medium.

[0186] The computer readable medium may also include non-transitory computer readable media, such as a register memory or a processor cache, that store data for a short period of time. The non-transitory computer readable medium may further include a non-transitory computer readable medium that stores program code and / or data for a long period of time. Thus, the non-transitory computer readable medium may include a secondary or permanent long-term storage device, such as a ROM, an optical or magnetic disk, a solid-state drive, or a compact disk read-only memory (CD-ROM). The non-transitory computer readable medium may also be other volatile or non-volatile storage systems. The non-transitory computer readable medium may be considered, for example, a computer readable storage medium, or a tangible storage device.

[0187] Additionally, steps or blocks depicting one or more information transmissions may correspond to information transmissions between software and / or hardware modules in the same physical device, although other information transmissions may occur between software and / or hardware modules in different physical devices.

[0188] The particular arrangements shown in the figures should not be considered limiting. It should be understood that other embodiments may include more or fewer of each element shown in a given figure. Further, some of the illustrated elements may be combined or omitted. Additionally, example embodiments may include elements not shown in the figures.

[0189] While various aspects and embodiments are disclosed herein, other aspects and embodiments will be apparent to those of skill in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope being indicated by the appended claims. [Explanation of symbols]

[0190] 100 computing devices 102 processors 104 Memory 106 Network Interface 108 Input / Output Unit 110 System Bus 200 Server Cluster 202 Server Device 204 Data Storage 206 Router 208 Local Cluster Network 210 Communication Links 212 Network 300 Managed Networks 302 Client Device 304 Server Device 306 Router 308 Virtual Machines 310 Firewall 312 Proxy Server 320 Remote Network Management Platform 322 compute instances 340 Public Cloud Network 350 Internet< / credentials> < / address> < / address> < / credentials> < / address>

Claims

1. a persistent storage including a list of discovery commands, each of the discovery commands being associated with a list of network addresses, the discovery commands and the network addresses being stored in a first database table within the persistent storage; one or more processors; a discovery verification application, the discovery verification application, when executed by the one or more processors, performing, prior to a discovery procedure: reading from the persistent storage the list of discovery commands and the list of network addresses; for each discovery command in the list of discovery commands, sending the discovery command to each network address in the list of network addresses associated therewith via one or more proxy servers deployed external to the system; receiving, via the one or more proxy servers, a discovery result respectively corresponding to each of the transmitted discovery commands, the discovery result indicating either a success or a failure of the discovery command; writing said discovery results to said persistent storage, said discovery results being stored in a second database table in said persistent storage, said second database table being arranged according to a schema that includes, for each of said discovery results, a specification of a particular discovery command that was executed and a specification of either the success or failure of execution of said particular discovery command. The system is configured as follows.

2. The system of claim 1 , wherein the discovery verification application is executed independently of discovery procedures scheduled to be executed by the system.

3. The system of claim 1 , wherein the list of network addresses is specified as a common list of network addresses associated with each of the discovery commands.

4. 2. The system of claim 1, wherein each of the discovery commands is one of a command line interface command, a simple network management protocol (SNMP) command, a command deliverable via a web-based interface, or a Windows Management Instrumentation (WMI) command.

5. The system of claim 1 , wherein the discovery command and the network address are stored in a first database table in the persistent storage, and the discovery results are stored in a second database table in the persistent storage.

6. 6. The system of claim 5, wherein each entry in the first database table includes an indication of a class of operating system on which a particular discovery command is to be executed, a type of the particular discovery command that specifies a network protocol to be used to deliver the particular discovery command, one of the proxy servers to which the particular discovery command is to be sent, or authentication credentials for use with the particular discovery command.

7. 6. The system of claim 5, wherein each entry of the discovery results in the second database table includes a specification of a particular discovery command that was executed, the network address to which the particular discovery command was sent, or a proxy server to which the particular discovery command was sent.

8. The system of claim 5 , wherein the discovery verification application is configured to send the discovery commands in successive batches.

9. The system of claim 5 , wherein the list of discovery commands has an ordering, and the discovery verification application is configured to send the discovery commands to each associated network address according to the ordering.

10. The system of claim 1 , wherein the indication of a successful discovery result comprises output from execution of a particular discovery command on a computing device associated with a particular network address.

11. 2. The system of claim 1, wherein an indication of failure in the discovery result specifies whether the particular discovery command failed due to a particular network address to which the particular discovery command was sent being unreachable, the particular discovery command not being supported by a computing device associated with the particular network address, a failure to authenticate credentials used by the particular discovery command to access the computing device, or a failure to authorize the credentials when the computing device attempted to execute the particular discovery command.

12. A computer-implemented method for performing the operations of any one of claims 1 to 11.

13. 12. A non-transitory computer readable medium having stored thereon program instructions which, when executed by a computing system, cause the computer to perform the operations of any one of claims 1 to 11.

Images