Computationally efficient virtual table scans

Abstract

To provide techniques for centralizing configuration data and tracking changes of the data.SOLUTION: An embodiment may involve: receiving, at a web server application, a query specifying a file, a block number of a block of data within the file, and a block size, where the file includes entries representing differences between snapshots of configuration data; identifying, based on the block size, the block of data within the file; storing the block in a non-transitory memory that is accessible to the web server application; and, in response to the query, transmitting, by the web server application, a set of the entries within the block formatted for display in a list component of a graphical user interface.SELECTED DRAWING: Figure 13

Description

[Background technology]

[0001] Modern computer platforms have become large and complex, supporting hundreds or even thousands of software applications simultaneously, as well as facilitating more advanced services through software applications operating in conjunction with one another. As a result, these computer platforms may have anywhere from tens of thousands to millions of individually configurable parameters that control the operation of the platform, the software applications, and / or the services. These parameters are collectively referred to as configuration data. Summary of the Invention

[0002] In many practical scenarios, configuration data may change frequently. For example, agile or rapid software development procedures may update these parameters thousands of times per day across platforms. Some specific parameters may change multiple times per day or week as software applications and / or their respective uses evolve. Furthermore, configuration data may be stored in multiple locations within a computer platform or external to the platform, making locating or identifying specific parameters difficult and time-consuming.

[0003] As a result of the above, changes to configuration data are difficult to track and manage. As a result, configuration errors (e.g., one or more parameters having an incorrect value) are now believed to be a greater cause of system downtime, defects, and failures than software coding errors.

[0004] Embodiments herein overcome the above and other possible limitations in the state of the art by providing techniques for centralizing configuration data and tracking changes to this data. Each version of the configuration data may be referred to as a snapshot. Modifications to the configuration data may originate from change requests that specify the files, database entries, and / or other structures affected by each change. A timeline of changes may then be generated from the snapshots, and differences between parameters of the snapshots may be determined based on the change requests. Such differences may be displayed in a tree-like hierarchy that clearly shows additions, deletions, and modifications (edits) from one snapshot to another. Advantageously, configuration faults may be quickly identified and triaged without having to look up thousands of parameters in many places.

[0005] Many existing systems represent these changes by storing the parameters (or changes to the parameters) in rows of a database table. As mentioned above, a computing platform may represent thousands of changes in a single day. Thus, identifying changes between snapshots may involve writing thousands of such rows to a table and then reading these rows to display the changes to the user.

[0006] Such a process can have high latency, requiring on the order of 1 millisecond for each row written or read. Thus, manipulating and reviewing a large table of changes can take at least several seconds, and in some cases minutes. To avoid such user delays, embodiments herein can employ virtual tables. This technique allows portions of one or more files stored in a computer platform's file system to be accessed through the use of a database interface. Thus, changes can be written to and read from a file instead of a database table, which can be 10-100 times faster. Additionally, pagination of the output displayed to the user can be used to ensure that only a small portion of the changes in a file are displayed at one time. In combination, this technique reduces main memory usage and dramatically improves the response time of the computer platform in presenting this information to the user.

[0007] Thus, a first exemplary embodiment may include, in response to determining that the software service meets a degradation criterion, generating an alert indicative of the software service and a change request specifying that configuration data used by the software service has changed in a current snapshot of the configuration data. The first exemplary embodiment may also include determining a set of configuration changes between a current snapshot and a previous snapshot of the configuration data based on the change request. The first exemplary embodiment may also include providing a representation of the set of configuration changes indicative of one or more parameters that have changed in the current snapshot and one or more paths in a tree-based arrangement of the configuration data that lead to the one or more parameters that have changed in the current snapshot.

[0008] A second exemplary embodiment may include receiving a query at a web server application specifying a file, a number of blocks of data blocks in the file, and a block size, where the file includes entries that represent differences between snapshots of configuration data; identifying data blocks in the file based on the block size; storing the blocks in non-transitory memory accessible to the web server application; and, in response to the query, transmitting, by the web server application, a set of entries in the blocks formatted for display in a list component of a graphical user interface.

[0009] A third exemplary embodiment may include a non-transitory computer-readable medium having stored thereon program instructions that, when executed by a computer system, cause the computer system to perform the operations described in the first and / or second exemplary embodiments.

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

[0011] In the fifth exemplary embodiment, the system may comprise various means for performing the operations of the first and / or second exemplary embodiments, respectively.

[0012] 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, as well as other descriptions and figures set forth herein, are intended to illustrate embodiments by way of example only, and many variations are possible. For example, structural elements and process steps can be rearranged, combined, distributed, removed, or otherwise modified while remaining within the scope of the embodiments, as claimed. [Brief description of the drawings]

[0013] [Figure 1] FIG. 2 is a schematic diagram of a computing device according to an exemplary embodiment. [Diagram 2] FIG. 2 is a diagram of a server device cluster in accordance with an exemplary embodiment. [Diagram 3] FIG. 1 illustrates a remote network management architecture according to an exemplary embodiment. [Figure 4] FIG. 1 illustrates a communication environment including a remote network management architecture according to an exemplary embodiment. [Diagram 5] FIG. 2 illustrates another communication environment including a remote network management architecture according to an exemplary embodiment. [Figure 6A] FIG. 2 illustrates types of configuration data, how the configuration data is stored, and where the configuration data can be stored, according to an exemplary embodiment. [Figure 6B] FIG. 1 illustrates a simplified set of configuration data for a software service, according to an exemplary embodiment. [Figure 6C] FIG. 1 illustrates centralized storage of configuration data according to an exemplary embodiment. [Figure 7A] 1 is an illustration of a user interface displaying a list of snapshots according to an example embodiment. [Figure 7B] FIG. 13 illustrates a user interface for displaying an alert according to an exemplary embodiment. [Figure 7C]1 is an illustration of a user interface displaying a timeline of snapshots for a change request according to an example embodiment. [Figure 7D] FIG. 13 illustrates a user interface displaying changes to configuration data according to an exemplary embodiment. [Figure 7E] FIG. 11 illustrates a user interface displaying another change to the configuration data according to an exemplary embodiment. [Figure 7F] 11A-11C are diagrams illustrating user interfaces displaying alternative views of configuration data changes according to an exemplary embodiment. [Figure 8] 1 is a flow chart according to an exemplary embodiment. [Figure 9] FIG. 13 illustrates a partial difference comparison file according to an exemplary embodiment. [Figure 10] FIG. 13 is a message flow diagram for inputting data from a database or virtual table into a graphical user interface according to an exemplary embodiment. [Figure 11] FIG. 2 illustrates a virtual database driver for reading blocks from a file according to an exemplary embodiment. [Figure 12] FIG. 1 illustrates a web server backend with custom pagination controls according to an exemplary embodiment. [Figure 13] 1 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Exemplary methods, apparatus, and systems are described herein. It should be understood that the words "example" and "exemplary" are used herein 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 so stated. Thus, other embodiments can be utilized, and other changes can be made, without departing from the scope of the subject matter presented herein.

[0015] Accordingly, the exemplary embodiments described herein are not meant to be limiting in any way. It will be readily understood that the aspects of the present disclosure as described throughout this specification and illustrated in the drawings 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 implemented in many ways.

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

[0017] Additionally, any recitation of elements, blocks, or steps in the specification or claims is for purposes of clarity, and therefore such recitation should not be construed as requiring or implying adherence to a particular arrangement of those elements, blocks, or steps, or performance in a particular order.

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

[0019] To support a wide range of business 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 also be required to meet the unique requirements of the enterprise. Large enterprises often have dozens or even hundreds of these custom software applications. In contrast, the advantages provided by embodiments herein are not limited to large enterprises, but may be applicable to enterprises of any size or other types of organizations.

[0020] Many such software applications are developed by individual departments within a company. These range from simple spreadsheets to bespoke software tools and databases. However, the proliferation of disconnected, custom software applications has many drawbacks. This negatively impacts a company's ability to operate and grow its business, innovate, and meet regulatory requirements. Without a single system that integrates its subsystems and data, companies may find it difficult to integrate, streamline, and enhance their operations.

[0021] To efficiently generate custom applications, enterprises would 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 individuals to focus on developing high-value, unique functionality.

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

[0023] aPaaS systems may support the development and execution of Model-View-Controller (MVC) applications. MVC applications enable efficient code reuse and parallel development by separating the representation of information from the way that information is presented to the user by dividing each functionality into three interconnected parts (model, view, and controller). 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 may be structured differently from MVC, such as those that use unidirectional data flow.

[0024] An aPaaS system may support standardized application components, such as a standardized set of widgets for graphical user interface (GUI) 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.

[0025] aPaaS systems may support the ability to configure application behavior using metadata, allowing applications to quickly adapt their behavior to meet specific needs. Such an approach reduces development time and increases flexibility. Additionally, aPaaS systems may support GUI tools that make metadata creation and management easier, reducing metadata errors.

[0026] An aPaaS system may support well-defined interfaces between applications, allowing software developers to avoid unnecessary inter-application dependencies. To this end, an aPaaS system may implement a service layer where data such as persistent state information is stored.

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

[0028] The aPaaS system may support enterprise-level security. Additionally, because the aPaaS system may be hosted remotely, it should also utilize security procedures when interacting with enterprise systems or with third-party networks and services hosted outside the enterprise. For example, the aPaaS system may be configured to detect and identify common security threats by sharing data between parties such as enterprises.

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

[0030] As an example of an aPaaS development process, a software developer may be tasked with creating a new application using an aPaaS system. The developer may first specify a data model that specifies the types of data the application will use and the relationships between each. The developer then inputs (e.g., uploads) the data model via the aPaaS system's GUI. The aPaaS system automatically creates all of the corresponding database tables, fields, and relationships, which are accessible through an object-oriented services layer.

[0031] The aPaaS system can also build a fully functional application with a client-side interface and server-side CRUD logic. This generated application can serve as a basis for the user's further development. Developers do not need to spend a lot of time on the basic functionality of the application, which is convenient. Furthermore, the application can be web-based, so that it can be accessed from any internet-enabled client device. Alternatively or additionally, a local copy of the application can be accessed, for example, when internet service is not available.

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

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

[0034] Additionally, user interaction with GUI elements, such as buttons, menus, tabs, sliders, checkboxes, toggles, etc., may be referred to as "selecting," "activating," or "actuating," respectively. These terms may be used regardless of whether the interaction with the GUI element is through a keyboard, a pointing device, a touch screen, or another mechanism.

[0035] The aPaaS architecture is particularly effective when integrated with and used to manage an enterprise's network. The following embodiments describe the architecture and functional aspects of an exemplary aPaaS system, as well as respective features and advantages.

[0036] II. Exemplary Computing Device and Cloud-Based Computing Environment 1 is a simplified block diagram illustrating a computing device 100 showing some of the components that may be included on the computing device and configured to operate in accordance with embodiments herein. The 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 computing services to client devices), or some other type of computing platform. Some server devices may act as client devices at times to perform certain operations, and some client devices may incorporate server functionality.

[0037] 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 peripherals (e.g., removable storage, printers, etc.).

[0038] The processor 102 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a co-processor (e.g., a mathematical, graphics, or encryption co-processor), 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 to be executed, as well as a cache memory for temporarily storing recently used instructions and data.

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

[0040] The memory 104 may store program instructions and / or data on which the program instructions may operate. As an example, the memory 104 may store program instructions on a non-transitory computer-readable medium such that, upon execution by the processor 102, these instructions may perform any of the methods, processes, or operations disclosed herein or in the accompanying drawings.

[0041] As shown in FIG. 1, the memory 104 may include firmware 104A, kernel 104B, and / or applications 104C. The firmware 104A may be program code used to boot or start some or all of the computing device 100. The kernel 104B may be an operating system including modules for memory management, processor scheduling and management, input / output, and communication. The kernel 104B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, network interfaces, ports, and buses) of the computing device 100. The 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. The memory 104 may also store data used by these and other programs and applications.

[0042] The network interface 106 may be in the form of one or more wired interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet). The network interface 106 may also support communication over one or more non-Ethernet media, such as coaxial cable or power line, or wide area media, such as Synchronous Optical Networking (SONET) or Digital Subscriber Line (DSL) technologies. The network interface 106 may also be in the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), BLUETOOTH, Global Positioning System (GPS), or wide area 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 include multiple physical interfaces. For example, some embodiments of the computing device 100 may include Ethernet, BLUETOOTH, and Wifi interfaces.

[0043] The input / output unit 108 may facilitate user and peripheral interaction with 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 include one or more types of output devices, such as a screen, a monitor, a printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, the computing device 100 may communicate with other devices, for example, by using a Universal Serial Bus (USB) or a High Definition Multimedia Interface (HDMI) port interface.

[0044] In some embodiments, an aPaaS architecture may be supported by the deployment of one or more computing devices, such as computing device 100. The exact physical location, connectivity, and configuration of these computing devices may not be known and / or important to the client devices. Thus, the computing devices may be referred to as "cloud-based" devices that may be housed in a variety of remote data center locations.

[0045] Figure 2 illustrates a cloud-based server cluster 200 according to an example embodiment. In Figure 2, the operation 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 server cluster 200 may depend on the computing tasks and / or applications assigned to server cluster 200.

[0046] For example, server devices 202 may be configured to perform various computational tasks for computer device 100. Thus, computational tasks may be distributed to one or more server devices 202. To the extent that these computational tasks can 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." This nomenclature should be understood as an implication that one or more different server devices, data storage devices, and cluster routers may be involved in the operation of a server device.

[0047] Data storage 204 may be a data storage array including a drive array controller configured to manage read and write access to a set of hard disk drives and / or solid state drives. The drive array controller may also be configured, alone or in conjunction with server devices 202, to manage backup or redundant copies of data stored on data storage 204 to protect against drive failure or other types of failure that would prevent one or more server devices 202 from accessing units of data storage 204. Other types of memory besides drives may also be used.

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

[0049] The configuration of router 206 may also be based at least in part on the data communications requirements of server equipment 202 and data storage 204, the latency and throughput of local cluster network 208, the latency, throughput, and cost of communications 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.

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

[0051] Server device 202 may be configured to transmit data to and / or receive data from data storage 204. The transmission and retrieval may be in the form of SQL queries or other types of database queries and the output of such queries. Similarly, text, images, video, and / or audio may additionally be included. Additionally, server device 202 may organize the received data as a representation of a web page or web application. Such a representation may be in the form of a markup language such as HTML, Extensible Markup Language (XML), or some other standardized or proprietary format. Additionally, server device 202 may be capable of executing various types of computerized scripting languages, including, but not limited to, Perl, Python, PHP 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 as well as client device 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.

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

[0053] A. Managed Network Managed network 300 may be, for example, an enterprise network used by an entity for computing and communication tasks as well as storage of data. To this end, 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 may be embodied by computing devices 100, server devices 304 may be embodied by computing devices 100 or server clusters 200, and routers 306 may be any type of router, switch, or gateway.

[0054] The virtual machine 308 may be embodied by one or more of the computer device 100 and the server cluster 200. In general, a virtual machine is an emulation of a computer system that mimics the functionality (e.g., processor, memory, and communication resources) of a physical computer. A single physical computer 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 the 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 computer systems include VMWARE® and MICROSOFT®.

[0055] Firewall 310 may be one or more dedicated routers or server devices that protect managed network 300 from unauthorized attempts to access internal devices, applications, and services while allowing legitimate communications originating 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 virtual private network (VPN) gateways for communicating with a remote network management platform 320 (see below).

[0056] 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.

[0057] In some cases, the proxy servers 312 may also enable the remote network management platform 320 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.

[0058] A firewall such as firewall 310 typically denies all communication sessions coming in via Internet 350 unless such sessions ultimately originate behind the firewall (i.e., a device on managed network 300) and the firewall is explicitly configured to support the sessions. Locating proxy server 312 behind firewall 310 (e.g., by being located within managed network 300 and protected by firewall 310) may allow proxy server 312 to initiate these communication sessions through firewall 310. This may mean that firewall 310 does not need to be specially configured to support incoming sessions from remote network management platform 320, thus avoiding a potential security risk to managed network 300.

[0059] In some cases, managed network 300 may consist of just a few devices and a few networks. In other deployments, 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 can be scaled up or down by orders of magnitude.

[0060] Furthermore, the number of proxy servers 312 deployed may vary 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, sets of two or more proxy servers may be assigned to such portions of the managed network 300 to provide load balancing, redundancy, and / or improved availability.

[0061] 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 be in the form of a web-based portal, for example using the web-based technologies mentioned above. This allows users to securely access the remote network management platform 320, for example from the client device 302 or potentially from a client device outside the managed network 300. The web-based portal allows users to design, test, and deploy applications, generate reports, review analytics, and perform other tasks. The remote network management platform 320 may also be referred to as a multi-application platform.

[0062] 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 nodes running a dedicated copy of the aPaaS software and / or one or more database nodes. Flexible placement of servers and databases on physical server equipment and / or virtual machines may be allowed and may change based on the needs of the enterprise. In combination, these nodes may provide a set of web portals, services, and applications available to a particular enterprise (e.g., a fully functional aPaaS system). In some cases, a single enterprise may use multiple compute instances.

[0063] 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. A reason for providing multiple compute instances to a customer may be that the customer desires to independently develop, test, and deploy its applications and services. Thus, compute instance 322 may be dedicated to developing applications associated with 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. Computing instances may also be referred to as hosted instances, remote instances, customer instances, or some other designation. Any application deployed to a computing instance may be considered a scoped application in that access to the database within the computing instance may be restricted to specific elements therein (e.g., specific database table(s) or specific rows within one or more database tables).

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

[0065] The multi-instance architecture of the remote network management platform 320 provides several advantages as opposed to traditional multi-tenant architectures. In a multi-tenant architecture, data from different customers (e.g., enterprises) is mixed in a single database. The data of these customers is isolated from each other, but this isolation is enforced by the software that operates the single database. As a result, a security breach in the system affects all of the customers' data, creating additional risks, especially for government, healthcare, and / or financial regulated entities. Furthermore, any database operation that affects one customer may affect all customers that share the database. Thus, in the case of an outage due to a hardware or software error, the outage affects all such customers. Similarly, when a database is upgraded to meet the needs of one customer, the upgrade process makes it unavailable to all customers. Such maintenance windows are often long due to the size of the shared database.

[0066] In contrast, a multi-instance architecture provides each customer with its own database in a dedicated compute instance. This prevents intermingling of customer data and allows for independent management of each instance. For example, if one customer's instance goes down due to an error or upgrade, other compute instances are not affected. Maintenance downtime is limited because the database contains only one customer's data. In addition, the simpler design of a multi-instance architecture allows redundant copies of each customer database and instance to be deployed geographically diversely. This promotes high availability and allows the live version of a customer's instance to be moved when a failure is detected or maintenance is performed.

[0067] 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 computing instances, the central instance may include several application and database nodes distributed on several physical server devices or virtual machines. Such a central instance may act as a repository for the computing instances as well as a particular configuration of data that may be shared by at least some of the computing instances. For example, there may be definitions of common security threats that may occur on the computing instances, software packages commonly found on the computing instances, and / or an application store for applications that may be deployed on the computing instances. The computing instances may communicate with the central instance by well-defined interfaces to obtain this data.

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

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

[0070] C. Public Cloud Networks Public cloud network 340 may be remote server equipment (e.g., multiple server clusters, such as server cluster 200) available for outsourced computing, data storage, communication, and service hosting activities. These servers may be virtualized (i.e., virtual machines). Examples of public cloud network 340 include AMAZON WEB SERVICES® and MICROSOFT® AZURE®. Similar to remote network management platform 320, multiple server clusters supporting public cloud network 340 may be deployed in diverse geographic locations for load balancing, redundancy, and / or high availability purposes.

[0071] The managed network 300 may use one or more public cloud networks 340 to deploy applications and services to its clients and customers. For example, if the managed network 300 provides an online music streaming service, the public cloud network 340 may store the music files and provide a web interface and streaming capabilities. In this way, the businesses in the managed network 300 do not need to build and maintain their own servers for these operations.

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

[0073] D. Communications Support and Other Operations Internet 350 may represent a portion of the global Internet, although Internet 350 may alternatively represent different types of networks, such as private wide-area or local-area packet-switched networks.

[0074] Figure 4 further illustrates the communication environment between managed network 300 and computing instances 322, introducing additional features and alternative embodiments. In Figure 4, all or a portion of computing instances 322 are replicated in both data centers 400A and 400B. These data centers may be geographically separate from one another, perhaps in different cities or different countries. Each data center includes managed network 300 as well as supporting facilities that facilitate communication with remote users.

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

[0076] Data center 400B may have its own versions of the components of data center 400A, such that 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, computing instances 322 may exist simultaneously in data centers 400A and 400B, with real-time or near real-time database replication and / or other operations.

[0077] Data centers 400A and 400B as shown in Figure 4 may 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 for managed network 300 while the versions of computing 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 be supported.

[0078] If data center 400A experiences some kind of failure or becomes unavailable to users, 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 computing 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), computing instance 322 is made accessible to users by data center 400B.

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

[0080] 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 state, serial number, last updated time, etc. The class of a configuration item may determine the subset of attributes that exist for the configuration item (e.g., software and hardware configuration items may have different attribute lists).

[0081] As mentioned above, VPN gateway 412 may provide a dedicated VPN to 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 of managed network 300 and / or compute instance 322 that communicates directly through the VPN may be assigned a public IP address. Other devices of managed network 300 and / or compute instance 322 may be assigned a private IP address (e.g., an IP address 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 managed network 300, such as proxy server 312, may communicate directly with one or more data centers using a secure protocol (eg, TLS).

[0082] IV. Exemplary Detection To manage the devices, applications, and services of the managed network 300, the remote network management platform 320 may initially determine the devices present in the managed network 300, their configurations, components, and operational states, and the applications and services they provide. The remote network management platform 320 may also determine relationships between the discovered devices, their respective components, applications, and services. Representations of each device, component, application, and service may be referred to as configuration items. 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. Representations of the configuration items and relationships are stored in the CMDB.

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

[0084] 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 advanced functionality provided by one or more applications running on one or more devices acting 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.

[0085] 5 is a logical depiction of how configuration items and relationships may be discovered, as well as how information associated with them may be stored. For simplicity, the remote network management platform 320, the public cloud network 340, and the Internet 350 are not shown.

[0086] 5, the CMDB 500, task list 502, and identification and reconciliation engine (IRE) 514 are located and / or operated within a compute instance 322. The task list 502 represents 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 not only the queue itself, but also any associated processing, such as adding, deleting, and / or manipulating information in the queue.

[0087] Once detection has occurred, the computing instance 322 may store detection 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 a task in the task list 502 may trigger or cause the proxy server 312 to initiate the respective detection operation. For example, the proxy server 312 may poll the task list 502 periodically or ad-hoc, or may otherwise notify the proxy server 312 of the detection command in the task list 502. Alternatively or additionally, detection may be manually or automatically triggered based on a trigger event (e.g., detection may be automatically initiated once a day at a particular time).

[0088] Nevertheless, the computing instance 322 may send these detection 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 therein and execute this task until the task list 502 is exhausted or another stop condition is reached. In response to receiving the detection command, the proxy server 312 may query various devices, components, applications, and / or services in the managed network 300 (represented in FIG. 5 as devices 504, 506, 508, 510, and 512 for simplicity). These devices, components, applications, and / or services may provide responses to the proxy server 312 regarding their respective configurations, operations, and / or status. In response, the proxy server 312 may then provide this detection information to the task list 502 (i.e., the task list 502 may have a send queue to hold the detection commands until requested by the proxy server 312 and a receive queue to hold the detection information until it is retrieved).

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

[0090] In this manner, the configuration items stored in CMDB 500 represent the environment of managed network 300. By way of 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 on them (e.g., web servers, email servers, databases, or storage arrays), as well as services that include multiple individual configuration items. Relationships may be pairwise definitions of placements or dependencies between configuration items.

[0091] To allow such detection, the proxy server 312, the CMDB 500, and / or one or more credential stores may be populated with credentials for the devices to be detected. The credentials may include any type of information required to access the devices. These 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 these credentials so that the credentials can be used to log on to or access the devices to be detected.

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

[0093] A.Horizontal detection Horizontal discovery is used to scan the managed network 300, discover devices, components, and / or applications, and then populate the CMDB 500 with configuration items that represent those devices, components, and / or applications. Horizontal discovery also generates relationships between configuration items. For example, there 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. Horizontal discovery is typically not service aware and does not generate relationships between configuration items based on the services they run on.

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

[0095] Patterns are also scripts that collect and process data on one or more devices to update 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 more general probes and sensors often cannot reliably discover (or at all). In particular, patterns can specify a set of actions that dictate how to discover a particular deployment of devices, components, and / or applications, what credentials to use, and which CMDB tables to populate with configuration items as a result of this verification.

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

[0097] During the scanning phase, proxy server 312 may determine the general type of device and its operating system by probing each IP address within a specified range of IP addresses for open Transmission Control Protocol (TCP) and / or User Datagram Protocol (UDP) ports. The presence of such open ports at an IP address indicates that a particular application is running on the device to which the IP address is assigned, thereby allowing the operating system used by the device to be identified. For example, if TCP port 135 is open, the device is likely running the 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 otherwise identifiable through the Simple Network Management Protocol (SNMP). Other possibilities exist.

[0098] During the classification phase, the proxy server 312 may further probe each detected 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 access information from the particular device. For example, if TCP port 22 is open, the proxy server 312 may be instructed to open a Secure Shell (SSH) connection to the particular device and retrieve information from a particular location in the file system about the particular type of operating system on the device. Based on this information, the operating system may be determined. As an example, a UNIX® device with an open TCP port 22 may be classified as AIX®, HPUX, LINUX®, MACOS®, or SOLARIS®. This classification information may be stored in the CMDB 500 as one or more configuration items.

[0099] During the identification phase, the proxy server 312 may determine specific 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 10 specific probes may be used. As with the classification phase, an appropriate set of tasks may be placed in the task list 502 for execution by the proxy server 312. These tasks enable the proxy server 312 to retrieve information from the particular device, such as basic input / output system (BIOS) information, serial numbers, network interface information, media access control addresses assigned to those network interfaces, IP addresses used by the particular device, etc. This identification information may be stored in the CMDB 500 as one or more configuration items along with any associated relationships between them. At this time, by passing the identification information through the IRE 514, it is possible to avoid the generation of duplicate configuration items for the purpose of eliminating ambiguity and / or to determine the table in the CMDB 500 into which the detected information should be written.

[0100] During the discovery phase, the proxy server 312 may determine further details regarding the operational status 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 phase. 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 retrieve additional information from the particular device, such as processor information, memory information, a list of running processes (software applications), etc. Here again, the detection information may be stored in the CMDB 500 as one or more configuration items and relationships.

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

[0102] Patterns are used only in the identification and search phases. In pattern-based detection, the scan and classification phases work as if probes and sensors were used. After the classification phase is complete, a pattern probe is designated as the probe to use for identification. The pattern probe and the pattern it designates are then activated.

[0103] 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, using pattern-based discovery, it is much easier to achieve discovery of equipment, components, and / or applications in public cloud networks, as well as tracking of configuration files. Additionally, these patterns are more easily customizable by users than probes and sensors. Also, because patterns are more focused on specific equipment, components, and / or applications, they can execute faster than the more general approaches used by probes and sensors.

[0104] 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, the operating system versions, hardware configurations, and network configuration details of the client devices, server devices, and routers in managed network 300, as well as the applications running thereon, may be stored as configuration items. This collected information may be presented to a user in various ways to allow the user to ascertain the hardware configuration and operational status of the devices.

[0105] Further, the CMDB 500 may include entries regarding relationships between configuration items. More specifically, it is assumed that a server device includes many hardware components (e.g., a processor, a memory, a network interface, a storage, and a file system) on which multiple software applications are installed or executed. 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., an "runs" relationship) may be so represented in the CMDB 500.

[0106] More generally, relationships between software configuration items installed or executed on hardware configuration items may take various forms, such as hosting, executing, or depending. Thus, a database application installed on a server device may have a "hosting" relationship with the server device to indicate that the database application is hosted on the server device. In some embodiments, a server device may have a "using" mutual relationship with a database application to indicate that the server device is used by the database application. While these relationships may be discovered automatically using the discovery procedures described above, it is also possible to configure the relationships manually.

[0107] In this manner, the remote network management platform 320 can discover and inventory the hardware and software deployed and provisioned on the managed network 300 .

[0108] B. Vertical detection Vertical discovery is a technique used to discover and map configuration items that are part of an overall 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 for the web service. Typically, horizontal discovery is performed first to find configuration items and the basic relationships between them, and then vertical discovery is performed to establish the relationships between the configuration items that make up the service.

[0109] Patterns can be used to discover specific types of services because they can be programmed to look for specific configurations of hardware and software that match a description of how the service is deployed. Alternatively or additionally, traffic analysis (e.g., studying network traffic between devices) can be used to facilitate vertical discovery. In some cases, service parameters can be manually configured to aid in vertical discovery.

[0110] Generally, vertical discovery attempts to find certain kinds of relationships between devices, components, and / or applications. Some of these relationships can be inferred from configuration files. For example, a configuration file for a web server application may indicate 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, if there is a large amount of web traffic (e.g., TCP port 80 or 8080) between a load balancer and a device hosting a web server, it is likely that the load balancer and the web server have some kind of relationship.

[0111] The 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 a different hardware device configuration item. The email service may have a "dependency" relationship with these software configuration items, while the software configuration items have a "use" interrelationship with the email service. Such services may not be fully determined by a horizontal discovery procedure, and instead vertical discovery and possibly some degree of manual configuration may be relied upon.

[0112] C. Advantages of Detection Regardless of how it is obtained, discovery information can be beneficial to the operation of a managed network. Among other things, IT personnel can quickly determine where specific software applications are deployed and the configuration items that make up the service. This allows for quick identification of the root cause of a service outage or degradation. For example, if two different services have slow response times, a CMDB query can determine (among other possible actions) that the root cause is high processor utilization in a database application used by both services. IT personnel can then address the database application without wasting time considering the health and performance of other configuration items that make up the service.

[0113] In another example, a database application is running on a server device and is used by a payroll service as well as an employee training service. Therefore, if the server device is taken down for maintenance, the employee training service and the payroll service will obviously be affected. Similarly, dependencies and relationships between configuration items could represent the services that will be affected if a particular hardware device fails.

[0114] Typically, the configuration items and / or relationships between the configuration items may be displayed and represented as a hierarchy in a web-based interface through which modification of such configuration items and / or relationships in the CMDB may be accomplished.

[0115] Additionally, users of managed network 300 can develop workflows that allow for the execution of specific coordinated actions across multiple discovered devices. For example, an IT workflow could allow a user to change a common administrator password for all discovered LINUX devices in a single operation.

[0116] V. CMDB Identification Rules and Reconciliation A CMDB such as CMDB 500 provides a repository of configuration items and relationships. If properly provisioned, it can play a key role in higher level applications deployed within or including the computing instances. These applications may relate to an enterprise's IT service management, operations management, asset management, configuration management, regulatory compliance, etc.

[0117] For example, an IT service management application may use information in the CMDB to determine which applications and services may be affected by a malfunction, outage, or a highly loaded component (e.g., server equipment). Similarly, an asset management application may use information in the CMDB to determine the hardware and / or software components used to support a particular enterprise application. As a result of the importance of the CMDB, it is desirable for the information stored therein to be accurate, consistent, and up-to-date.

[0118] Population of the CMDB can occur in a variety of ways. As mentioned above, a discovery procedure may automatically populate the CMDB with information including configuration items and relationships. However, the CMDB may also be populated in whole or in part by manual entry, configuration files, and third-party data sources. Given that multiple data sources may be able to update the CMDB at any time, one data source may overwrite an entry in another data source. Also, two data sources may each generate slightly different entries for the same configuration item, resulting in the CMDB containing duplicate data. If any of these occur, the health and usefulness of the CMDB may be reduced.

[0119] 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 the IRE 514. The IRE 514 may then use a set of configurable identification rules to uniquely identify the configuration item and determine if and how to write it to the CMDB.

[0120] 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 higher priority rules being considered before lower priority rules. Rules may also be considered independent in that they identify configuration items independent of other configuration items, or dependent in that they first use metadata rules to identify dependent configuration items.

[0121] Metadata rules describe other configuration items contained in a particular configuration item or the hosts to which a particular configuration item is deployed. For example, a network directory service configuration item may contain a domain controller configuration item, while a web server application configuration item may be hosted on a server appliance configuration item.

[0122] 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 not expected to change during the lifetime of the configuration item. Possible attributes for an example server device include serial number, location, operating system, operating system version, memory capacity, etc. If a rule specifies attributes that do not uniquely identify a configuration item, multiple components may be represented in the CMDB as the same configuration item. Also, if a rule specifies attributes that change for a particular configuration item, duplicate configuration items may be created.

[0123] Thus, when a data source provides information about a configuration item to IRE 514, IRE 514 may attempt to match this 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 retained for separate analysis.

[0124] A configuration item reconciliation procedure may be used to ensure that only authoritative data sources are allowed to overwrite configuration item data in the CMDB. Again, this reconciliation may be rule-based. For example, reconciliation rules may specify that a particular data source is authoritative for a particular configuration item type and set of attributes. The IRE 514 may then only allow the authoritative data sources to write to a particular configuration item, preventing unauthorized data sources from writing to it. In this way, the legitimate data source is the single source of truth for a particular configuration item. In some cases, an unauthorized data source may be allowed to write to a configuration item if it is generating the configuration item or if the attributes it is writing to are empty.

[0125] Also, multiple data sources may be authoritative for the same configuration item or its attributes. For clarity, these data sources may be assigned priorities that are taken into account when writing to the configuration item. For example, a second most authoritative data source may be able to write to a configuration item attribute until the first most authoritative data source writes to this attribute. After that, the second most authoritative data source may be prevented from further writing to the attribute.

[0126] In some cases, duplicate configuration items may be automatically detected by the IRE 514 or otherwise detected, and these may be cleared or flagged for manual de-duplication.

[0127] VI. Determining Changes to Configuration Data As mentioned above, a remote network management platform (such as remote network management platform 320) can support a vast number of software applications and services, each of which may have its own configuration data, but which may also reside by default in one or more files or database entries within the platform or outside the platform.

[0128] The configuration data may consist of sets of parameters, which may be key-value pairs, one or more values, files, or any other type of content. For purposes of discussion herein, we will assume that the parameters are in the form of key-value pairs, although other parameter forms may be employed. An example of a key-value pair is "IP Address: 10.0.177.15" where the key is the text "IP Address" and the value is the IP Address "10.0.177.15". The key-value pairs may be stored in various types of structured or unstructured text files, database tables, etc.

[0129] A. Placement of setting data FIG. 6A illustrates an example of the types of configuration data as well as how and where they are stored. Application / service settings 600 may include configuration data for a particular software application and / or service. These may be one or more of usernames and passwords, encryption settings, application programming interface (API) keys, or connections to databases. Middleware settings 602 may include configuration data for features built into the remote network management platform that may be employed by the software application and / or service. These may be one or more of database settings, message queue settings, content delivery network (CDN) settings, and / or heap sizes. Cloud-based resource settings 604 may include configuration data regarding one or more public cloud network services used by the software application and / or service. These may be one or more of storage settings, scaling rules (e.g., processing, storage, and network capacity, etc.), geographic regions in which cloud-based resources are located, and / or hostnames associated with those resources. Infrastructure settings 606 may include configuration data directed to the operation of computer equipment within the remote network management platform. These may be one or more of server equipment settings, network settings, firewall settings, etc. For example, these settings may include IP address assignments, domain name assignments, workgroup assignments, and so on.

[0130] All this configuration data may be stored in different ways, distributed across a remote network management platform, one or more public cloud networks, and / or other locations. For example, some of this configuration data may be stored in files 608, which may include unstructured text, structured text, or other types of files (e.g., .properties, .conf, XML, JavaScript Object Notation (JSON), Comma Separated Values ​​(CSV), and / or Yet Another Markup Language (YAML) files). Alternatively or additionally, some of this configuration data (parameters and / or files) may be stored in a repository 610, which may include a database (e.g., a particular database table), a network folder, a source code control system, and / or artifact storage.

[0131] In some cases, configuration data may be stored in a hierarchical tree-like structure. For example, JSON and XML files are hierarchically structured to directly resemble a tree. In these types of files, objects are either elements (e.g., key-value pairs, such as the leaves of a tree) or containers for other objects (e.g., blocks of elements, such as the root node or intermediate nodes of a tree).

[0132] As a concrete example, an airline ticket booking website may contain many nodes of application and service configuration data, such as a custom ticket booking application, a user relationship management component, a payment gateway service, a user interface, a set of web servers serving content to the user interface, authentication microservices, database servers, load balancers, internal network routing policies, etc., all of which must be configured properly to seamlessly combine and operate as an airline ticket booking application service. Thus, the configuration data of a software service may span thousands of nodes storing tens of thousands of configuration key-value pairs in a tree-like hierarchy. A simplified exemplary set of JSON configurations for such a software service is shown in Figure 6B.

[0133] The challenge in maintaining such configuration data is not only that the data is complex (tens of thousands to millions of parameters), but also that it changes frequently. For example, a remote network management platform may support hundreds or thousands of software applications and services, some of which may be under continuous development processes, such as various kinds of agile programming models. Thus, new versions of these applications may be deployed to production environments every few days, or even several times a day.

[0134] While the teams of software engineers developing and testing these applications may change the configuration data of their applications, they may also change the configuration data of other applications, as well as middleware and / or infrastructure. Thus, to fix a software defect or deploy multiple features, one team of software engineers may change configuration data that affects some or all of the other teams' software applications. Such changes may cause at least some of these other software applications to behave differently or to fail in various ways.

[0135] Furthermore, each set of configuration data may be located in files 608 and / or repositories 610 distributed throughout many locations, making access to the configuration data less restrictive and making changes difficult, if not impossible, to orchestrate, resulting in changes that are uncontrollable, untraceable, and not easily auditable.

[0136] As a result, the leading root cause of software application and service outages today is errors in configuration data. By some estimates, these errors are far more common and impactful than coding errors in software applications. Some notable configuration-related outages have taken entire websites offline or unavailable for hours or days. Due to the aforementioned limitations, troubleshooting these outages is difficult, as narrowing down the possible configuration change that caused the outage can be like searching for a needle in a haystack across multiple files and repositories.

[0137] Therefore, improvements in how configuration data is managed, presented, displayed, and manipulated so that outages are less likely to occur and are quicker to resolve would be beneficial.

[0138] Embodiments herein provide such improvements. As shown in FIG. 6C, these embodiments may include consolidating configuration data into a centralized configuration data model 612 that may be stored in a single location. This facilitates centralized visibility of configuration data (so that software and operations engineers do not have to spend significant amounts of time just locating relevant files or repositories). This also facilitates rule-based access control, with sets of access control lists (ACLs) or other mechanisms defining which users can make what changes to specific parameters at what time. This further facilitates continuous validation, where an automated process scans the configuration data to identify possible errors, misconfigurations, or inconsistent parameter groups. Such validation may be based on rules that define valid and / or invalid parameters or parameter combinations, or may be based on more complex logic.

[0139] One or more such ACLs may also control visibility of nodes, keys, or values ​​on a per-user or per-user group basis. As a result, some users may be unable to see particular branches of the tree or observe particular mask values ​​(such as passwords), while still being aware that mask values ​​have been added, edited, deleted, or remain unchanged.

[0140] As mentioned above, a snapshot represents a version of the configuration data. In some cases, a snapshot may represent the entirety of the configuration data, while in other cases, a snapshot may represent only a subset of the configuration data (e.g., the portion of the configuration data used by one or more particular software applications).

[0141] As an example, a particular software application may include configuration data parameters that determine which search engine is employed in response to a user's search request. It may be desirable to support multiple search engines and allow the software application to use or switch between any of them.

[0142] In a possible embodiment, the parameters may be updated to include the new search engine. For example, parameters specifying the Google search engine may include the following key-value pairs: "googleSearch:invalid", "googleSearchURL:www.google.com", and "googleRefIdNumber:grefID123113".

[0143] First, a change request may be made requesting the addition of the new search engine. This change request may be user or application initiated and may be added to a database of change requests stored by the remote network management platform. Based on this change request, a software developer may add new parameters to a configuration file of the software application. A new version of the software application may then be built whose configuration file incorporates these parameters as well as any changes to the software application's code that facilitate the use of the new search engine. This package (e.g., the new version of the application and its configuration data) may then be subjected to an automated testing procedure. Such testing may ensure that the configuration file is syntactically correct and properly formatted.

[0144] Assuming these tests pass, the configuration file may be uploaded to the centralized configuration data model 612. A snapshot of the configuration file is constructed, which is the current version of the configuration file, and after going through a validation process is made public (available) through a web interface of the centralized configuration data model 612.

[0145] Once the snapshots are available, a change control process is performed to review and either approve or reject the change request (and associated snapshots). The change control process may include manual or automated review by the software developer. For example, the results of the validation process may be reviewed to ensure validation was successful. If the change request is approved, the package can be deployed to an environment (e.g., by an end user of a remote network management platform in a production environment, by a software tester in a test environment, or by a software developer in a development environment).

[0146] B. Exemplary Graphical User Interface For purposes of further explanation, Figure 7A shows a list 700 of available snapshots of configuration data organized by environment, where "prod" indicates production, "test" indicates testing, and "dev" indicates development. This list may be obtained via a web interface of a remote network management platform, such as the web interface of the centralized configuration data model 612.

[0147] Assume now that snapshot prod-v8.dpl 702 is a new snapshot with the addition of parameters specifying the Google search engine. Among other things, the web interface specifies whether each snapshot is published, the deployable environment, whether it has been verified, and the timestamps of its creation and last verification. As shown, prod-v8.dpl 702 is the latest production snapshot.

[0148] Continuing with this scenario, assume that the package associated with snapshot prod-v8.dpl 702 is deployed in a production environment. The environment may be configured to generate alerts when various types of problems or potential problems are detected. For example, the environment may generate an alert if no searches have been performed for the past 15 minutes (such an event is expected to be very rare given that thousands of users are expected to be using the search service).

[0149] As a result, the remote network management platform may generate an alert. This alert may be sent to one or more system reliability engineers responsible for maintaining the correct operation of the platform and its applications and services. As an example, FIG. 7B shows a web interface 710 of an alert management application of the remote network management platform. It shows alert 0010223 with an identified problem 712 ("No searches processed in the last 15 minutes"), an affected configuration item 714 ("Search engine service-production"), and a possible root cause 716 (associated with change request CHG0030040). Assume now that change request CHG0030040 was (i) to modify a configuration file to include the Google search engine and (ii) associated with the affected configuration item 714.

[0150] In many practical scenarios, there may be multiple change requests listed under possible root causes 716. Furthermore, the content of these change requests may not reveal the parameters of the configuration data that were changed. Thus, the root cause analysis process may require a system reliability engineer to manually review each change request, and then collaborate with the software developers to first identify the relevant configuration snapshots, identify the changes between these snapshots, and determine whether these changes led to the apparent service outage. In all but the simplest of situations, this process is complex and may take hours or days.

[0151] The embodiments herein overcome the above-mentioned shortcomings due to the association between change requests and snapshots. In particular, change request CHG0030040 evolves snapshot prod-v8.dpl 702. Thus, new configuration parameters introduced in snapshot prod-v8.dpl 702 can be quickly and easily identified.

[0152] In this regard, Figure 7C illustrates a user interface 720 showing a snapshot deployment timeline 722 in which multiple snapshots are shown, each of which may be selectable. Figure 7C illustrates that a reference snapshot 724 (representing the most recent predeployed snapshot) and a target snapshot 726 (representing the current deployed snapshot prod-v8.dpl 702) have been selected. In general, the range of time shown in the timeline 722 may be expanded or contracted, and any one or two snapshots thereon may be selected. Additionally, the web interface may automatically display the final deployed snapshots (e.g., 2, 3, 5, or 10 snapshots).

[0153] 7D displays the difference between two selected snapshots, e.g., reference snapshot 724 and target snapshot 726. In this figure, user interface 730 may be part of user interface 720 (e.g., reached by scrolling down from user interface 720) or a separate user interface.

[0154] Nevertheless, pane 732 displays a tree-based arrangement of the changes between these snapshots, with each node being selectable. By selecting such a node, pane 734 can display any changes between the two snapshots in or under that node. For example, in pane 732, node "Prod" is selected. Thus, pane 734 shows all the changes under that node. These changes are labeled with the path through the tree to the node where the change resides. For example, the path displayed as " / Prod / release-1.0 / searchService-V1.0 / javaConfig / json / settings" indicates that there are three changes between the two snapshots, and that these changes appear in the settings node (i.e., the settings file that was edited to add the Google search engine).

[0155] Pane 734 shows, in table format, for each changed parameter, the associated action 736 (e.g., added, edited, deleted, unchanged), the parameter's key (name) 738, its value from the base snapshot 740, and its value from the target snapshot 742. If neither the base nor target snapshot contains a parameter, the associated entry may be blank. For example, in FIG. 7D , three parameters were added to the target snapshot, so they are not shown in the base snapshot.

[0156] As shown, pane 734 uses a graphical user interface list component to display rows of actions, parameter keys (names), and parameter values, although other types of user interface components may be used to display such information.

[0157] From this user interface, a system reliability engineer or software developer can easily identify parameters that have changed between related snapshots. This significantly reduces the amount of searching required by such an individual to locate the root cause of an outage. Finding the difference between the contents of two files is not particularly difficult. The difficult part of root cause analysis is identifying the two files to compare. In embodiments herein, such a process requires only seconds to minutes to execute, instead of hours to days.

[0158] In this regard, the additional parameter "googleSearch" has a value of "disabled" in Figure 7D. This indicates that the Google search engine is not enabled in the production environment, explaining why the alert was generated. Software developers can allow the use of the Google search engine by creating and deploying a new snapshot with the parameter "googleSearch" having the value "enabled".

[0159] For example, Figure 7E illustrates user interface 750, which is a variation of user interface 730. However, user interface 750 includes multiple parameter changes to multiple nodes in a tree-based arrangement. Furthermore, these changes include adding, deleting, and editing of both parameters and nodes. User interfaces 730 and 750 may also support the ability to display parameters that have not been changed. This may be useful when a parameter change is expected but for some reason was not made. Additionally, these user interfaces may support searching and sorting of the displayed parameters.

[0160] FIG. 7F shows another optional user interface 760 that is an alternative view of the changes made to the parameters. Instead of the traditional view of the differences between the files shown in two side-by-side text boxes, here each parameter name (key) is shown along with its previous and new values ​​(if necessary). Thus, for example, FIG. 7F shows that the key "com.glide.csp.self_script_src_svg" has a value of "true" in the reference snapshot and a value of "false" in the target snapshot. Conversely, the value of the key "com.glide.decision.table.max_inputs" has not changed between the snapshots since only one value is shown. Additionally, the added, removed, and edited parameters may be highlighted in various ways (e.g., with special fonts, colors, or associated text or icons) to draw the user's attention.

[0161] This view may be superior to traditional side-by-side text boxes because most of the changes here are values, not keys, so while a user has difficulty identifying changes in side-by-side text boxes, it is easy in this layout.

[0162] C. Exemplary Operations Figure 8 is a flow chart illustrating one exemplary embodiment. The process illustrated by Figure 8 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 computing instance of a remote network management platform or a portable computer, such as a laptop or tablet device.

[0163] The embodiments of Figure 8 may be simplified by removing any one or more of the features shown therein. Additionally, these embodiments may be combined with any of the other features or features, aspects, and / or implementations described herein.

[0164] Block 800 may include, in response to determining that the software service meets the degradation criterion, generating an alert indicative of the software service and a change request specifying that configuration data used by the software service has changed in the current snapshot of the configuration data.

[0165] Block 802 may include determining a set of configuration changes between the current snapshot and the previous snapshot of the configuration data based on the change request.

[0166] Block 804 may include providing a representation of the set of configuration changes indicating one or more parameters that were changed in the current snapshot and one or more paths in a tree-based arrangement of the configuration data that lead to the one or more parameters that were changed in the current snapshot.

[0167] In some embodiments, determining the set of configuration changes between the current snapshot and the predecessor snapshot of the configuration data is in response to receiving a selection of the current snapshot and the predecessor snapshot.

[0168] In some embodiments, the software service is supported by one or more software applications, and the one or more parameters that are changed in the current snapshot of the configuration data are used by the one or more software applications.

[0169] In some embodiments, determining that the software service meets the degradation criterion includes detecting one or more of an outage affecting the software service, a degradation in performance of the software service, or processor or memory utilization above a threshold.

[0170] In some embodiments, the alert is one of a plurality of alerts stored in an alert database and associated with a detected technical issue affecting one or more of a plurality of software services.

[0171] Some embodiments may further include providing, via a graphical user interface to the client device, a representation of the alert specifying the software service and the change request.

[0172] In some embodiments, determining the set of configuration changes includes providing an adjustable timeline of multiple snapshots including a current snapshot and an earlier snapshot of the configuration data to the client device, receiving another selection of the current snapshot and the earlier snapshot from the client device, and determining one or more parameters that have changed between the earlier snapshot and the current snapshot.

[0173] In some embodiments, each of the one or more parameters that have been changed in the current snapshot of the configuration data is represented as a key-value pair that includes a key that uniquely identifies each parameter and the value of each parameter.

[0174] In some embodiments, one or more parameters that have been changed in the current snapshot of the configuration data are marked as newly added to the configuration data, deleted from the configuration data, or edited in the configuration data, respectively.

[0175] In some embodiments, the representation of the set of configuration changes also indicates additional parameters that are unchanged in the current snapshot of the configuration data.

[0176] In some embodiments, a current snapshot of configuration data is deployed in a production environment and the predecessor snapshot is a snapshot of configuration data that was most recently deployed in the production environment prior to the deployment of the current snapshot.

[0177] VII. Using Virtual Tables with Pagination to Display Configuration Data Changes Using the centralized configuration data model 612, changes to configuration data are tracked and stored in a manner similar to source control management systems such as Git, Subversion (SVN), Version Control Systems (CVS), and Team Foundation Server (TFS). For example, the centralized configuration data model 612 tracks changes, the users involved in each change, and the ability to reconstruct the state of the configuration data before and after such changes. However, embodiments herein include managing and presenting such changes in new ways that are specific to the configuration data.

[0178] Changes are tracked for debugging, tracking, and auditing purposes. Versions of configuration data can be imported from files, but also from changes made as part of a change request process. These configuration data changes can be in the form of a set of changes involving the configuration trees of one or more software services and / or deployable modules that may be used by such services.

[0179] The changes involved are incorporated into a centralized configuration data model 612. The centralized configuration data model 612 may be stored, for example, in a relational database, with each element of the configuration data represented as a row in a database table that represents a node in a tree-like structure of the configuration data. A node references its corresponding change set (i.e., the change set that caused the node's creation) and may be reached (addressed) by a unique path of nodes from the root to this node. In particular, a new release of configuration data may reference a particular source control change set that can be used to determine a valid snapshot of the configuration data for that release.

[0180] These change sets involve additions to the configuration data. They are therefore non-destructive, as the added, edited or removed entries become new instances of the node, replacing the previous version of the node in the tree-like structure. However, they do not change the previous version of the node, so history is preserved. For example, a node that was removed from the configuration data by a change set still exists and can be observed as a removed node. From the nodes of this tree-like structure (removed and non-removed nodes), snapshots of the configuration data at various points in time can be generated. Releasing these snapshots allows the current snapshot to be applied to the configuration items of a software service.

[0181] Additionally, a snapshot of configuration data at a point in time or for a particular change involvement can be reconstructed for audit and / or review. To reconstruct a snapshot at a particular point in time and determine the valid configuration data tree-like structure nodes for that snapshot, the change involvement in the tree-like structure is identified and the valid version of the tree node at that point in time is determined.

[0182] As discussed above, changes to configuration data may result in degradation of a software service or a failure of the software service. An alert may be generated by monitoring software on the platform, such as abnormally high processor utilization and / or abnormally slow response times. The alert may identify the affected configuration item being monitored, the associated software service, and / or other components associated with the configuration item. From the alert, a current configuration snapshot may be inferred, since the configuration data in the snapshot includes the configuration item identified by the alert. From the current snapshot, a history of configuration changes and a valid snapshot of configuration changes committed and deployed may be reconstructed, as a timeline of configuration snapshots used to identify configuration changes that caused degradation of the software service.

[0183] Visualizing the differences between two versions of code is a feature of source control systems and can be text-based, line-by-line or character-by-character. In contrast, a difference between two versions of configuration data, A and B, involves identifying node differences between the tree-like structures of two snapshots, A and B. These changes can then be categorized as additions (node ​​path not present in A but present in B), deletions (node ​​path not present in B but present in A), edits (node ​​path present in A and B but with different values ​​in B), or unchanged (same node path and value present in A and B).

[0184] This differs from a normal source control code comparison due to the tree-like structure background. Nodes in the configuration data tree-like structure may span multiple lines of text, and not all lines of text representing a node may have text-based differences. In fact, some lines of text in two snapshots may be identical and still belong to nodes that were changed. Source control systems such as Git may only use line-based and text-based comparisons to identify differences, highlighting lines of text that were added and removed. Additionally, source control systems may consider lines to be unchanged even if they are part of a node that was changed. A visual diff in a source control system shows lines of text that were added and removed between two versions of a code file, and omits lines that were unchanged.

[0185] The differences between snapshots of configuration data depend on the context of the nodes in the configuration data. For example, a parent node may not have changed, but its children may have changed. As a result, the parent node has a difference category of edits.

[0186] An unchanged difference category also provides more information than the source control system. For example, if a node's difference category is unchanged, none of its child nodes have changed. Thus, in a tree-like structure, the context of a node's location in the tree and the difference categories of its sibling, descendant, and ancestor nodes provide additional insight into identifying the configuration data change that caused the alert. When attempting to apply a text-line comparison of source control code, this context is lost and line changes may even be attributed to the wrong node.

[0187] A differential comparison can be performed by a configuration data management software application and calculated between two snapshots of the configuration data of the configuration item associated with the alert. These snapshots can contain tens of thousands of nodes in two tree-like hierarchies. The differential is a merged tree structure that includes all nodes in both snapshots. If a node exists in both snapshots as determined by the path, it is considered to be the same node in the merged tree. For such a node, a differential comparison of each key-value pair is also performed, which results in one of the four states (added, deleted, edited, unchanged) for that node as described above.

[0188] A. Storing differential comparisons A differential comparison can be performed by loading two or more snapshots into main memory and then determining the node-by-node differences between these snapshots. However, the results are temporary and are usually specific to only one user (the one requesting the differential comparison) and his / her access permissions (each user only sees the part of the tree that he / she has access to). These results may not even be relevant for the duration of the entire user session, since the user may change the selection of snapshots for comparison.

[0189] Moreover, the results may amount to tens of thousands of nodes. For this reason, storing these results in a database table is prohibitive, as database reads and writes would be relatively slow and computationally expensive. Displaying these results in a user interface in a responsive manner (e.g., in less than 1-2 seconds) is not possible given the volume of data. Furthermore, the transient nature of delta comparisons makes employing persistent storage in a database table wasteful, as these tens of thousands of results would be purposeless and would need to be purged from the database once the user is finished viewing them.

[0190] Thus, storing large amounts of short-term results in database tables reduces performance and efficiency. This is further compounded in high availability database configurations where all database operations are replicated to a secondary database. Such large amounts of data insertion and deletion in a short period of time can cause replication to back up and ultimately jeopardize the stability of the replication process. In some cases, this can jeopardize the stability of the compute instance since most or all software applications running on the platform rely on the database being accessible and the replication procedures available. For example, if a software application is blocked by large and continuous database insert or delete operations, other operations required to keep the compute instance running smoothly and healthily can be affected, causing a degradation of service for the entire instance.

[0191] Thus, storage of the delta comparisons is transient, but persistent, so that a user can retrieve the same results again and apply filtering, searching, and / or sorting in any manner desired to isolate and identify changes that may be the root cause of the alert. Although database tables facilitate filtering, searching, and sorting, as discussed above, the use of database tables is computationally prohibitive.

[0192] To overcome these and possibly other limitations, the integrated differential snapshots can be serialized into files in the file system of the compute instance. File system I / O is typically several times faster than storing large data collections in database tables. Furthermore, typical text compression of multi-megabyte text files can result in a 70-80% size reduction. Such compression and storage (e.g., to a solid-state drive) can take a total of about 10 milliseconds, but deletion is nearly instantaneous.

[0193] The difference comparison is done by pairing snapshot nodes with their paths, so that the resulting merged file format is grouped by tree path, with entries containing a key and a value (including the values ​​from both snapshots, as well as an indicator of one of the four types of difference the node represents). To further reduce file size, nodes with edited differences may contain two values ​​per key-value pair, one from each snapshot, while deleted, added, and unchanged nodes only contain a single value per key-value pair.

[0194] An example of this is shown in partial difference comparison file 900 in Figure 9. Each leaf node in file 900 represents a key-value pair and is annotated with a comment (the text after " / / ") indicating the type of change, if any. Leaf nodes 902 and 904 contain two values ​​since they represent edits. Considering left to right, the first value is before the edit and the second value is after the edit. All other leaf nodes have only one value since they represent add, delete, or unchanged scenarios.

[0195] Nevertheless, the resulting file is stored in the file system and associated with a unique delta identifier (delta ID), allowing the file to be read and opened by its delta identifier.

[0196] B. Displaying difference comparisons in the user interface To investigate the cause of a software service degradation, a user may find it advantageous to view a snapshot of the configuration data deployed at the time the alert was generated (the current snapshot). With the support of the difference comparison operation described above, a user may compare this snapshot against a snapshot of the configuration data deployed at an earlier time when the software service did not experience degradation (the prior snapshot).

[0197] To observe the differences between the nodes of the current snapshot and the previous snapshot, a graphical user interface may be generated to display these differences. Also, information from the different comparison files may be presented in the graphical user interface in a table format having columns and rows. The columns may indicate one or more of the path of the node, the type of change the node indicates from the previous snapshot to the current snapshot, the key of the node's key-value pair, the previous value of the node's key-value pair (if applicable), and the new value of the node's key-value pair (if applicable). Also, the tabular graphical user interface may support filtering, searching, paging, and sorting of its rows based on the contents of its columns.

[0198] 7D shows one possible embodiment of such a tabular graphical user interface. Pane 734 displays the root path ( / Prod / release-1.0 / searchService-V1.0 / javaConfig.json / settings) of the three nodes (this path can also be inferred from the tree-like structure of the configuration data displayed in pane 732). For each node, the tabular format includes columns for action 736 (type of change), name 738 (key of the node's key-value pair), base snapshot value 740 (previous value of the node's key-value pair), and target snapshot value 742 (new value of the node's key-value pair). As mentioned above, pane 734 uses a list component to display this information.

[0199] A tabular graphical user interface with rows and columns is familiar to users, and a familiar graphical user interface with familiar navigation and data presentation increases the efficiency of a user tasked with identifying the root cause of an alert. For example, if an alert details a request timeout on an infrastructure configuration item that is part of a software service, the user can first examine the configuration data and changes to that node and its child nodes by examining the subtree of configuration data that includes that software service and filtering the results. A familiar tabular graphical user interface with familiar selections allows the user to perform this analysis more quickly and easily, allowing them to inspect the differential comparison results.

[0200] C. Virtual Table A tabular graphical user interface is typically populated with data stored in a database table. However, for reasons discussed above, it is undesirable to place the differential comparison data in a database. Thus, to serve a tabular graphical user interface in an efficient manner that avoids the latency associated with storing differential comparisons in a database, a virtual table configuration can be used to configure the display and response of files stored in a file system as if the information in the files were in a database table.

[0201] Traditionally, a list component of a graphical user interface for displaying entries from a database table can make API calls to a back-end web service of a web server. These API calls can specify the table name, the columns of the table that are requested to be displayed, a sort order, a limit on the number of entries to be returned, a page number, and possibly a filter based on the values ​​to be displayed in one or more columns. The back-end web service can call another software layer, such as an object-relational mapper (ORM), to generate a database query (e.g., SQL) against the database table. This query can then be sent through the web server's database driver.

[0202] The database driver may be another software layer that handles low-level communication between the web server and the database server. It may thus create a connection to the database server, provide a query in a format that the database server recognizes, receive results provided by the database server over the network, and then return these results to the ORM layer. The web server then formats the results according to a list component of a graphical user interface and displays them in the list component. These layers work together through standards, defined communication protocols, and software interfaces that allow each layer to interoperate with other layers that implement these same interfaces, protocols, and standards.

[0203] An ORM may support multiple types of databases by employing more than one database driver. For example, there may be one database driver for MySQL databases and another for Postgres databases. Each database driver may use a specific communication protocol and query format tuned for that type of database. Meanwhile, the web server's graphical user interface module does not know how the web service got its results, the web service does not know how the ORM layer got its results, and the ORM does not know how the database driver got its results. What is important for each of these modules is that they can communicate and interoperate with the other modules according to a prescribed interface.

[0204] If the data is stored in a table that is not a traditional database table, then there is no database to handle queries involving that table. On the other hand, the web service can still accept queries from a list component in a graphical user interface and call the ORM to return the results to the web service. Instead of providing the query to a database driver, the ORM may recognize that the table name being queried is not a database table and instead call an alternative layer of software that implements the driver for virtual tables in non-transient volatile memory such as RAM.

[0205] Such an arrangement is shown in Figure 10. A client device graphical user interface 1002 is in communication with a web server 1004. When the client device is provided with a list component showing input of data from a database 1006 (e.g., a MySQL database) or a virtual table 1008, the client device may make a corresponding query to the web server 1004. Notably, the client device and the web server 1004 may be separate and distinct computing devices communicating over a network such as the Internet. Furthermore, the database 1006 may be a separate and distinct computing device communicating with the web server 1004 over a network. The virtual table 1008 may be stored in the RAM of the web server 1004 or in the RAM of a yet separate and distinct computing device. There are other possibilities. As mentioned above, the client device graphical user interface 1002 and possibly parts of the web server 1004 may not be aware that they are ultimately querying a virtual table instead of an actual database table.

[0206] Steps 1010-1024 show how a query for data from database 1006 and its corresponding response flow through the modules of web server 1004. In step 1010, client device graphical user interface 1002 may send a database query to backend web service 1004A. In step 1012, backend web service 1004A may identify the query as related to a database and provide it to ORM 1004B. In step 1014, ORM 1004B may identify the query as related to database 1006 and provide it to database driver 1004C. In step 1016, database driver 1004C may convert the query to a format compatible with database 1006 before sending it to database 1006. In step 1018, database 1006 may send a response to the query to database driver 1004C. In step 1020, the database driver 1004C may convert the response into a format compatible with the ORM 1004B before providing it to the ORM 1004B. In step 1022, the ORM 1004B may provide the response to the backend web service 1004A. In step 1024, the backend web service 1004A may provide the response to the client device graphical user interface 1002. Although not shown in FIG. 10, the client device graphical user interface 1002 may then use the response to populate a list component.

[0207] Steps 1026-1040 show how a query for data from the virtual table 1008 and its corresponding response flow through the modules of the web server 1004. In step 1026, the client device graphical user interface 1002 may send a virtual table query to the backend web service 1004A. In step 1028, the backend web service 1004A may identify the query as related to the virtual table and provide it to the ORM 1004B. In step 1030, the ORM 1004B may identify the query as related to the virtual table 1008 and provide it to the virtual database driver 1004D. In step 1032, the virtual database driver 1004D may convert the query to a format compatible with the virtual table 1008 before sending it to the virtual table 1008. In step 1034, the virtual table 1008 may send a response to the query to the virtual database driver 1004D. In step 1036, the virtual database driver 1004D may convert the response into a format compatible with the ORM 1004B before providing it to the ORM 1004B. In step 1038, the ORM 1004B may provide the response to the backend web service 1004A. In step 1040, the backend web service 1004A may provide the response to the client device graphical user interface 1002. Although not shown in FIG. 10, the client device graphical user interface 1002 may then use the response to populate a list component.

[0208] D. Block-Based Reading and User Interface Pagination As mentioned above, the virtual table 1008 may be stored in RAM. The capacity of RAM is typically several orders of magnitude smaller than persistent storage such as a hard drive or solid-state drive. The RAM may also be shared by other virtual tables, applications, processes, and operating systems running on a computer system such as the web server 1004. Thus, while a database may be maintained in persistent storage and grow to billions of entries, a virtual table in shared volatile memory has a much smaller amount of accessible memory and can only accommodate a limited number of entries (e.g., 1000 entries). Furthermore, the entry limit (e.g., 1000) may be enforced by the virtual table driver. Here, the entries of the virtual table correspond to nodes of the configuration data (e.g., nodes in a difference comparison of two snapshots) and may be displayed in the rows of a list component.

[0209] Given that a differential comparison of two snapshots of configuration data may have several times as many entries (e.g., tens of thousands) as can reasonably be stored in RAM, it is desirable to fetch a "block" of entries from the virtual table 1008 at a time and store these entries in RAM for at least a portion of the time they are displayed to the user. For example, suppose the entry limit is 1000, and the differential comparison stored in the file system contains 10,000 entries. In this case, there are 10 blocks, each containing 1000 entries. Thus, entries 0-999 constitute the first block (block 0), entries 1000-1999 constitute the second block (block 1), and so on. In various embodiments, a block number and / or another set of identifiers may be used to identify the desired block.

[0210] A custom block read mechanism may be used to facilitate displaying these entries in a client graphical user interface. To this end, new columns are added to the virtual table. Rows act as additional parameters to the software layer that generates the virtual table entries, rather than simply providing data read from the virtual table. These additional rows in the virtual table may include delta IDs, block numbers, number of entries per block, and possibly other information. The software layer may be configured to add filter conditions based on these additional rows. Such filter conditions may not be used to filter data returned by the virtual table, but may instead function as part of a query against the virtual table.

[0211] Here, the delta ID represents a delta comparison between two snapshots stored in one or more files in persistent storage. For example, there may be a one-to-one mapping between delta IDs and files, or a single delta ID may represent a large delta comparison across multiple files. In the latter case, a B-tree (binary tree) index is present in the header of the first file or in a separate file and is used to determine the correct file to serve the request. In other words, the B-tree will act as an index that identifies files and / or block regions within a file, and the resulting block may contain several entries from each of two or more files. Another possibility is multiple redundant files associated with the same delta ID in persistent storage, each arranged in a different internal structure or with a specific data scanning procedure, such as pre-grouped, pre-filtered, or pre-sorted results. This allows certain types of requests (e.g., specific grouping, filtering, or sorting of results) to be served more quickly.

[0212] These filter conditions allow a query provided by the ORM to identify a particular delta ID, a particular block number within that delta ID, and a particular block size of a block within that delta ID. With this information, the virtual database driver can locate the particular delta ID in persistent storage and return the appropriate number of entries after iterating through the delta IDs based on the particular block size until the beginning of the particular block is found. As an example, if the block size is 1000 entries and the query indicates that the second block is being requested, the virtual database driver can return entries 1000-1999 for the specified delta ID. Notably, the blocks retrieved are not always loaded contiguously from the same region of the file on the file system, as different requests for blocks may also include additional filter and / or sort conditions that modify how blocks are identified for the requests.

[0213] This scenario is illustrated in Figure 11. Assume MYFILE 1100 exists in a local or remote file system accessible to virtual database driver 1004D. In step 1102, virtual database driver 1004D receives a query specifying the delta ID of "MYFILE", block number 1, and block size 1000. The query originates, for example, from ORM 1004B. In some cases, the block size is not included in the query, as this may be a fixed setting for virtual database driver 1004D. In step 1104, virtual database driver 1004D locates MYFILE in the file system (local or remote) and uses the block number and block size to identify and retrieve entries 1000-1999 that make up block 1 (the second block) of MYFILE. If filters and / or sorts are applied to one or more "columns" of the entries (e.g., node path, action, name, previous value, current value), the data in the file is filtered and / or sorted accordingly prior to identifying the entries. Virtual database driver 1004D receives these entries in step 1106. Virtual database driver 1004D provides these entries in response to queries in step 1108.

[0214] In these embodiments, the interfaces of the list component, backend web services, and ORM do not differ significantly from queries against traditional database tables. Keeping these interfaces unchanged promotes backward compatibility while reducing the risk of introducing defects.

[0215] Furthermore, for user convenience and system performance, user interface components (such as list components) typically do not display an unlimited number of entries at one time. For example, a list component may paginate the entries so that only a small, fixed number (e.g., 10, 25, 50, 100, etc.) are displayed at one time in the client device graphical user interface. Thus, if the block size is 1000, the list component may display any one of 10 pages of 100 entries each.

[0216] In various embodiments, pagination interacts with a loaded block when there are more entries in the block than can be loaded. If such additional entries exist in the delta ID, then up to 1000 entries (for example) of the block may be reloaded / replaced to handle the next graphical user interface request to paginate beyond the first 10 of the 100 pages. In practice, blocks may be reloaded into the virtual table memory for each stateful transaction (but not multiple requests from one or more users intermixed at the same time) and / or as required by the graphical user interface request. Even if there is a limit of 1000 entries per block, the pagination control can independently know that there are more entries, such as 10,000, and will not limit the graphical user interface page options to only the first 10 of the 100 pages. Thus, selecting page 11 will result in a different block being reloaded into the virtual table memory. The virtual table driver may also understand that the graphical user interface is currently only displaying 100 entries in the list (request block size) and load only the 100 entries required for that graphical user interface's transaction rather than continuing to fill memory up to the maximum memory limit of 1000 entries.

[0217] A custom pagination control, in some embodiments, can avoid reading the total count of entries through the normal channels of the backend web service 1004A / ORM 1004B / virtual database driver 1004D. Instead, the custom pagination control may query another web service (e.g., a pagination backend service) that generates a total count of entries for the current list filter, calculates the page count, and keeps track of the current page the user is viewing.

[0218] The pagination service may receive as input a delta ID, various filters and filter values ​​currently active in the list component, and / or a list page size currently being used in the list component. These inputs are updated whenever any of them change in the graphical user interface, and another pagination service is invoked. In return, the pagination control provides the currently selected page to the list component for querying the list backend, and resets to page 1 if the input changes. The pagination service may determine the file from the delta ID and apply the filter. The pagination service may then obtain a total filtered count of entries by invoking iteration count rather than loading the entries into a virtual table memory. The pagination service then divides the total count of entries by the list page size input, rounding up, and returns the total count (with any filters applied) and this rounded up page count.

[0219] An example is shown in Figure 12. The client graphical user interface 1200 displays the difference comparison information in the list component. This information is retrieved by the list backend service 1004A-1, the ORM 1004B, and the virtual database driver 1004D of the web server 1004. As shown, the virtual database driver 1004D retrieves the blocks of the relevant difference IDs (files) from the file system 1202 into main memory. There is also a parallel channel through which the list component communicates with the pagination backend service 1004A-2. The pagination backend service 1004A-2 determines the page count and / or the current page number from the blocks currently in main memory and / or the blocks of the difference IDs (files) stored in the file system 1202, and displays or highlights it in the client graphical user interface 1200.

[0220] E. Exemplary Operations Figure 13 is a flow chart illustrating one exemplary embodiment. The process illustrated by Figure 13 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 computing instance of a remote network management platform or a portable computer, such as a laptop or tablet device.

[0221] The embodiments of Figure 13 may be simplified by removing any one or more of the features shown therein. Additionally, these embodiments may be combined with any of the other features or features, aspects, and / or implementations described herein.

[0222] Block 1300 may include receiving a query at a web server application specifying a file, a block number of data blocks in the file, and a block size, where the file includes entries representing differences between snapshots of configuration data.

[0223] Block 1302 may include identifying data blocks within the file based on the block size.

[0224] Block 1304 may include storing the block in non-transitory memory accessible to the web server application.

[0225] Block 1306 may include transmitting, in response to the query, by a web server application, the set of entries in a block formatted for display in a list component of a graphical user interface.

[0226] In some embodiments, the file is one of one or more files that contain the entries.

[0227] In some embodiments, identifying a block of data within a file includes iterating through the file until the block is located based on a block size.

[0228] In some embodiments, the query also specifies a filter to be applied to the entries. These embodiments may further include applying the filter to the entries before iterating through the file. In practice, the filter is applied but may be lazily evaluated as part of the iteration loop. This is to avoid the need to always iterate through the entire file and filter to the end of the file, for example if the block limit is reached the first time during a previous iteration that filters the entire file. This process may also involve reading an entry, testing its filter, keeping or discarding the entry, and then iterating over the next entry. At this granularity, the filter is applied before each iteration step, but not all filtering is completed before the iteration begins. This is in contrast to sorting, where all sorting must be completed before the iteration begins, or where the iteration is performed on unsorted entries.

[0229] In some embodiments, the query also specifies a sorting operation to be applied to the entries. These embodiments may further include applying the sorting operation to the entries before iterating through the file.

[0230] In some embodiments, the set of entries contains one or more entries. In some cases, it is possible to return an empty set if the filter excludes all possible entries, or if the snapshot is an empty tree and the comparison produces an empty file.

[0231] In some embodiments, the files are designated by a unique identifier that is associated with the difference between two particular snapshots of the configuration data.

[0232] In some embodiments, the list component displays a set of entries in a table format with pagination buttons to load and display other sets of entries in a block.

[0233] These embodiments may further include receiving, at the web server application, another query to load another set of entries into the list component, determining that the another set of entries includes entries in another block of the file, identifying another block in the file based on the block size, storing the another block in non-transitory memory, and transmitting, by the web server application, in response to the another query, the entries in the another block formatted for display in the list component.

[0234] In some embodiments, storing the other block in the non-transitory memory includes replacing the block with the other block.

[0235] In some embodiments, each entry is associated with a configurable setting in the configuration data and includes a path, an action, a name, and one or both of the setting's previous value from a previous one of the snapshots and the setting's current value from a current one of the snapshots.

[0236] In some embodiments, submitting a set of entries in a block formatted for display in a list component includes, for each entry, filling in a row of the list component, each path, each action, each name, and one or both of a previous value and a current value.

[0237] In some embodiments, a particular one of the entries includes a particular action that indicates that a configurable setting has been added, the previous value is null, and the current value is not null.

[0238] In some embodiments, a particular one of the entries includes a particular action that indicates that the configurable setting has been deleted, the previous value is not null, and the current value is null.

[0239] In some embodiments, a particular one of the entries includes a particular action that indicates that the configurable setting has been edited, the previous value is not null, and the current value is not null.

[0240] In some embodiments, files are used instead of storing entries in a database structure.

[0241] In some embodiments, the non-transitory memory is a volatile main memory.

[0242] In some embodiments, the block size ranges from 100 to 5000 entries.

[0243] VIII. Conclusion The present disclosure is not limited in terms of the specific embodiments described herein, which are intended to illustrate various aspects. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope thereof. From the foregoing description, functionally equivalent methods and apparatuses within the scope of the present disclosure, in addition to those described herein, will be apparent to those skilled in the art. Such modifications and variations are also intended to fall within the scope of the appended claims.

[0244] In the above detailed description, various features and operations of the disclosed system, apparatus, and method are described with reference to the accompanying drawings. The exemplary embodiments described herein and in the drawings are not meant to be limiting in any way. 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 described throughout this specification and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations.

[0245] With respect to any or all of the message flow diagrams, scenarios, and flowcharts in the figures, each step, block, and / or communication may represent information processing and / or information transmission according to an exemplary embodiment, as discussed herein. The scope of these exemplary embodiments includes alternative embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and / or messages may be performed out of the order shown or described (including substantially simultaneously or in reverse order), depending on the functionality involved. Furthermore, any of the message flow diagrams, scenarios, and flowcharts discussed herein may use more or fewer blocks and / or operations, and some or all of these message flow diagrams, scenarios, and flowcharts may be combined with each other.

[0246] The steps or blocks representing the processing of information may correspond to circuitry that may be configured to perform certain logical functions of the methods or techniques described herein. Alternatively or additionally, the steps or blocks representing the processing of information may correspond to modules, segments, or portions of program code (including associated data). The program code may include one or more instructions executable by a processor to perform certain logical operations or actions in the methods or techniques. 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.

[0247] Computer readable media may also include non-transitory computer readable media, such as non-transitory computer readable media that store data for a short period of time, such as register memory and processor cache. Non-transitory computer readable media may further include non-transitory computer readable media that store program code and / or data for a long period of time. Thus, non-transitory computer readable media may include secondary or permanent long-term storage, such as, for example, ROM, optical or magnetic disks, solid-state drives, or compact disk read-only memories (CD-ROMs). Non-transitory computer readable media may also be any other volatile or non-volatile storage system. Non-transitory computer readable media may be considered, for example, computer readable storage media or tangible storage devices.

[0248] Furthermore, steps or blocks depicting one or more information transfers may correspond to information transfers between software and / or hardware modules in the same physical device, although other information transfers are possible between software and / or hardware modules in different physical devices.

[0249] The particular arrangement depicted in the figures should not be construed as limiting in any way. It is understood that other embodiments may show more or fewer elements in a given figure. Further, some of the depicted elements may be combined or omitted. Additionally, an example embodiment may include elements that are not shown in the figures.

[0250] Various aspects and embodiments are disclosed herein, and other aspects and embodiments will be apparent to those of ordinary skill in the art. The various aspects and embodiments disclosed herein are intended to be illustrative and not limiting, with the true scope being indicated by the following claims. [Explanation of symbols]

[0251] 101 Computer Equipment 102 processors 104 Memory 104A Firmware 104B Kernel 104C Application 106 Network Interface 108 Input / Output Unit 110 System Bus 200 Server Cluster 202 Server equipment 204 Data Storage 206 Router 208 Local Cluster Network 210 Communication Links 212 Network 300 Managed Networks 302 Client Device 304 Server Equipment 306 Router 308 Virtual Machines 310 Firewall 312 Proxy Server 320 Remote Network Management Platform 322 Computing Instances 324 Computing Instances 326 Computing Instances 328 Compute Instances 340 Public Cloud Network 350 Internet 400A Data Center 400B Data Center 402A VPN Gateway 402B VPN Gateway 404A Firewall 404B Firewall 406A load balancer 406B Load Balancer 410 Setting items 412 VPN Gateways 414 users 416 Remote User 500 CMDB 502 Task List 504 Equipment 506 Equipment 508 Equipment 510 Equipment 512 Equipment 514IRE 600 Application / Service Settings 602 Middleware Settings 604 Cloud-based resource configuration 606 Infrastructure Settings 608 Files 610 Repositories 612 Centralized Configuration Data Model 700 List 702 Snapshots 710 Web Interface 712 Identified Issues 714 Setting items 716 Root cause 720 User Interface 722 Snapshot Deployment Timeline 724 Reference Snapshots 726 Target Snapshots 730 User Interface 732 Pain 734 Pain 736 operation 738 Name 740 Baseline Snapshot Value 742 Target Snapshot Values 750 User Interface 760 User Interface 900 Partial Difference Comparison File 902 leaf nodes 904 Leaf Nodes 1002 Client device graphical user interface 1004 Web Server 1004A Backend Web Services 1004A-1 List Backend Service 1004A-2 Pagination backend service 1004B ORM 1004C Database Driver 1004D Virtual Database Driver 1006 Database 1008 Virtual Table 1010 Database Query 1012 Database Query 1014 Database Query 1016 Database Query 1018 Database Response 1020 Database Response 1022 Database Response 1024 Database Response 1026 Virtual Table Queries 1028 Virtual Table Queries 1030 Virtual Table Query 1032 Virtual Table Queries 1034 Virtual Table Response 1036 Virtual Table Response 1038 Virtual Table Response 1040 Virtual Table Response 1100 MYFILE 1200 Client Graphical User Interface 1202 File System

Claims

1. receiving a query at a web server application specifying a file, a block number and a block size of data blocks within the file, the file including entries representing differences between snapshots of configuration data; identifying the data blocks within the file based on the block size; storing the block in non-transitory memory accessible to the web server application; transmitting, in response to the query, by the web server application, a set of the entries in the block formatted for display in a list component of a graphical user interface; The method includes:

2. The method of claim 1 , wherein the file is one of one or more files containing the entry.

3. 2. The method of claim 1, wherein identifying the data block within the file comprises iterating through the file until the block is located based on the block size.

4. The query also specifies a filter to be applied to the entry; The method of claim 3 , further comprising applying the filter to the entries prior to iterating through the file.

5. the query also specifies a sort operation to be applied to the entries; The method of claim 3 , further comprising applying the sort operation to the entries prior to iterating through the file.

6. The method of claim 1 , wherein the set of the entries includes one or more of the entries.

7. The method of claim 1 , wherein the file is designated by a unique identifier associated with a difference between two particular snapshots of the configuration data.

8. The method of claim 1 , wherein the list component displays the set of entries in a table format with pagination buttons to load and display other sets of entries within the block.

9. receiving, at the web server application, another query to load another set of entries into the list component; determining that the other set of entries includes entries in another block of the file; identifying the other block within the file based on the block size; storing the other block in the non-transient memory; and transmitting, by the web server application, in response to the further query, the entries in the further block formatted for display in the list component; The method of claim 1 further comprising:

10. 10. The method of claim 9, wherein storing the other block in the non-transient memory comprises replacing the block with the other block.

11. 2. The method of claim 1 , wherein each of the entries is associated with a configurable setting in the configuration data and includes a path, an operation, a name, and one or both of a previous value of the configurable setting from a previous one of the snapshots and a current value of the configurable setting from a current one of the snapshots.

12. 12. The method of claim 11, wherein transmitting the set of entries in the block formatted for display in the list component includes, for each entry, populating a row of the list component with a respective path, a respective action, a respective name, and one or both of a respective predecessor value and a respective current value.

13. 12. The method of claim 11, wherein a particular one of the entries includes a particular action indicating that the configurable setting has been added, the previous value being null, and the current value being non-null.

14. 12. The method of claim 11, wherein a particular one of the entries includes a particular action indicating that the configurable setting has been deleted, the previous value is not null, and the current value is null.

15. 12. The method of claim 11, wherein a particular one of the entries includes a particular action indicating that the configurable setting has been edited, the previous value is not null, and the current value is not null.

16. The method of claim 1 , wherein the file is used instead of storing the entries in a database structure.

17. The method of claim 1 , wherein the non-transitory memory is a volatile main memory.

18. The method of claim 1 , wherein the block size is in the range of 100 to 5000 of the entries.

19. When executed by one or more processors of a computer system, receiving a query at a web server application specifying a file, a block number and a block size of data blocks within the file, the file including entries representing differences between snapshots of configuration data; identifying the data blocks within the file based on the block size; storing the block in non-transitory memory accessible to the web server application; transmitting, in response to the query, by the web server application, a set of the entries in the block formatted for display in a list component of a graphical user interface; A non-transitory computer-readable medium storing program instructions that cause the computer system to perform operations including:

20. 1. A computer system comprising: one or more processors; Memory, and, when stored in the memory and executed by the one or more processors, receiving a query at a web server application specifying a file, a block number and a block size of data blocks within the file, the file including entries representing differences between snapshots of configuration data; identifying the data blocks within the file based on the block size; storing the block in non-transitory memory accessible to the web server application; transmitting, in response to the query, by the web server application, a set of the entries in the block formatted for display in a list component of a graphical user interface; program instructions for causing the computer system to perform operations including: A computer system comprising:

Images