Patent Publication Number: US-10776104-B2

Title: Systems and methods for tracking configuration file changes

Description:
CROSS-REFERENCE TO RELATED APPLICATION(S) 
     This application is a continuation of U.S. Pat. No. 10,191,736, which issued on Jan. 29, 2019, which is herein incorporated by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The present disclosure relates in general to systems, methods, and apparatuses for tracking changes to configuration files used by configuration items and applications. 
     BACKGROUND 
     This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art. 
     Computer resources (e.g., configuration items) hosted in distributed computing (e.g., cloud-computing) environments may be disparately located with each having its own functions, properties, and/or permissions. Such resources may include hardware resources (e.g. computing devices, switches, etc.) and software resources (e.g. database applications). These resources may be provided and provisioned by one or more different providers with different settings or values. 
     However, files used by the configuration items may change overtime. For example, configuration files used by the configuration items (or their related applications) may change how a configuration item behaves in one or more situations. The discovered configuration items may include numerous devices or applications with numerous configuration files attached thereto. Furthermore, configuration files may be substantially voluminous in data that uses a substantial amount of time to review. It may be difficult to determine which files have changed or where changes have occurred to configuration files. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The description herein makes reference to the accompanying drawings, wherein like reference numerals refer to like parts throughout the several views. 
         FIG. 1  is a block diagram of a distributed computing system utilizing a cloud service and a configuration management databases (CMDB), in accordance with an embodiment; 
         FIG. 2  is a block diagram of a generalized computing device utilized in the distributed computing system of  FIG. 1 , in accordance with an embodiment; 
         FIG. 3  is a block diagram of an electronic computing and communication system that utilizes the CMDB of  FIG. 1 , in accordance with an embodiment; 
         FIG. 4  is a block diagram illustrating a process for tracking configuration files utilizing a discovery server, in accordance with an embodiment; 
         FIG. 5  is a block diagram illustrating a process within the discovery server of  FIG. 4  for tracking configuration files, in accordance with an embodiment; and 
         FIG. 6  shows a screen that may be used to access currently tracked file entries and/or create new configuration file tracking entries in a pattern designer for designing patterns for future discovery processes, in accordance with an embodiment; 
         FIG. 7  illustrates a tracked file definition box overlaid on the screen of  FIG. 6 , in accordance with an embodiment; 
         FIG. 8  illustrates a comparison screen comparing a first version of a configuration file to a second version of the configuration file, in accordance with an embodiment; 
         FIG. 9  illustrates a service mapping timeline used to track configuration files, in accordance with an embodiment; 
         FIG. 10  illustrates the service mapping timeline of  FIG. 9  at a later time illustrating a change in a configuration item, in accordance with an embodiment; 
         FIG. 11  illustrates a process that may be used to track configuration items, in accordance with an embodiment; and 
         FIG. 12  illustrates a process that may be used to track configuration items, in accordance with an embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers&#39; specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure. 
     Information Technology (IT) devices are increasingly important in an increasingly electronics-driven world in which various electronic devices are interconnected within a distributed context. As more and more functions are performed by services using some form of distributed computing, the complexity of IT network management increases. As these devices are separated geospatially, managing and tracking configuration of these devices may become more difficult. 
     In such an interconnected but distributed context, the configuration of each of these devices may be represented by configuration items (CIs) that detail certain configurations, parameters, components, software, or settings associated with a respective device. As will be discussed in greater detail below, CIs may include information related to a physical entity (e.g., hardware), a logical entity (e.g., version, instance of a database), a conceptual entity (e.g., service), and the like associated with a respective device. Given the wide variety of CIs associated with various devices within this type of complex IT environment, configuration item (CI) discovery executed on a given infrastructure is used to track the CIs of the devices that are present on the connected IT environment. That is, CI discovery is the process of finding configuration items, such as hardware, software, documentation, location, and other information related to the devices connected to a given network, such as an enterprise&#39;s network. This discovery process may be performed at least partially using automated routines, e.g., an application program, running on the network in question. When a CI is found by such routines, discovery includes exploring some or all of the CI&#39;s configuration, provisioning, and current status. This explored information is used to update one or more databases, such as a configuration management database (CMDB), accordingly. 
     The CMDB stores and tracks all of the discovered devices connected to the network. On computer systems, the discovery process may also identify software applications running on the discovered devices, and any connections, such as Transmission Control Protocol (TCP) connections between computer systems. Discovery may also be used to track all the relationships between computer systems, such as an application program running on one server that utilizes a database stored on another server. CI discovery may be performed at initial installation or instantiation of connections or new devices, and/or CI discovery may be scheduled to occur periodically to track additions, removals, or changes to the IT devices being managed, thereby keeping data stored on the CMDB. Thus, using the discovery process, an up-to-date map of devices and their infrastructural relationships may be maintained. 
     Large information technology (IT) networks may include a large number of resources, such as servers, applications, and/or other hardware devices. Each of these devices may have one or more corresponding configuration files that control how the asset functions. The configuration files may change overtime. However, due to the potentially large number of configuration files, it may be difficult and time-consuming to determine when the configuration files or even to determine which configuration files have changed and/or how they have changed. Thus, the cloud service may be used to track the configuration files by storing relevant information (e.g., content, last discovery of the file, etc.) in a configuration item entry in the CMDB. 
     By way of introduction,  FIG. 1  is a block diagram of a system  100  that utilizes distributed computing framework, which may perform one or more of the techniques described herein. As illustrated in  FIG. 1 , a client  102  communicates with a cloud service  104  over a communication channel  106 . The client  102  may include any suitable computing system. For instance, the client  102  may include one or more computing devices, such as a mobile phone, a tablet computer, a laptop computer, a notebook computer, a desktop computer, or any other suitable computing device or combination of computing devices. The client  102  may include client application programs running on the computing devices. The client  102  can be implemented using a single physical unit or a combination of physical units (e.g., distributed computing) running one or more client application programs. Furthermore, in some embodiments, a single physical unit (e.g., server) may run multiple client application programs simultaneously. 
     The cloud service  104  may include any suitable number of computing devices (e.g., computers) in one or more locations that are connected together communicate using one or more networks. For instance, the cloud service  104  may include various computers acting as servers in datacenters at one or more geographic locations where the computers are connected together using network and/or Internet connections. The communication channel  106  may include any suitable communication mechanism for electronic communication between the client  102  and the cloud service  104 . The communication channel  106  may incorporate local area networks (LANs), wide area networks (WANs), virtual private networks (VPNs), cellular networks (e.g., long term evolution networks), and/or other network types for transferring data between the client  102  and the cloud service  104 . For example, the communication channel  106  may include an Internet connection when the client  102  is not on a local network common with the cloud service  104 . Additionally or alternatively, the communication channel  106  may include network connection sections when the client and the cloud service  104  are on different networks or entirely using network connections when the client  102  and the cloud service  104  share a common network. Although only a single client  102  is shown connected to the cloud service  104 , it should be noted that cloud service  104  may connect to multiple clients (e.g., tens, hundreds, or thousands of clients). 
     Through the cloud service  104 , the client  102  may connect to various devices with various functionality, such as gateways, routers, load balancers, databases, application servers running application programs on one or more nodes, or other devices that may be accessed via the cloud service  104 . For example, the client  102  may connect to an application server  107  and/or a databases, such as the configuration management database (CMDB)  108 , via the cloud service  104 . The application server  107  may include any computing system, such as a desktop computer, laptop computer, server computer, and/or any other computing device capable of providing functionality from an application program to the client  102 . The application server  107  may include one or more application nodes running application programs whose functionality is provided to the client via the cloud service  104 . The application nodes may be implemented using processing threads, virtual machine instantiations, or other computing features of the application server  107 . Moreover, the application nodes may store, evaluate, or retrieve data from a database and/or a database server (e.g., the CMDB  108 ). 
     The CMDB  108  is a series of tables containing information about all of the assets and business services controlled by a client  102  and the configurations of these assets and services. The assets and services include configuration items (CIs)  110  that may be computers, other devices on a network  112  (or group of networks), software contracts and/or licenses, or business services. The CIs  110  include hardware resources, such as server computing devices, client computing devices, processors, memory, storage devices, networking devices, or power supplies; software resources, such as instructions executable by the hardware resources including application software or firmware; virtual resources, such as virtual machines or virtual storage devices; and/or storage constructs such as data files, data directories, or storage models. As such, the CIs  110  may include a combination of physical resources or virtual resources. For example, the illustrated embodiment of the CIs  110  includes printers  114 , routers/switches  116 , load balancers  118 , virtual systems  120 , storage devices  122 , and/or other connected devices  124 . The other connected devices  124  may include clusters of connected computing devices or functions such as data centers, computer rooms, databases, or other suitable devices. Additionally or alternatively, the connected devices  124  may include facility-controlling devices having aspects that are accessible via network communication, such as heating, ventilation, and air conditioning (HVAC) units, fuel tanks, power equipment, and/or the like. The CMDB  108  may include an index of CIs  110 , attributes (e.g., roles, characteristics of elements, etc.) associated with the CIs  110 , and/or relationships between the CIs  110 . Furthermore, the CMDB  108  may track which configuration files identified pertain to each CI  110 . 
     Additional to or in place of the CMDB  108 , the cloud service  104  may include one or more other database servers. The database servers are configured to store, manage, or otherwise provide data for delivering services to the client  102  over the communication channel  106 . The database server includes one or more databases (e.g., CMDB  108 ) that are accessible by the application server  107 , the client  102 , and/or other devices external to the databases. The databases may be implemented and/or managed using any suitable implementations, such as a relational database management system (RDBMS), an object database, an extensible markup language (XML) database, a configuration management database (CMDB), a management information base (MIB), one or more flat files, and/or or other suitable non-transient storage structures. In some embodiments, more than a single database server may be utilized. Furthermore, in some embodiments, the cloud service  104  may have access to one or more databases external to the cloud service  104  entirely. 
     In the depicted topology, access to the cloud service  104  is enabled via a management, instrumentation, and discovery (MID) server  126  via an External Communications Channel (ECC) Queue  128 . The MID server  126  may include an application program (e.g., Java application) that runs as a service (e.g., Windows service or UNIX daemon) that facilitates communication and movement of data between the cloud service  104  and external applications, data sources, and/or services. The MID server  126  may be executed using a computing device (e.g., server or computer) on the network  112  that communicates with the cloud service  104 . As such, in some embodiments, the MID server  126  may connect back to the cloud service  104  using a virtual private network connection that simulates the CIs  110  being connected to the cloud service  104  on a common physical network. 
     As discussed below, the MID server  126  may periodically and/or intermittently use discovery probes to determine information on devices connected to the network  112  and return the probe results back to the cloud service  104 . Probes may have different types and functions. For example, some probes get the names of devices of specific operating systems (e.g., Windows or Linux) while other exploration probes return disk information for those devices using the operating systems. Some probes run a post-processing script to filter the data that is sent back to the cloud service  104 . 
     As a non-limiting example, the probe types available for use by the MID server  126  may include a Common Information Model (CIM) probe that utilizes the CIM query language to query a CIM server using Web-Based Enterprise Management (WBEM) protocols, a Simple Network Manage Protocol (SNMP) probe to discover information about network device (e.g., routers), a Windows Management Instrumentation (WMI) Runner probe that uses the WMI to obtain information about a Windows-based device, a Powershell probe that executes Powershell scripts (e.g., Powershell V2 scripts) on a host for the MID server  126 , a Secure Copy (SCP) Relay Probe that copies a file or directory contents from one host to another via the MID server  126 , a Secure Shell (SSH)-based probe that executes a shell command on a target host and returns the output, a Shazzam probe that determines what devices are active using a targeted port scan, a user-defined probe class, a multi-probe that combines probe types, and/or any combination thereof. 
     In the illustrated embodiment, the MID server  126  is located inside the network  112  thereby alleviating the use of a firewall in communication between the CIs  110  and the MID server  126 . However, in some embodiments, a secure tunnel may be generated between a MID server  126  running in the cloud service  104  that communicates with a border gateway device of the network  112 . 
     The ECC queue  128  may be a database table that is typically queried, updated, and inserted into by other systems. Each record in the ECC queue  128  is a message from a instance in the cloud service  104  to a system (e.g., MID server  126 ) external to the cloud service  104  that connects to the cloud service  104  or a specific instance running in the cloud service  104  or a message to the instance from the external system. The fields of an ECC queue  128  record include various data about the external system or the message in the record. For example, the record may include an agent field, a topic field, a name field, a source field, a response to field, a queue field, a state field, a created time field, a processed time field, a sequence number for the message, an error string field, a payload field, and/or other suitable fields for identifying messages and/or the systems sending/receiving the message. The agent field identifies a name (e.g., mid.server.xxxx) of the external system that the message is directed to or originates from. The topic field is a value (e.g., arbitrary values) that indicates that a message pertains to a particular subject. For example, during discovery of CIs  110 , the topic field may be populated with a value to identify a name of the probe that has been/is going to be run. The name field provides more detail in a context indicated by the topic field. For example, in discovery, the name field may be a descriptive and human-readable name or a command to be run by the probe identified in the topic field. Alternatively, if the topic field contains “SSHCommand”, the name field may indicate the shell command to be run. 
     The source field indicates a target or recipient of the message outside of the cloud service  104 . In discovery, the source field may contain an Internet Protocol (IP) address that the discovery probe is to be/has been run against, or the field may include a human-readable description when the probe is to be/has been run against multiple IP addresses. 
     The response to field, when included, contains a reference (e.g., sys_id) to the ECC queue  128  that the message is a response to. In discovery, a discovery result may be a response to a discovery schedule message. 
     The queue field indicates whether the message is incoming to the cloud service  104  or outgoing from the cloud service  104 . The state field indicates whether the message is ready to be processed, is being processed, or has been processed. The recipient of the message generally updates this field. The time created field indicates when the record was first stored in the ECC queue  128 . The time processed field indicates when the record was updated to processed. 
     In some embodiments, the messages are sequenced using a sequencing field that includes a number assigned at generation of the record. The error string field, when included, indicates that an error occurred and/or a type of error that occurred. 
     The payload field is the body of the message. The contents of this field are specific to the context of the record and the system that is exchanging information with the cloud service  104 . For example, a result of a discovery probe uses Extensible Markup Language (XML) documents for the payload. For instance, in some embodiments, the returned XML document may have a root tag of &lt;results&gt; containing one or more &lt;result&gt; tags and a single &lt;parameters&gt; tag. The parameters are simply an echo of those sent to the MID server  126  in the probe. 
     The cloud service  104  may allocate resources to users or groups of users in a multi-tenant and/or a single-tenant architecture. Allocating resources in a multi-tenant architecture includes include installations or instantiations of one or more servers, such as application servers, database servers, or any other server, or combination of servers, that can be shared amongst a group of users. For example, a web server, such as a unitary Apache installation; an application server, such as a unitary Java Virtual Machine; and a single database server catalog, such as a unitary MySQL catalog, may handle requests from multiple users. In a multi-tenant architecture, the application server, the database server, or both may distinguish between and segregate data or other information of the various customers using the system. In summary, multi-tenant architecture provides a single instance of software and all of the supporting infrastructure of the software serves multiple customers. In other words, each user shares the software application program and a database. The database and the software application program tracks who the data belongs to. 
     In a single-tenant architecture (which can also be referred to as a multi-instance architecture), separate web servers, application servers, database servers, or combinations thereof may be provisioned for at least some users or sub-users (e.g., sub-accounts) of those users. In the single-tenant architecture, one or more web servers are provided and dedicated to a user and/or sub-users of that user. Moreover, transactions are processed using one or more dedicated application servers, and data is stored in one or more database servers dedicated to the user or sub-users of that user. In summary, a single-tenant architecture includes a single instance serves only a single user (and its sub-users). Thus, each user has its own database and instance of the software application program. In other words, the database and the software application program are not shared between users (outside of a user&#39;s sub-users). 
     In use, a user&#39;s instance may include multiple web server instances, multiple application server instances, multiple database server instances, and/or any combination thereof. The server instances may be physically located on different physical servers and may share resources of the different physical servers with other server instances associated with other customer instances. 
     Although the system  100  is described as having the application servers  107 , the CMDB  108 , the ECC queue  128 , the MID server  126 , and the like, it should be noted that the embodiments disclosed herein are not limited to the components described as being part of the system  100 . Indeed, the components depicted in  FIG. 1  are merely provided as example components and the system  100  should not be limited to the components described herein. Instead, it should be noted that other types of server systems may communicate with the cloud service  104  in addition to the MID server  126 . 
     Further, it should be noted that server systems described herein may communicate with each other via a number of suitable communication protocols, such as via wired communication networks, wireless communication networks, and the like. In the same manner, the client  102  may communicate with a number of server systems via a suitable communication network without interfacing its communication via the cloud service  104 . 
     In any case, to perform one or more of the operations described herein, the client  102 , the application servicer  107 , the MID server  126 , and other server or computing system described herein may include one or more of the computer components depicted in  FIG. 2 .  FIG. 2  generally illustrates a block diagram of example components of a computing device  200  and their potential interconnections or communication paths, such as along one or more busses. 
     In any case, to perform one or more of the operations described herein, the client  102 , the application server  107 , the MID server  126 , and other server or computing system described herein may include one or more of the computer components depicted in  FIG. 2 .  FIG. 2  generally illustrates a block diagram of example components of a computing device  200  and their potential interconnections or communication paths, such as along one or more busses. As briefly mentioned above, the computing device  200  may be an embodiment of the client  102 , the application server  107 , a database server (e.g., CMDB  108 ), other servers in the cloud service  104  (e.g., server hosting the ECC queue  128 ), device running the MID server  126 , and/or any of the CIs. As previously noted, these devices may include a computing system that includes multiple computing devices and/or a single computing device, such as a mobile phone, a tablet computer, a laptop computer, a notebook computer, a desktop computer, a server computer, and/or other suitable computing devices. 
     As illustrated, the computing device  200  may include various hardware components. For example, the device includes one or more processors  202 , one or more busses  204 , memory  206 , input structures  208 , a power source  210 , a network interface  212 , a user interface  214 , and/or other computer components useful in performing the functions described herein. 
     The one or more processors  202  may include processor capable of performing instructions stored in the memory  206 . For example, the one or more processors may include microprocessors, system on a chips (SoCs), or any other performing functions by executing instructions stored in the memory  206 . Additionally or alternatively, the one or more processors  202  may include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform some or all of the functions discussed herein without calling instructions from the memory  206 . Moreover, the functions of the one or more processors  202  may be distributed across multiple processors in a single physical device or in multiple processors in more than one physical device. The one or more processors  202  may also include specialized processors, such as a graphics processing unit (GPU). 
     The one or more busses  204  includes suitable electrical channels to provide data and/or power between the various components of the computing device. For example, the one or more busses  204  may include a power bus from the power source  210  to the various components of the computing device. Additionally, in some embodiments, the one or more busses  204  may include a dedicated bus among the one or more processors  202  and/or the memory  206 . 
     The memory  206  may include any tangible, non-transitory, and computer-readable storage media. For example, the memory  206  may include volatile memory, non-volatile memory, or any combination thereof. For instance, the memory  206  may include read-only memory (ROM), randomly accessible memory (RAM), disk drives, solid state drives, external flash memory, or any combination thereof. Although shown as a single block in  FIG. 2 , the memory  206  can be implemented using multiple physical units in one or more physical locations. The one or more processor  202  accesses data in the memory  206  via the one or more busses  204 . 
     The input structures  208  provide structures to input data and/or commands to the one or more processor  202 . For example, the input structures  208  include a positional input device, such as a mouse, touchpad, touchscreen, and/or the like. The input structures  208  may also include a manual input, such as a keyboard and the like. These input structures  208  may be used to input data and/or commands to the one or more processors  202  via the one or more busses  204 . The input structures  208  may alternative or additionally include other input devices. For example, the input structures  208  may include sensors or detectors that monitor the computing device  200  or an environment around the computing device  200 . For example, a computing device  200  can contain a geospatial device, such as a global positioning system (GPS) location unit. The input structures  208  may also monitor operating conditions (e.g., temperatures) of various components of the computing device  200 , such as the one or more processors  202 . 
     The power source  210  can be any suitable source for power of the various components of the computing device  200 . For example, the power source  210  may include line power and/or a battery source to provide power to the various components of the computing device  200  via the one or more busses  204 . 
     The network interface  212  is also coupled to the processor  202  via the one or more busses  204 . The network interface  212  includes one or more transceivers capable of communicating with other devices over one or more networks (e.g., the communication channel  106 ). The network interface may provide a wired network interface, such as Ethernet, or a wireless network interface, such an 802.11, Bluetooth, cellular (e.g., LTE), or other wireless connections. Moreover, the computing device  200  may communicate with other devices via the network interface  212  using one or more network protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP), power line communication (PLC), WiFi, infrared, and/or other suitable protocols. 
     A user interface  214  may include a display that is configured to display images transferred to it from the one or more processors  202 . The display may include a liquid crystal display (LCD), a cathode-ray tube (CRT), a light emitting diode (LED) display, an organic light emitting diode display (OLED), or other suitable display. In addition and/or alternative to the display, the user interface  214  may include other devices for interfacing with a user. For example, the user interface  214  may include lights (e.g., LEDs), speakers, haptic feedback, and the like. 
       FIG. 3  is a block diagram of an embodiment of an electronic computing and communication system  300  for discovering and/or managing connected configuration items. The electronic computing and communication system  300  includes one or more environments such as environments  302  and  304  each including resources  306  and  308 , respectively. Each environment  302 ,  304  may include one or more networks coupling resources together in a location-based, function-based, and/or common credentials-based grouping. For example, the environments  302 ,  304  may include a customer service environment used to represent customer service infrastructure in a technical support, sales, billing, and/or other groupings. 
     For example, the environments  302 ,  304  may include a datacenter and all devices coupled to one or more networks located at the datacenter. Additionally or alternatively, the environment  302 ,  304  may be distributed across multiple geographical locations. Thus, the environment  302 ,  304  may include any devices that are accessible by a user account including resources that may be spatially distant from each other. In some embodiments, resources  306 ,  308  may of the environments  302 ,  304  may communicate with each other across environments. However, in some embodiments, aspects of various environments may be provided by different vendors without communication therebetween. In such embodiments, the resources of disparate environments may communicate using the cloud service  104  (e.g., a configuration management service  310  that is a part of the cloud service  104  including the CMDB  108 ). The resources  306  and  308  may include any suitable configuration item  110  previously discussed. 
     The configuration management service  310  may include one or more servers providing access to and managing the CMDB  108 . The configuration management service  310  may allocate or provision resources, such as application instances in the resources  306  or  308  from a respective environment  302  or  304 . Further, the configuration management service  310  may create, modify, or remove information in the CMDB  108  relating to the resources  306  or  308 . Thus, the configuration management service  310  may manage a catalogue of resources in more than a single environment (even if the environments may not directly communicate with each other). Using this catalogue, the configuration management service  310  may discover new resources, provision resources, allocate resources, modify, and/or remove resources from the catalogue across a single environment or multiple environments. In some embodiments, these actions may be initiated using the client  102 , scheduled for periodic occasions (e.g., periodic discovery), or a combination thereof. For example, a client  102  may receive a request, via its input structures, to query an identity of an application program interface (API) used by a resource to access a particular vendor/provider for the environment  302  that is passed to the configuration management service  310  to query the CMDB  108 . As another example, the client  102  may receive a request, via its input structures, to query an identity of a user authorized to access a particular resource that is passed to the configuration management service  310 . 
     As previously discussed, the CMDB  108  may be populated utilizing a discovery process which may be used to discover the resources  306  or  308 . Moreover, as previously discussed, the discovery process may include determining the properties or attributes of the resources  306  or  308  in their respective environments  302  or  304  using a respective MID server  126 A or  126 B. In the illustrated embodiment, each environment  302  and  304  has its own MID server  126 A and  126 B. In some embodiments, a single MID server may be employed when the MID server may reach into multiple environments. For example, if the MID server is run in the cloud service  104  (e.g., in the configuration management service  310 ), a single MID server may be used to manage both environments  302  and  304 . Additionally or alternatively, if the MID server  126 A has access to the environment  304 , the MID server  126 B may be omitted. 
     As previously discussed, each discovered resource is identified as a configuration item  110  with a record stored in the CMDB  108  including data indicating properties, attributes, dependencies, or other information about the resource. The CMDB  108  may be encoded, for example, as a relational database management system (RDBMS); an object-oriented database (e.g. an XML database); a network model database; or a flat-file database. 
     Overtime configuration files used by the CIs  110  may change. As previously noted, in systems with multiple CIs  110  it may be difficult and/or time-consuming to examine the configuration files to determine where or when changes are made to various files.  FIG. 4  illustrates a flow diagram of tracking configuration files for the CIs  110 . A tracked file definition  352  is submitted via the client  102  or another location. The tracked file definition  352  defines how to find the configuration file(s) to be tracked and/or other information about the file. The tracked file information may include the information below in Table 1. 
                     TABLE 1                  Tracked file information                             Field name   Label   Type   Description               file_path   File Path   String   Configuration files path                   expression       pattern   Discovery   Reference   Additional attributes - OS,           Pattern       run order, etc.       ci_type   CI Type   Table name   Type of device for the                   associated CI       save_content   Save Content   Boolean   Provides the option to                   decide whether to save the                   content of the files under                   the indicated path       active   Active   Boolean   Indicates whether the                   tracking is active.                    
Although each tracked file information entry may include a flag of whether the content is tracked (e.g., active field), in some embodiments, a user may globally enable and/or disable tracking for configuration files. For example, when the user wants to limit memory consumption, the user may disable configuration files. For instance, the tracked file definition  352  includes a file path that indicates where one or more configuration files may be located. In some embodiments, this file path may include an identifier for a device (e.g., IP address) or may be pointed at a particular device with no IP address in the file path. For example, the file definition may include “$install_directory+“/conf/*.xml” for one or more CI types (e.g., Apache Tomcat service). As noted, the file definition may include wildcards (e.g., *) that enable returning multiple files that satisfy the remaining search criteria in the definition. Furthermore, as noted, the file definition may include resolvable units. For example, the resolvable units may include variables (e.g., “$install_directory” for the install directory) that may be resolved differently for different applications and/or different servers. The resolvable units may also include functions (e.g., “+” for concatenate) to indicate how resolvable units and other portions of the pattern interact. These resolvable units may be resolved in some embodiments by storing the file path expression in a similar format (e.g., Neebula Discovery Language) used for discovery to enable resolution during discovery. Additionally or alternatively, the tracked file definition  352  may include a path to a CI  110 , and the configuration files may be discovered during discovery.
 
     Some definitions may identify more configuration files. For example, a pattern to be input as a definition may include an identification section that may be used to identify other configuration files. The cloud service  104  or the client  102  determines whether the pattern includes additional configuration files (block  354 ). If additional files are to be included, the cloud service  104  brings in the additional configuration files to be included (block  356 ). The cloud service  104  then performs discovery on a location (e.g., IP address, network, etc.) using the pattern including a file path to discover configuration files satisfying criteria in the pattern (block  358 ). As part on the discovery, an outgoing payload  360  including the list of tracked file names/locations to be discovered is passed from cloud service  104  to the MID server  126  via the ECC queue  128 . In some embodiments, as a preparation, the cloud service  104  resolves variables in the tracked file definition. Additionally or alternatively, the MID server  126  may resolve the variables. For example, regardless of where the variables are resolved, if an install directory is located at “/tomcat/” in the example discussed above. The file path expression is changed to “/tomcat/*.xml”. As discussed below in reference to  FIG. 5 , the MID server  126  acts upon the payload to discover the configuration files. 
     The discovered configuration files are then used to populate/add to a list of discovered file names. For example, if a “server.xml” is discovered within the “/tomcat/” install folder, an entry for a tracked file name “/tomcat/server.xml” is created. A single pattern may result in a single entry or may result in multiple entries. For example, if the install directory included multiple XML files, each XML file may all be discovered. An input payload  362  including the discovered file names is passed to the cloud service  104  from the MID server  126  via the ECC queue  128 . 
     These discovered file names are then passed to an identification engine  364  that marks the files as tracked in the CMDB  108 . For example, an additional identifier (e.g., metadata) about the CI  110  and/or its configuration files may be added as a new CI or added to a current CI. In other words, the configuration file may be stored as its own CI. In some situations, a current CI may be updated to change an indicator (e.g., metadata flag) to indicate that the file is to be tracked when the configuration file already has a CI generated in the CMDB  108 . 
     Since tracking files consumes resources (e.g., memory and processing), the cloud service  104  may determine whether a configuration file should be removed. (block  366 ). If the configuration file was not discovered (e.g., has been deleted) at the file path in the definition, the CI created from the configuration file is deleted (block  368 ). 
     The CIs  110  (including newly created configuration file CIs) and relations in their entries  370  along with tracked flags are sent to the CMDB  108 . The entries in the CMDB  108  may include contents and/or a hashing of the content. For example, the entries may include additional fields, such as those listed in Table 2, to enable file tracking. 
                     TABLE 2                  Tracking configuration files fields in a CI entry                             Field name   Label   Type   Description               content   File Content   Compressed   Contents of the               Data   configuration file identified       hash   Hash   String   Checksum used by the MID                   server 126 to determine                   whether a change has                   occurred       last_modified   Last   Glide Date   Most recent modification           Modified   Time   date and time on the server       file_size   File Size   Long   File size in Bytes                    
The contents in the configuration file CIs is added to the CMDB  108  to enable tracking. In some embodiments, the contents of the configuration files are compressed before storage as CIs in the CMDB  108 . Regardless, as discussed below, the contents in the CMDB  108  may be accessed via a service mapping timeline  372 , a CI timeline  374 , and/or file comparison user interface (UI)  376 .
 
     In some embodiments, an application programming interface (API), such as a Representational State Transfer (REST), may be used to fetch all tracked file definitions. The API may be used during synchronization of tracked file definitions with the MID server  126 . Access to these files may be divided into administrators, middle authorities, and users groups, such that one or more groups (e.g., users group) does not have access to the tracked file definitions via the API. 
       FIG. 5  illustrates a process  386  that may be performed within the MID server  126 . The MID server  126  receives the pattern  387  in the payload  360 . In some embodiments, the MID server  126  may be synchronized with file definitions/patterns at startup of the MID server  126 . A business rule may be used to determine when each insertion or modification of a definition record is synchronized during uptime of the MID server  126 . 
     The MID server  126  discovers whether one or more configuration files satisfy the criteria of the pattern (block  388 ). If no configuration files satisfy the criteria or the discovery fails for some other reason (e.g., credentials used unable to access the configuration file), the MID server  126  reports the failed discovery (block  389 ). This reported error may later cause deletion of the CI corresponding to the configuration file from the CMDB  108 , as previously discussed. 
     If one or more configuration files are found, the MID server  126  may begin to resolve external file definitions (block  390 ). In some embodiments, the resolution of external file definitions may occur when the external file definitions are called by the cloud service  104 . If external file definitions are identified in the pattern (block  391 ), the MID server  126  resolves the file paths and joins the external file paths with the file paths defined inside the pattern (block  392 ). 
     Whether external file paths are resolved or no external file paths are identified, the MID server  126  fetches the file information including information about file content (e.g., actual content, hashed checksum of content, etc.) (block  393 ). When a hashed checksum is used, the checksum content may be calculated from file content size plus a value of maximum file size and a save_content flag indicating whether the information should be saved. Alternatively, the hashed checksum may be calculated from the file size plus the last modification time and a value of the maximum file size and the save_content flag. Alternatively, the checksum may be any hashed value of the content suitable to indicate whether the content of the configuration file has changed. The MID server  126  compares this file information to previous file information to determine whether the content of the file has changed (block  394 ). For example, the illustrated embodiment includes a checksum compared to a previous checksum. If the checksum has changed, the MID server  126  also determines whether the content is to be saved to the configuration file info (and later the corresponding CI) (block  395 ). If the checksum has changed and the content is to be saved, the MID server  126  adds the content to the file information (block  396 ). The MID server then converts each file to a CI by including appropriate metadata information including connections to relevant parent CIs (block  397 ). 
     In some embodiments, the MID server  126  may determine whether the converted CIs with content surpass a payload size threshold (block  399 ). When the payload exceeds the payload size threshold, the MID server  126  splits the payload into multiple payloads (block  398 ). These multiple payloads are passed to the ECC queue  128  and the identification engine  364  sequentially. 
       FIGS. 6-10  include screens of an embodiment of user interfaces (UI) that may be used with the systems and methods disclosed herein. 
     Pattern Designer UI 
       FIG. 6  shows a screen  400  that may be used to access currently tracked file entries and/or create new configuration file tracking entries in a pattern designer for designing patterns for future discovery processes. As illustrated, the screen  400  includes navigation tabs  402 . The navigation tabs  402  enable selection of a pattern viewing screen or a tracked files screen. In the illustrated embodiment, an embodiment of a tracked file screen  404  is presented. Within the tracked file screen  404 , a list  406  of tracked files is presented. The illustrated embodiment of the list  406  includes only a single entry  408  while some embodiments may include any number of entries. For each entry in the list  406 , a CI Type column  410  that indicates a type of CI corresponding to criteria for the tracked configuration file, a file path column  412  that indicates the file path to the tracked configuration file corresponding to the entry, a save content column  414  that indicates whether content of the configuration file is saved in the CI, and an active column  416  that indicates whether the tracked configuration file is actively being tracked. 
     The tracked file screen  404  also includes a create entry button  418 . Upon selection of the create entry button  418 , the screen  400  presents a create file tracking entry creation box, discussed below. Existing entries may be edited or removed using an edit entry button  420  or a remove entry button  422 , respectively. In some embodiments, the edit entry button  420  may bring up a file tracking entry edit box that is similar to the create file tracking entry creation box. Additionally, removal of multiple entries may be made simultaneously by selecting a selection box  424  for each respective entry to be removed and clicking the remove entry button  422 . 
     Changes made to the pattern including the tracked configuration file criteria may be saved or discarded using a pattern save button  426  or a pattern change discard button  428 . Additionally or alternatively, the pattern may be deleted entirely using a delete button  430 . 
     Comparison Screen UI 
       FIG. 7  illustrates a tracked file definition box  440  overlaid on the screen  400 . The tracked file definition box  440  may be accessed using the new create entry button  418  and/or the edit entry button  420 . When the tracked file definition box  440  is opened for an existing entry via the edit entry button  420 , fields  442  of the tracked file definition box  440  are filled when opened. The tracked file definition box  440  includes fields  442 . Each field  442  may correspond to a column in the tracked file screen  404 . In the illustrated embodiment, the fields  442  includes a CI type field  444 , a file path field  446 , a save content radio  448 , and an active tracking radio  450 . Changes via the tracked file definition box  440  may be saved to the tracked file screen  404  via a save button  452  or may be canceled without saving to the tracked file screen  404  by clicking a cancel entry button  454 . 
     Once a configuration file is tracked with content saved, a current configuration file may be compared to a previous configuration file.  FIG. 8  illustrates an embodiment of a comparison screen  460  comparing a first version  462  of a configuration file to a second version  464  of the configuration file. The specific configuration file may be identified using a configuration file identifier  466 . In the illustrated embodiment, the configuration file identifier  466  includes the file path to the configuration file. Additionally or alternatively, the configuration file identifier  466  may include other identification, such as a human-readable label. In some embodiments, the comparison screen  460  may include highlights  468  and  470  where the first version  462  and the second version  464  of the configuration files differ. Moreover, the first version  462  and the second version  464  are saved at different times as indicated by a first save time indicator  472  and a second save time indicator  474 . These highlights may be jumped between using a next difference button  476  and a previous difference button  478  by moving to a next difference or a previous difference, respectively. 
     Service Mapping UI 
     Service mapping timelines  372  may be used to display an accurate, up-to-date view of infrastructure of one or more networks (e.g., IT networks). The service mapping timelines  372  may be used to view CIs that have been discovered during discovery processes.  FIG. 9  illustrates a service mapping timeline  490 . The service mapping timeline  490  includes a service map  492 , a properties frame  494 , and a changes timeline frame  496 . The service map  492  includes icons  498 ,  500 ,  502 ,  504 ,  506 ,  508 ,  510 ,  512 ,  514 , and  516  that each corresponds to a CI  110  that has been discovered during a discovery process. The service map  492  includes graphical illustration of interconnections between the CIs. 
     Upon selection of an icon from the service map, the properties frame  494  may reflect information about the selected CI and its related configuration files. For example, the properties frame  494  may include a configuration directory sub-frame  518 , a CI type sub-frame  520 , a class sub-frame  522 , a tracked configuration files sub-frame  524 , and a detailed properties sub-frame  526 . The configuration directory sub-frame  518  indicates a directory under which configuration files for the CI may be located. The CI type sub-frame  520  indicates a CI type for the currently selected CI. The class sub-frame  522  indicates a class for the currently selected CI. The tracked configuration files sub-frame  524  includes a list of configuration files being tracked for the CI. The detailed properties sub-frame  526  may include additional details about the CI that does not fit in the categories designated for the other sub-frames. 
     The changes timeline frame  496  may display a list  528  of changes to tracking and/or tracked files. In some embodiments, the list  528  may include changes to any and all CIs in the service map. Alternatively, the list  528  may display changes only related to a selected CI. The list  528  details information about the changes. For example, the list  528  includes when the change occurred in a created column  530 , a name for the change in a name column  532 , and an attribute description of the change in an attribute description column  534 . 
     The changes timeline frame  496  may display other information. For example, to display discovery messages (e.g., errors in discovery), a discovery message button  536  may be selected. From a display of discovery messages, the list  528  of changes may be displayed after selection of a changes button  538 . In the illustrated embodiment, CIs are only added. The CIs may be visually marked as added using a visual notification, such as the exclamation point and triangle illustrated in the embodiment. 
     The service mapping timeline  490  may also include timeline  540  reflecting all of the changes. Clicking a location in the timeline  540  may change which changes are reflected in the list  528 . Alternatively, the list  528  may be navigated using a navigation control  542 . A resolution of the timeline  540  may be changed using resolution controls  544 . In some embodiments, increasing the resolution may increase a number of events shown on the timeline. 
     The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure. 
       FIG. 10  illustrates the service mapping timeline of  FIG. 9  at a subsequent time when the only tracked change for the selected icon  508  is an update to the CI tracked item corresponding to icon  508 . In some embodiments, this update may be visually marked on the display. For example, in the illustrated embodiment, the word “UPDATED” is added next to the icon  508 . However, in some embodiments, other text or icons may be used to indicate that the corresponding file has been updated. Furthermore, since the icon  508  is selected, the properties frame  494  has changed to display the properties of the CI corresponding to the icon  508 . 
       FIG. 11  is a flowchart diagram of an embodiment of a process  600 . As previously noted, the process  600  begins by receiving a definition of a pattern (block  602 ). For example, the definition of the pattern may be input using a pattern designer through the client  102 . Using this pattern, the cloud service  104  performs horizontal discovery to discover a configuration file (block  604 ). In some embodiments, the horizontal discovery of the configuration file may include more than a single configuration file. Moreover, in some embodiments, the horizontal discovery may occur through one or more discovery servers (e.g., MID server  126 ). 
     The configuration file is updated to the CMDB  108  as a configuration item (block  606 ). In some embodiments, the update includes adding a new configuration file. Furthermore, in some embodiments, as previously discussed, the configuration item entries in the CMDB  108  may also include content from the configuration file used to create the CI entry in the CMDB  108 . 
     In some embodiments, the CI entry includes a checksum of the content in the configuration file. A current checksum is compared to a previous checksum stored in the CMDB  108  before updating the CI entry. As previously noted, in such embodiments, if the checksum has not changed, the configuration file is not used to update the CI entry in the CMDB  108 . However, if the checksum differs, the CI entry is updated to reflect the configuration file changes. 
     The differences between the stored CI entry and the update to the CI entry may used to track changes to the discovered configuration file (block  608 ). For example, when content is stored, the previous content and the updated content may be compared (e.g., side-by-side view). Moreover, in some embodiments, a log of the changes may be maintained using multiple versions by adding new content to the CI entry without removing older content or retaining only data from previous versions that does not match the current version. 
       FIG. 12  is a flowchart diagram of an embodiment of a process  610  that may be executed on the MID server  126  to track additions or changes to configuration files. The MID server  126  receives a pattern indicative of target configuration files (block  612 ). As previously discussed, the pattern may be received from the cloud service  104  and/or the client  102 . Moreover, the pattern may include various criteria about the configuration files to be tracked. For example, the pattern may indicate a file path for the configuration files. In some embodiments, the pattern may include wildcards or variables. The MID server  126  may resolve the variables or wildcards in the patter to obtain one or more file paths (block  614 ). For example, the variable may indicate a directory (e.g., $install directory) at which the install of an instance of software associated with the CI. The MID server  126  also determines whether there are any external file paths in the pattern (block  616 ). For instance, the pattern may include file paths in a description identifying files outside of the directory where the target configuration file path is located. The MID server  126  resolves these file paths (block  618 ). 
     For the criteria (e.g., file path locations) indicated in the pattern, the MID server  126  fetches file information for each configuration file (block  620 ). The file information may include content of the configuration file, CI type, and/or other information about the configuration file. The MID server  126  also calculates a checksum based on the file information (block  622 ). The MID server  126  determines if the file has changed and whether the file is to be saved (block  624 ). For example, if the checksum has changed from a previous checksum, the file has changed. To determine whether the file is to be saved, the MID server  126  may examine a flag (e.g., single bit) indicating whether the file content is to be saved or not. If the file has been changed and changes to the file are to be saved, the MID server  126  saves the changes in the configuration file information (block  626 ). Configuration files are converted into a corresponding CI by appending appropriate metadata onto the configuration file information (block  628 ). 
     In some embodiments, the payload to be delivered from the MID server  126  may be relatively large. Thus, as previously discussed, in some embodiments, the MID server  126  may determine whether the payload of the one or more configuration item converted from configuration files bound outside the MID server  126  (e.g., to the CMDB  108 ) exceeds a threshold size (block  630 ). If the payload size exceeds the threshold size, the MID server  126  splits (block  632 ) the payload into two or more payloads. The MID server  126  then delivers those payload(s) (block  634 ). 
     The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).