System and method for discovering assets and functional relationships in a network转让专利
申请号 : US12260438
文献号 : US09172611B2
文献日 : 2015-10-27
发明人 : Kowsik Guruswamy
申请人 : Kowsik Guruswamy
摘要 :
权利要求 :
What is claimed is:
说明书 :
The present invention is related to U.S. Utility patent application Ser. No. 12/234,450, filed Sep. 19, 2008, U.S. Utility patent application Ser. No. 11/514,809, filed Sep. 1, 2006, and U.S. Utility application Ser. No. 11/760,600, filed Jun. 8, 2007, all of which are hereby incorporated by reference in their entirety.
1. Field of Art
The present invention generally relates to the field of system management, in particular to information technology (IT) assets and services discovery, IT search, and change management.
2. Description of the Related Art
A network typically includes a variety of interconnected component systems (also referred to as component systems, network/service elements). Each of the component systems provides one or more services and works together with the rest to collectively provide aggregate services to users. For example, in Voice Over IP service (VoIP), session border controllers work in conjunction with gateways, phones, billing systems, Domain Name System (DNS) servers, Remote Authentication Dial In User Service (RADIUS)/Lightweight Directory Access Protocol (LDAP) authentication servers, and underlying IP infrastructure, to constantly validate and ensure that phones can be registered, that phone calls can be made, that the caller is authenticated, and that the phone calls are billed properly.
Because component systems can be added, removed, and changed (e.g., reconfiguration, patching, upgrading) overtime, the landscape of a network evolves overtime. In addition, because of the interdependent nature of the component systems, changes made in one component system (e.g., configuration changes) can inadvertently affect other component systems dependent upon it. The unintended impact can cause inter-component dependencies to breakdown and thereby break the service. Therefore, it is important to track the component systems and their status and functional relationships.
Traditional best practice techniques of managing hosts on a network and their configurations are summarized in the Information Technology Infrastructure Library (ITIL). In the context of asset management, such technologies mostly revolve around node-based views of the network. Tremendous efforts have gone in to enumerate and list out what's on the network and when it was provisioned. Unfortunately, such efforts have mostly resulted in a static spreadsheet view of the network that has to be manually updated. This is not only laborious, but also error prone. In the context of change management, such technologies mostly revolve around Simple Network Management Protocol (SNMP) based monitoring, log-based management-by-exception, and Change Management DataBase (or Configuration Management DataBase, CMDB). SNMP-based monitoring provides a large amount of details without revealing the configuration and supported services of the underlying component system. Log management records what has happened in the underlying component system without revealing the actual impacts or the causes. CMDB typically involves a spreadsheet for network operators to track configuration changes manually, which is both tedious and error prone. In addition, the traditional way of enumerating applications within known hosts involves installing agents in each of the known hosts which further explore and discover applications, file systems and other aspects internal to the host. This approach is defective because installing agents on hosts are intrusive and can potentially destabilize the hosts.
Therefore, there is a need for a system and method for automatically discovering network components and their statuses and functional relationships in real time.
The present invention overcomes limitations of the prior art by providing a discovery system (and corresponding method and computer program product) for discovering assets and functional relationships among the assets in a network system. In one embodiment, the discovery system executes protocol queries against the network system. The discovery system contextually analyzes query responses for determining references to assets in the network system and their roles and functional relationships based on corresponding protocol grammars. The discovery system determines queries associated with the newly discovered assets based on their roles and functional relationships, and recursively applies the above process to the newly discovered assets to discover additional assets and their roles and functional relationships.
In one aspect of the present invention, the discovery system is scheduled to periodically interrogate assets for up-to-date information of the assets and functional relationships among the assets. Such information can be indexed and searched.
Other aspects of the disclosure include software, systems, components, and methods corresponding to the above, and applications of the above for other purposes.
The disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.
The present invention describes a methodology and corresponding system and computer program product to discover assets in a network system and their roles, statuses, and associations (also called functional relationships) with each other. An asset is defined as an entity that supports one or more protocols, such as a network, a physical host, a service that runs on the host as well as virtual hosts.
According to one aspect of the present invention, a seed asset in a network system and its supporting protocol commands are represented by a seed object and associated methods. The methods of the seed object are invoked to interrogate the seed asset. The responding messages from the corresponding seed asset is normalized into Document Object Models (DOMs) and contextually analyzed to identify references to other assets, their roles and functional relationships with the queried asset. The identified assets are represented by objects. Protocol commands supported by the identified assets are represented by methods associated with the corresponding objects and invoked for responses. The responses are then normalized and analyzed for further assets. This process can be recursively applied to newly discovered assets to discover additional assets available in the network system and their roles and functional relationships. This process can also be applied continuously by a discovery system to make multiple periodical passes of the assets to extract real time status and functional relationship information.
The discovered information can be used to construct a network functional topology map, and to provide advanced services such as searches, change management, and customizable advanced visualization. This map beneficially identifies functional relationships between services and hosts that are closely relevant in troubleshooting and diagnosing service-related problems. This map is one layer above physical connectivity that, while interesting, masks the complex service-level dependencies in most modern networks.
Protocol Normalization and Message Abstraction (DOM)
Communications among computing devices generally involve the exchange of data or messages in a known, structured format (a “protocol”). Typically a computing device supports one or more protocols by implementing them in software or hardware modules within the device. Each of these protocols can be described by a concrete formal grammar (e.g., a context-free grammar) through a process called normalization (also known as canonization). The grammar can be represented by a generic data structure, and can be used to generate and verify protocol messages. Further information regarding normalization and representing protocols using a generic data structure is found in U.S. application Ser. No. 11/514,809, filed Sep. 1, 2006, titled “Automated Generation of Attacks for Analyzing the Security of Communication Protocols and Channels”, the content of which is incorporated by reference in its entirety.
A protocol typically includes one or more messages (or commands). A protocol message can be expressed as a method call, with its fields represented by parameters of the method call. Similarly, a responding protocol message can be expressed using markup language such as the Extensible Markup Language (XML) and stored in a normalized document object model (DOM). Responding protocol messages can be parsed according to the corresponding protocol grammar. The parsing result can be expressed in XML and stored in the DOM. Further information regarding protocol message representation and normalization is found in U.S. application Ser. No. 12/234,450, filed Sep. 19, 2008, titled “Test Driven Deployment And Monitoring Of Heterogeneous Network Systems”, the content of which is incorporated by reference in its entirety. As a result of the normalization process, the complexity of the protocol communication (e.g., layers of communication protocols used in the actual transmission) is hidden behind the method call and the returned canonical DOM.
A responding protocol message typically includes information of interest. For example, a message responding to an inquiry about a digital certificate contains information regarding when the digital certificate expires. Such information can be stored and indexed for subsequent searches, and used for testing purposes. A responding protocol message often contains information referencing other devices, hosts, and/or services (collectively referred to assets) available in the network. For example, in response to a received DHCPREQUEST message, a DHCP (Dynamic Host Configuration Protocol) server returns a DHCP Acknowledgement message identifying itself as the DHCP server. The DHCP Acknowledgment message may also contain information such as information about local DNS (Domain Name System) server(s) (e.g., its IP (Internet Protocol) address). Such reference information can be identified using protocol grammars, generic data structures, and/or contextual information in the responding message (e.g., associated tagging information).
The reference information extracted from responding messages can be used to discover other assets available in the network and their roles and functional relationships with the queried asset. The assets identified by the reference information can be interrogated for further reference information identifying additional assets. This process can be recursively applied to discover assets in the network and their roles and functional relationships (or associations, logical correlations). A system that utilizes the process to discover assets and functional relationships among assets is described in detail below.
Computing Environment
The discovery system 110 (also referred to as crawler system, service crawler, crawler) is configured to discover assets and their roles and functional relationships in the network system 120. The discovery system 110 is configured to conduct the discovery by recursively interrogating known assets (e.g., seed assets, discovered assets) though method invocations 130 for response messages 140, and contextually analyzing the response messages 140 for references to other assets (also referred to as hyperlinks). Alternatively or in conjunction, the discovery system 110 is configured to continuously interrogate known assets to detect changes (e.g., changes in roles, configurations, and functional relationships) in the network system 120.
The discovery system 110 can be implemented in hardware, software, or a combination of both. Regarding software, the discovery system 110 can be, for example, a single application (executing within a single operating system or single physical device) or a collection of applications communicating with each other to correlate discovery operations. Regarding hardware, the discovery system 110 can be, for example, a standalone computer or a collection of physical devices with out-of-band synchronization. In one embodiment, the discovery system 110 is a portable appliance that can be transported to different locations to conduct discovery in different network systems.
The network system 120 includes multiple assets (not shown). An asset is an entity that supports one or more protocols, each of which including one or more protocol commands (or functions, methods). When invoked thorough one of such supported protocol function calls, the asset returns one or more responding messages. Each of the assets includes hardware and/or software subject to discovery. Software includes, for example, services, interfaces, domains, applications, operating systems, and/or communications systems. Hardware includes, for example, one or more devices. A device can be, for example, a server, host, subnet, switch, bridge, router, packet filter, firewall, Virtual Private Network (VPN) concentrator, proxy, intrusion detection/prevention system, or network protocol analyzer. An asset (e.g., a subnet) can include multiple devices that are coupled at various communication layers to form a system or network of devices. Each of the component devices can in turn be an asset. The assets communicate with each other through networks such as the Internet, an intranet, a wireless local area network (LAN), a cellular network, or any combination thereof. The assets receive the method invocations 130 from the discovery system 110 and respond by sending the response messages 140.
In one embodiment, the discovery system 110 and/or assets in the network system 120 (or computer systems executing the discovery system 110 and/or assets) are structured to include a processor, memory, storage, network interfaces, and applicable operating system and other functional software (e.g., network drivers, communication protocols).
A system architecture of the discovery system 110 is discussed below according to one embodiment of the present invention.
System Architecture of Discovery System
A protocol suite 210 is a parameterized atomic protocol command (or transaction, method, function) for a protocol. A protocol suite 210 is a method call where arguments (or parameters) are defined but the actual values for the arguments are not known. For example, DNS requests can be represented by the following protocol suite:
- DNS.query(target-ip, query-name, query-type, query-class)
As shown, the above protocol suite can be customized to query various different aspects of the DNS (e.g., A record, CNAME record, Zone transfer, SOA record). As another example, HTTP (Hypertext Transfer Protocol) requests can be represented by an HTTP protocol suite that takes URL and SSL setting as arguments. The discovery system 110 can be pre-configured with a set of basic protocol suites 210 for well established protocols (e.g., HTTP, DNS). The discovery system 110 can also dynamically add new protocol suites 210 into its collection. For example, the discovery system 110 can discover protocols (and/or commands) supported by an asset through techniques such as Representational State Transfer (REST), Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery and Integration (UDDI), and create new protocol suites 210 for such newly discovered protocol commands.
- DNS.query(target-ip, query-name, query-type, query-class)
An asset object 220 is an object representing a known asset (e.g., a seed asset or a discovered asset) in the network system 120. Initially the discovery system 110 may only have one or a few asset objects 220 (hereinafter referred to as seed objects). The discovery system 110 discovers other assets through recursively interrogating known assets, contextually analyzing the query responses for additional assets, and then interrogating the additional assets at run-time.
As illustrated, each asset object 220 has one or more queries 222. A query 222 represents a configured protocol suite where the customizable parameters of the underlying protocol suite 210 are defined and specified. Because parameters of a protocol suite 210 can take various values, a single protocol suite 210 can be associated with multiple queries 222, each having a same or different configuration. For example, the DNS request protocol suite 210 illustrated above may have numerous queries 222 associated with various IP addresses, such as the following query 222 soliciting information about the uspto.gov domain:
- DNS.query (www.uspto.gov)
The value of the parameters can be determined on the fly. For example, the value of the IP address argument of the DNS request protocol suite 210 can be extracted from a response message of the queried asset.
- DNS.query (www.uspto.gov)
In one embodiment, objects of certain types of assets have a set of default queries. For example, objects for network components (e.g., hosting computers) by default include a TCP scan query and a UDP scan query. The TCP scan query enumerates through potentially available TCP ports and attempts to communicate with the interrogated network component to discover its supported protocols and assets resided within. Similarly, the UDP scan query attempts to interrogate though potential UDP ports for discovery. Based on the discovery result, the discovery system 110 creates new asset objects 220 and attaches new asset specific queries 222 accordingly. For example, after finding out that a web server supports several services through TCP port 80, the discovery system 110 can create objects 220 for the newly discovered services, and attach service-specific queries 222 of the newly created objects 220 to that port.
The DOM analyzing component 230 (also referred to as spider) is configured to contextually analyze query results to discover references to other assets (also referred to as hyperlinks) and the functional relationships between the queried asset and the other assets. The DOM analyzing component 230 also generates new asset objects 220 for the discovered assets and associated new queries 222 based on the roles and functional relationships of the discovered assets. Responding messages 140 from assets are canonical, normalized DOMs, structured data containing salient portions of the underlying protocol exchanges. Therefore, the context and structure of the DOMs is determined by the underlying protocols. In one embodiment, the discovery system 110 creates a DOM analyzing component 230 for each protocol suite 210 and configures the DOM analyzing component 230 to specially handle the associated query results.
The following is a DOM for a query result of a DNS request. The example DOM is represented using the JavaScript Object Notation (JSON) format, even though other formats (e.g., XML) can also be used.
The above example DOM shows that querying a DNS server for ldap.musecurity.com returns references to three servers named themole, kyle, and stan as well as their IP (Internet Protocol) addresses. As a result, the DOM analyzing component 230 creates three asset objects 220 and associated LDAP (Lightweight Directory Access Protocol) specific queries 222 for the three newly discovered servers.
As another example, the resulting DOM of a query for mount points in the Host Resource Management Information Base (Host Resource MIB) using SNMP (Simple Network Management Protocol) includes the following information:
As shown, the queried host returns references to two other hosts named bertha and clyde. Based on the underlying protocol (Host Resource MIB) and the semantic of the resulting DOM, the DOM analyzing component 230 determines that the host that was queried is mounting different file systems from bertha and clyde, and thus discovers the functional relationships between the queried host and the newly discovered hosts and their roles in the relationships. Thus, by contextually analyzing the resulting DOMs, the DOM analyzing component 230 can identify hyperlinks to additional assets, discover information about the additional assets (e.g., their roles, types, and IP addresses), determine their functional relationship with the queried asset, and create asset objects 220 and queries 222 accordingly.
In addition, the above example shows that the functional relationship identified through executing a query 222 of a protocol is not necessarily tied to the query protocol. In this example, the query protocol is SNMP, and the queried asset and the identified systems (remote mount points) are connected through the Host Resource MIB (or the Network File System). SNMP is a means for the discovery system 110 to discover the remote mount points and does not impose any restriction on the underlying functional relationships. Because the DOM analyzing component 230 associated with the SNMP query is configured with knowledge of the protocol grammar, it can accurately identify the remote mount points and their roles and functional relationships with the queried asset.
The data storage component 240 is configured to store information related to the discovery process of the discovery system 110. Examples of such information include protocol grammars (e.g., supported protocol commands), discovered assets (e.g., information extracted from responses from the assets, DOMs), their roles and functional relationships (e.g., hyperlinks and associated information). The data storage component 240 may be a relational database or any other type of database that stores the data, such as a flat file.
Because inquiries to known assets are expressed as queries 222, the query results are represented by DOMs and contextually analyzed for references to other assets, an analogy can be made between web pages and DOMs, and between hyperlinks in the web pages and asset references in the DOMs. Therefore, spidering technologies can be applied to crawl the network to discover available assets.
A methodology for the discovery system 110 to recursively interrogate known assets to discover additional assets and their roles and functional relationships is described in detail below.
Asset and Functional Relationship Discovery Methodology
The discovery system 110 coordinates the DOM analyzing components 230 to discover assets and their roles and functional relationships in the network system 120. Initially, the discovery system 110 has one or a few seed objects representing known assets (also referred to as seed assets). Examples of such seed assets include a local network interface, and hosts associated with a specific range of IP addresses. The seed object(s) can be pre-configured with the discovery system 110 or provided by users.
The discovery system 110 (or the DOM analyzing component 230) executes 310 queries 222 associated with a seed object by transmitting the corresponding protocol messages to the corresponding seed asset. The responding messages from the seed asset are normalized into DOMs and passed on to the DOM analyzing component 230 corresponding to the executed queries 222. The DOM analyzing component 230 contextually analyzes 320 the DOMs to identify hyperlinks to other assets and determine their roles and functional relationships. The DOM analyzing component 230 determines 330 whether the identified assets are already known to the discovery system 110 (e.g., represented by an asset object 220). If an identified asset is already known to the discovery system 110, the DOM analyzing component 230 merges 340 the results (e.g., by storing information about the asset together). Otherwise, the DOM analyzing component 230 creates 350 an asset object 220 and associated queries 222 for the asset based on the relevant contextual information in the DOM. Information about the DOM, the functional relationships, and the identified assets are also stored in a persistent data store (e.g., the data storage component 240).
The discovery system 110 (or the DOM analyzing component 230) subsequently executes 310 queries 222 associated with newly created asset objects 220 (or newly created queries 222 for existing asset objects 220), and passes on the query results to the corresponding DOM analyzing components 230 for contextual analysis 320. The method 300 can be applied recursively to newly created asset objects 220 and/or queries 222 to discover assets and their roles and functional relationships in the network system 120. In one embodiment, the asset objects 220 (or the queries 222) are placed in a data structure such as a queue and a stack. The discovery system 110 retrieves asset objects 220 from the queue to execute 310 associated queries 222, and adds to the queue newly created asset objects 220 representing assets discovered in results of the queries 222. The discovery system 110 can repeat the process until the queue becomes empty. This process of recursively applying the method 300 is also referred to as crawling.
In one embodiment, the discovery system 110 periodically crawls through the network system 120, and stores resulting information of the assets in the data storage component 240. Assuming the assets in the data store is retrievable by the last-updated time stamp, the discovery system 110 can interrogate one known asset at a time by executing all queries for the asset and merging the resulting changes back into the data storage component 240. Each pass either discovers new assets or new queries or generates change records that identify exactly which part of the known asset was changed and how. By having the normalized query results from all known assets in the data storage component 240 continuously updated by the discovery system 110, a real-time snapshot of the network system 120 including all known assets and their roles and functional relationships can be constructed. As will be described in further detail below, such information can be used to provide various advanced services to users that are unavailable before.
The method 300 is further illustrated through the following example. Assume the discovery system 110 has a seed asset object 210 representing a network interface. The seed object 210 is associated with the following default queries: arp-enum, dhcp-discover, icmp-broadcast-ping, and ssdp-search. The arp-enum query uses ARP (Address Resolution Protocol) to methodically query for all hosts in the subnet connected to the network interface. The dhcp-discover query searches for the existence of DHCP servers on the network. The icmp-broadcast-ping query sends a broadcast ICMP (Internet Control Message Protocol) packet to the network and collects responses from the responding hosts in the network. The ssdp-search query sends an SSDP (Simple Service Discovery Protocol) multicast request to identify all UPnP (Universal Plug and Play) devices (e.g., printers) in the network.
The discovery system 110 places the seed object into a queue (the only object in the queue) and initiates the method 300. The discovery system 110 retrieves the seed object from the queue and executes 310 associated queries by issuing corresponding query messages to the network interface. The network interface broadcasts (or multicasts) the protocol messages. As a result, hosts in the network connected to the network interface receive the protocol messages and respond by sending query results to the discovery system 110 (through the network interface). The query results are normalized into DOMs and passed to corresponding DOM analyzing components 230 for contextual analysis 320.
The following is an example DOM of a response message from a DHCP server for the dhcp-discover query the discovery system 110:
As shown, the DOM includes information (e.g., IP addresses) about two DNS servers, one LPR (Line Print Request) server, one NBNS (NetBIOS Naming Service) server, one NTP (Network Time Protocol) server, one router, and one TFTP (Trivial File Transfer Protocol) server, along with other assets such as the domain (musecurity.com), and information about the DHCP server itself. The DOM analyzing component 230 associated with the DHCPREQUEST protocol suite (also known as DHCP API Discovery) contextually analyzes 320 the DOM and identifies hyperlinks (or references) to the various assets. The DOM analyzing component 230 determines 330 whether the identified assets are already known. Since at this point the discovery system 110 is only aware of the network interface (the seed asset), all the identified assets are unknown. As a result, the DOM analyzing component 230 creates 350 objects and associated queries for each of the identified assets, and places them in the queue. For example, based on the context of the DOM (e.g., the tag “type”=>“dns”), the DOM analyzing component 230 determines that the assets at the IP addresses 10.10.3.80 and 10.10.3.110 are DNS servers for the queried asset, the network interface, and creates objects for them and queries that are specific for DNS servers, such as a DNS Request query. In addition, the DOM analyzing component 230 stores the DOM and the extracted information (e.g., the functional relationships) in the data storage component 240. It is noted that the host with the IP address 10.10.3.110 plays the following roles: a DNS server, an LPR server, a NBNS server, a DHCP server, an NTP server, and a TFTP server. In one embodiment, each of the roles (or functions, services) is identified as a separate asset that is represented by a distinctive asset object 220. In other embodiments, the host can be represented by a single asset object 220 associated with queries for each of these services provided by the host. In one embodiment the queries associated with the newly created objects are created based on the relevant contextual information (e.g., DNS related queries for DNS server assets). In other embodiments, an asset may be associated with context neutral queries (e.g., TCP san and/or UDP scan).
After processing the queries for the seed asset, the discovery system 110 repeats the above process for other objects in the queue. For example, the discovery system 110 can retrieve the asset object 220 representing one of the two newly discovered DNS servers, and executes 310 the associated queries. The responding messages are normalized to DOMs. The following is an example DOM for a DNS request with two different queries. One of the two queries fetches the SOA (source of authority) resource record, and the other queries for the SMTP server (MX resource record).
As shown, the results of both queries include contextual information that identifies additional assets. As a result, the DOM analyzing component 230 associated with the DNS request protocol suite 210 identifies these assets and their roles and functional relationships, creates new objects 220 and associated queries 222, places the new objects 220 in the queue, and stores the results in the data storage component 240.
As shown, by recursively applying the method 300, the discovery system 110 can discover assets in the network system 120 and their roles and functional relationships by following hyperlinks identified in normalized query results. In addition, by repeatedly crawl through the network system 120, the discovery system 110 can maintain a constantly updated database of information regarding the network system 120, the assets within, and their roles and functional relationships. As described below in further detail, the data collected through method 300 can be used to provide advanced user services (or functions).
Starting with the network interface as the seed asset, the discovery system 110 could potentially identify hosts that are outside the subnet range of the network interface or the network range(s) specified by users. In one embodiment, as new hosts are identified, the discovery system 110 can be configured to automatically compare the IP addresses of the newly identified hosts against these ranges to ensure that the discovery system 110 does not leak out into the Internet. Information about such outside assets and their functional relationships can be indexed such that users can query against assets that are outside their realms of control.
Example Usage of Collected Data
As described above, the discovery system 110 can discover new assets and their roles and functional relationships, along other important information about the assets by interrogating known assets (e.g., seed assets, discovered assets). In addition, the discovery system 110 can keep such information up-to-date through automatic continuous crawling. As a result, the discovery system 110 is aware of everything on the network and their configuration (or available services), and how things are actually correlated between each other. This information can be utilized to provide user services. The following are a few examples.
A. Visualization and Data Mining
The updated asset data can be used to provide various visibilities about the network system. For example, the asset data can be used to construct a real-time functional map of all known assets in the network system 120 with new assets added as they are discovered in real time. The functional map identifies assets by their roles and connects assets through their functional relationships. The functional graph not only identifies related assets but also specifies exactly their roles and how they are related. This functional graph is useful for purposes such as determining impact radius of a certain asset in the network system 120.
Because the collected information not only identifies the discovered assets and their status, but also specifies their roles and functional relationships, a user can drill downward, upward, or sideway, or apply other data mining techniques through the visualization. For example, a user can click the service mount in
Other examples include a calendar view of life spans of SSL certificates for all known assets. A user can easily identify expiring SSL certificates in real time. In addition, tests, assertions, alerts, and/or triggers can be attached to the underlying asset data. For example, a trigger can be set to send an email to a network administrator 30 days before an SSL certificate expires.
B. Index and Search
The collected data can be kept up-to-date, indexed, and available for searches.
C. Asset Profiling
Up-to-date asset data can be used to construct real time profiles for all known assets on the network system 120. The asset profiles can be used to conduct similarity comparisons among assets, and generate distance metrics for the assets based on their similarities. For example, asset information can be converted into normalized documents that are subject to document comparisons. In addition, assets can be classified based on their similarities or compliance with customizable signatures. Such classification can be visualized to users.
D. Change Management
The discovery system 110 can be scheduled to periodically crawl the network system 120. The resulting data can be stored with associated time stamp. As a result, the data can be used to detect changes in system behavior, either configuration or service degradation on an on-going basis. Such time-stamped asset information can be used to create timeliness. A common aspect of change management is tracking progress towards a goal in the form of checklists. By tying a search parameter directed to a goal, a dynamic checklist refreshed constantly can be generated by the discovery system 110. One example of such a use case is upgrading hosts that are running a particular application. The discovery system 110 can keep track of how many hosts have not yet been updated. Historically such a task has been tracked and managed using static spreadsheets.
Services other than those listed above can be provided using the crawled data. For example, the collected asset data can be used to conduct tests and verifications. As another example, while deploying a network system, the discovery system 110 can be used to discover and track assets and functional relationships among the assets in the network to ensure proper deployment. Further information about the test driven deployment is found in U.S. Utility patent application Ser. No. 12/234,450, filed Sep. 19, 2008, the content of which is hereby incorporated by reference in its entirety.
In one embodiment, multiple discovery systems 110 might be deployed across multiple networks all of which generate information that is merged to get a global perspective across the multiple networks. The information generated from these multiple discovery systems 110 can be synchronized and/or merged in a central data store.
Even though the discovery system 110 is described above to discover assets available in a network, one skilled in the art would understand that it can be applied to discover assets residing on a single device (e.g., an unconnected computer).
The discovery system 110 can automatically discover additional assets, up-to-date information about known assets, and their roles and functional relationships in real time. In addition, the discovered information can be used to provide advanced services regarding the network system and assets within.
In the preceding description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. It will be apparent, however, to one skilled in the art that the disclosure can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the disclosure.
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, objects, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices.
The present disclosure also relates to an apparatus for performing the operations herein. This apparatus is specially constructed for the required purposes, or it comprises a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program is stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems are used with programs in accordance with the teachings herein, or more specialized apparatus are constructed to perform the required method steps. The required structure for a variety of these systems appears in the description herein. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the disclosure as described herein.