DYNAMIC DISCOVERY OF APPLICATIONS, EXTERNAL DEPENDENCIES, AND RELATIONSHIPS

Description

BACKGROUND

[0001] Enterprise-scale services typically have large numbers of servers in a particular role. The arrangement of the servers is typically fairly fluid as machines are added, removed, or taken out for maintenance. In addition, many enterprise-scale services utilize multiple copies of their service. As a result, designing a monitoring system that can automatically discover the services, and give relevant health state to an operations center can be challenging.

[0002] This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.

[0003] US 2009/0106256 A1 describes methods, systems, and apparatus, including computer program products, for discovering entities in a first portion of a data center network, examining information associated with the discovered entities to determine relationships that exist between pairs of entities in the first portion of the data center network, and generating a specification of the relationships that exist between pairs of entities in the first portion of the data center network based on results of the examining.

[0004] US 2008/0215922 A1 describes a system, method and program enabling users to diagnose applications easily without affecting the operating performance of the application server, optimizing the log mechanism based on the integrated development environment. The method includes running the application in a main running environment and at least one shadow environment, the shadow environment obtained by duplicating the main running environment; and the main running environment interacting with the shadow environment with respect to the fault of the application. The method includes performing the steps of the main running environment: monitoring the exceptions in the system and sending system exception information to the shadow environment in the event of finding exceptions in the system. The shadow environment: receives the system exception information, opens diagnostic log/trace functions to obtain diagnosis log/trace files related to the system exceptions, and analyzes the diagnosis result based on the obtained diagnosis log/trace files.

SUMMARY

[0005] The invention is set out in the appended set of claims.

[0006] A monitoring system is arranged for automatically and dynamically discovering local applications running on servers in an enterprise-scale service environment as well as discovering external resources (both partitioned and non-partitioned resources) that the local applications use. The discovered objects and their dependencies are instantiated into a health map and the map is dynamically updated as applications and resources are added to and deleted from the enterprise-scale service environment. Health indicators such as events, performance counters, synthetic transactions, and SysLog and SNMP (Simple Network Management Protocol) service events for the mapped objects are monitored. The monitored health indicators are attributed to either the health of a local application or that of an external resource. Upon detection of a fault, the health map enables performance of root cause analyses and determination of the impact of the fault on the objects in the environment so that appropriate alerts can be raised.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] 

FIG 1 shows an illustrative computing environment in which the present dynamic discovery of applications, external dependencies, and relationships may be implemented;

FIG 2 shows servers, databases, and an operations center in an illustrative enterprise-scale service;

FIG 3 shows duplicated servers and external resources arranged in illustrative production and test environments that may be utilized in an enterprise-scale service;

FIG 4 is a flowchart of an illustrative method for dynamically discovering applications, external dependencies, and relationships;

FIGs 5-9 show illustrative taxonomies of various details of steps in the method shown in FIG 4;

FIG 10 is a simplified block diagram of an illustrative computer system such as a personal computer ("PC") that may be used in part to implement the present dynamic discovery of applications, external dependencies, and relationships; and

FIG 11 shows a block diagram of an illustrative computing platform that may be used in part to implement the present dynamic discovery of applications, external dependencies, and relationships.

[0009] Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.

DETAILED DESCRIPTION

[0010] FIG 1 shows an illustrative computing environment 100 in which the present dynamic discovery of applications, external dependencies, and relationships may be implemented. Users 105 of a variety of client devices 110 including multimedia consoles, mobile phones, smartphones, tablets, personal computers ("PCs"), personal digital assistants ("PDAs"), handheld gaming platforms, personal media players, wearable computers, navigation devices, and the like, may interact with one or more enterprise-scale services 115_{1 ... N} over a network such as the Internet 125. For example, the enterprise-scale services 115 may host web applications, provide consumable media content, support browsable and/or interactive web pages, or the like, in any of a variety of applications.

[0011] FIG 2 shows servers, databases, and an operations center in an illustrative enterprise-scale service 115. As shown, a number of servers 205_{1, 2 ... N} are located in the service 115 and are utilized to support the interaction with the users 105 and client devices 110 (FIG 1). In some cases, a given server 205 may be operatively coupled to one or more databases of external resources, as representatively indicated by reference numeral 210. During typical operations of the enterprise-scale service 115, servers 205 may be added to the environment, removed, or taken out for maintenance as representatively indicated by the dashed-line rendering of server 205_N.

[0012] The operations center 215 is configured to be in communication with the servers 205 and external resources 210 so that monitoring of various operational aspects of the service 115 can be implemented. As described in more detail below, such monitoring may be performed by a monitoring service 220 and include instantiation of objects into a health map 225, and dynamic updating of the map as servers 205 and resources 210 are added and removed from the service 115 over time. The monitoring may also be utilized to generate a single root cause alert 230 upon detection of a fault that occurs in the service 115.

[0013] FIG 3 shows an illustrative map 225 of duplicated servers and external resources arranged in illustrative production and test service environments (respectively indicated by reference numerals 300 and 305) that may be utilized in the enterprise-scale service 115. Duplication in this manner may typically be performed to ensure the provision of high quality and reliable services to the users 105. For example, if a fault or problem in the service is detected or reported by a production user 310, a test user 315 and/or other service personnel can perform tests, run diagnostics, attempt to duplicate the problem, or test potential solutions and workarounds, among other activities, in the test environment 305 without having to take down production servers and resources in the production environment 300 which would generally be highly disruptive to the service 115 and its users.

[0014] In both the production and test service environments, local applications are arranged in service groups. As used here, a local application is a single instance of an application running on a single server, for example, a www.xbox.com web server that supports Microsoft Corporation's game related service offerings. A service group is a group of local applications that provide a common function to a common consumer, for example, all of the www.xbox.com servers in a production environment (it is noted that all of the www.xbox.com servers in a test environment would be a different service group).

[0015] The production service environment 300, as shown in FIG 3, includes two instances of local application A, as represented by reference numerals 320₁ and 320₂, in service group A 325. Two instances of local application B, 330₁ and 330₂, are in service group B 335. Duplicate instances of local application A, 340i and 340₂, are supported in the duplicate service group A 345 in the test service environment 305. Duplicate instances of local application B, 350₁ and 350₂, are supported in the duplicate service group B 355.

[0016] External resources are also supported in both the production service environment 300 and the test service environment 305. These external resources may include both non-partitioned external resources and partitioned external resources. As used here, a non-partitioned external resource is a service that a local application needs which is outside of itself and is seen as a single entity or "black box." A partitioned external resource is a service that a local application needs which is outside of itself, and for which the local application has a granular view of sub-components, such as individual servers.

[0017] The production service environment 300 includes non-partitioned resources Y and Z, as respectively indicated by reference numerals 360 and 365, and partitioned resources Q/1 and Q/2, as respectively indicated by reference numerals 370 and 375. The test service environment 305 includes duplicate non-partitioned resources Y and Z, as respectively indicated by reference numerals 380 and 385, and duplicate partitioned resources Q/1 and Q/2, as respectively indicated by reference numerals 390 and 395.

[0018] The dependencies between local applications and external resources are shown using the arrows in FIG 3. It is noted that the illustrative map 225 can typically be expected to be dynamic and change as local applications, service groups, and resources are moved on and offline in the service. In addition, additional partitions of a partitioned resource may be dynamically added or removed. Accordingly, the particular local applications, service groups, resources, and their various dependencies and relationships in a particular map at a given time can vary. It may thus be appreciated that the map 225 shown in FIG 3 represents a snapshot of the service 115 as it exists at some arbitrary time.

[0019] FIG 4 is a flowchart of an illustrative method 400 for dynamically discovering applications, external dependencies, and relationships that may move into and out of the enterprise-scale service 115 shown in FIG 2. Practice of the method may facilitate creation of a health map such as the map shown in FIG 3 and then updating of the map to reflect changes as they occur. Data in the map may then be used to make health decisions and raise alerts with root cause identification when faults are detected. The method may be implemented, for example, using the monitoring service 220 that executes on a computing platform such as a server implemented at the operations center 215 (FIG 2). Unless specifically stated, the methods or steps shown in the flowchart in FIG 4 and the taxonomies in FIGs 5-9 and described below are not constrained to a particular order or sequence. In addition, some of the methods or steps thereof can occur or be performed concurrently and not all the methods or steps have to be performed in a given implementation depending on the requirements of such implementation and some methods or steps may be optionally utilized.

[0020] According to the claimed invention, at block 405, a determination is made as to whether a local application is present on a server in the environment. Referring to the taxonomy 500 in FIG 5, this determination may be made using one or more alternative methods. For example, the monitoring service 220 can ask yes/no questions of the monitored servers including if a specific registry key is present (as indicated by reference numeral 505), if a specific file exists on a local file system (510), or if a specific environment variable is set (515).

[0021] Returning back to FIG 4, at block 410, a determination is made as to which service environment a discovered local application belongs. Referring to the taxonomy 600 in FIG 6, this determination may be made using one or more alternative methods. According to the claimed invention, the monitoring service 220 can query the operating system's domain (605), read a string in the registry (610), read a line in a configuration file (615), or read a configuration database (620).

[0022] Returning again to FIG 4, at block 415, discovered objects are instantiated into the health map 225 (FIG 2). Referring to the taxonomy 700 in FIG 7, this determination may be performed using the steps shown. These include, for example, adding the new local application to the health map (710), if the service group associated with that application is not currently in the health map, then adding it to the health map (715), and if the service environment associated with the local application and service group is not currently in the health map, then adding it to the health map (720).

[0023] Returning again to FIG 4, at block 420 discovery of external resources used by a local application is performed. Referring to the taxonomy 800 in FIG 8, this discovery may be made using one or more alternative methods. For example, the monitoring service 220 can enumerate instances of performance counters (805), read a configuration file (810), read a configuration database (815), or evaluate network traffic (820).

[0024] Returning again to FIG 4, at block 425, the external resources are instantiated into the health map if they are not already previously known. At block 430, health indicators for the local applications are monitored. As shown in the taxonomy 900, in FIG 9, and according to the claimed invention, the health indicators may include one or more of the following: events 905, performance counters 910, synthetic transactions 915 (e.g., those transactions implemented using a Lync server), SysLog service events 920, and SNMP service events 925.

[0025] Returning once more to FIG 4, at block 435, the health indicators 900 are attributed to either the health of a local application or the health of an external resource. At block 440, in the event of a fault, then the single root cause alert 230 (FIG 2) can be raised by the monitoring service. At block 445, the service groups and service environments affected by the fault are indicated.

[0026] For example, if non-partitioned external resource Y (element 360 in FIG 3) fails in the production environment 300, then the servers supporting service group A (element 325 in FIG 3) will detect the fault as they have a dependency on that resource. The alert can report that the service group A 325 is impacted, but the service group servers are not the root cause for the failure. In another example, if partition 1 of the partitioned resource Q (element 390 in FIG 3) fails in the test environment 305, all four local applications (i.e., the two instances of local application A and the two instances of local application B) will be impacted, but a single alert should be raised by the monitoring service to the operations center that partition 1 of resource Q is the root cause of the fault. The alert can report that service groups A and B, 345 and 355, in the test environment 305 are both impacted, but are not the root cause of the fault.

[0027] FIG 10 is a simplified block diagram of an illustrative computer system 1000 such as a PC, client device, or server with which the present dynamic discovery of applications, external dependencies, and relationships may be implemented. Computer system 1000 includes a processing unit 1005, a system memory 1011, and a system bus 1014 that couples various system components including the system memory 1011 to the processing unit 1005. The system bus 1014 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory 1011 includes read only memory ("ROM") 1017 and random access memory ("RAM") 1021. A basic input/output system ("BIOS") 1025, containing the basic routines that help to transfer information between elements within the computer system 1000, such as during startup, is stored in ROM 1017. The computer system 1000 may further include a hard disk drive 1028 for reading from and writing to an internally disposed hard disk (not shown), a magnetic disk drive 1030 for reading from or writing to a removable magnetic disk 1033 (e.g., a floppy disk), and an optical disk drive 1038 for reading from or writing to a removable optical disk 1043 such as a CD (compact disc), DVD (digital versatile disc), or other optical media. The hard disk drive 1028, magnetic disk drive 1030, and optical disk drive 1038 are connected to the system bus 1014 by a hard disk drive interface 1046, a magnetic disk drive interface 1049, and an optical drive interface 1052, respectively. The drives and their associated computer- readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1000. Although this illustrative example shows a hard disk, a removable magnetic disk 1033, and a removable optical disk 1043, other types of computer-readable storage media which can store data that is accessible by a computer such as magnetic cassettes, flash memory cards, digital video disks, data cartridges, random access memories ("RAMs"), read only memories ("ROMs"), and the like may also be used in some applications of the present dynamic discovery of applications, external dependencies, and relationships. In addition, as used herein, the term computer-readable storage media includes one or more instances of a media type (e.g., one or more magnetic disks, one or more CDs, etc.). For purposes of this specification and the claims, the phrase "computer-readable storage media" and variations thereof, does not include waves, signals, and/or other transitory and/or intangible communication media.

[0028] A number of program modules may be stored on the hard disk, magnetic disk 1033, optical disk 1043, ROM 1017, or RAM 1021, including an operating system 1055, one or more application programs 1057, other program modules 1060, and program data 1063. A user may enter commands and information into the computer system 1000 through input devices such as a keyboard 1066 and pointing device 1068 such as a mouse. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, trackball, touchpad, touch screen, touch-sensitive module or device, gesturerecognition module or device, voice recognition module or device, voice command module or device, or the like. These and other input devices are often connected to the processing unit 1005 through a serial port interface 1071 that is coupled to the system bus 1014, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus ("USB"). A monitor 1073 or other type of display device is also connected to the system bus 1014 via an interface, such as a video adapter 1075. In addition to the monitor 1073, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The illustrative example shown in FIG 10 also includes a host adapter 1078, a Small Computer System Interface ("SCSI") bus 1083, and an external storage device 1076 connected to the SCSI bus 1083.

[0029] The computer system 1000 is operable in a networked environment using logical connections to one or more remote computers, such as a remote computer 1088. The remote computer 1088 may be selected as another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computer system 1000, although only a single representative remote memory/storage device 1090 is shown in FIG 10. The logical connections depicted in FIG 10 include a local area network ("LAN") 1093 and a wide area network ("WAN") 1095. Such networking environments are often deployed, for example, in offices, enterprise-wide computer networks, intranets, and the Internet.

[0030] When used in a LAN networking environment, the computer system 1000 is connected to the local area network 1093 through a network interface or adapter 1096. When used in a WAN networking environment, the computer system 1000 typically includes a broadband modem 1098, network gateway, or other means for establishing communications over the wide area network 1095, such as the Internet. The broadband modem 1098, which may be internal or external, is connected to the system bus 1014 via a serial port interface 1071. In a networked environment, program modules related to the computer system 1000, or portions thereof, may be stored in the remote memory storage device 1090. It is noted that the network connections shown in FIG 10 are illustrative and other means of establishing a communications link between the computers may be used depending on the specific requirements of an application of dynamic discovery of applications, external dependencies, and relationships.

[0031] FIG 11 shows an illustrative architecture 1100 for a computing platform or device capable of executing the various components described herein for dynamically discovering applications, external dependencies, and relationships. Thus, the architecture 1100 illustrated in FIG 11 shows an architecture that may be adapted for a server computer, mobile phone, a PDA (personal digital assistant), a smartphone, a desktop computer, a netbook computer, a tablet computer, GPS (Global Positioning System) device, gaming console, and/or a laptop computer. The architecture 1100 may be utilized to execute any aspect of the components presented herein.

[0032] The architecture 1100 illustrated in FIG 11 includes a CPU 1102, a system memory 1104, including a RAM 1106 and a ROM 1108, and a system bus 1110 that couples the memory 1104 to the CPU 1102. A basic input/output system containing the basic routines that help to transfer information between elements within the architecture 1100, such as during startup, is stored in the ROM 1108. The architecture 1100 further includes a mass storage device 1112 for storing software code or other computer-executed code that is utilized to implement applications, the file system, and the operating system.

[0033] The mass storage device 1112 is connected to the CPU 1102 through a mass storage controller (not shown) connected to the bus 1110. The mass storage device 1112 and its associated computer-readable storage media provide non-volatile storage for the architecture 1100. Although the description of computer-readable storage media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available computer storage media that can be accessed by the architecture 1100.

[0034] By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable media includes, but is not limited to, RAM, ROM, EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), Flash memory or other solid state memory technology, CD-ROM, DVDs, HD-DVD (High Definition DVD), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the architecture 1100.

[0035] According to various embodiments, the architecture 1100 may operate in a networked environment using logical connections to remote computers through a network. The architecture 1100 may connect to the network through a network interface unit 1116 connected to the bus 1110. It should be appreciated that the network interface unit 1116 also may be utilized to connect to other types of networks and remote computer systems. The architecture 1100 also may include an input/output controller 1118 for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown in FIG 11). Similarly, the input/output controller 1118 may provide output to a display screen, a printer, or other type of output device (also not shown in FIG 11).

[0036] It should be appreciated that the software components described herein may, when loaded into the CPU 1102 and executed, transform the CPU 1102 and the overall architecture 1100 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The CPU 1102 may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the CPU 1102 may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the CPU 1102 by specifying how the CPU 1102 transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the CPU 1102.

[0037] Encoding the software modules presented herein also may transform the physical structure of the computer-readable storage media presented herein. The specific transformation of physical structure may depend on various factors, in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage media, whether the computer-readable storage media is characterized as primary or secondary storage, and the like. For example, if the computer-readable storage media is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable storage media by transforming the physical state of the semiconductor memory. For example, the software may transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. The software also may transform the physical state of such components in order to store data thereupon.

[0038] As another example, the computer-readable storage media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope of the present description, with the foregoing examples provided only to facilitate this discussion.

[0039] In light of the above, it should be appreciated that many types of physical transformations take place in the architecture 1100 in order to store and execute the software components presented herein. It also should be appreciated that the architecture 1100 may include other types of computing devices, including hand-held computers, embedded computer systems, smartphones, PDAs, and other types of computing devices known to those skilled in the art. It is also contemplated that the architecture 1100 may not include all of the components shown in FIG 11, may include other components that are not explicitly shown in FIG 11, or may utilize an architecture completely different from that shown in FIG 11.

[0040] Based on the foregoing, it should be appreciated that technologies for dynamically discovering applications, external dependencies, and relationships are disclosed. Although the subject matter presented herein has been described in language specific to computer structural features, methodological and transformative acts, specific computing machinery, and computer-readable storage media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts, and mediums are disclosed as example forms of implementing the claims.

[0041] The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the scope of the present invention, which is set forth in the following claims.

Claims

1. A computer-implemented method for dynamically discovering applications running on servers, the method comprising the steps of:

performing, via a monitoring service (220), a query to discover (405) if a local application is present on a server, the local application being a single instance of an application running on a single server;

determining (410) a service environment (115) to which the discovered local application belongs via the monitoring service using one of: querying an operating system's domain (605), reading a string in a registry (610), reading a line in a configuration file (615), or reading a configuration database (620), wherein the service environment is a group of service groups that serve a common consumer, a service group being a group of local applications that provide a common function to the common consumer;

adding or removing (415) discovered local applications, service groups, and service environments as objects in a health map (225), wherein the health map is dynamically updated by including objects as they are added to and deleted from an enterprise-scale service environment and wherein at any time the health map represents a snapshot of the service environment (115);

adding (425) external resources as objects to the health map if they are not already known;

monitoring (430), via the monitoring service, health indicators for the discovered local applications, service groups, service environments and external resources;

attributing (435) the health indicators to either health of a local application or health of an external resource and dynamically updating the health map; and

based on the attributed monitored health indicators in the health map identifying one or more faults in the service environment;

wherein the health indicators include at least one of events, performance counters, synthetic transactions, SysLog service events, or Simple Network Management Protocol, SNMP, service events.

2. The method of claim 1 further including a step of
raising (440) a single root cause alert (230) to indicate the or each fault, the alert being attributable to either a local application or an external resource.

3. The method of claim 2 further including a step of
indicating (445) which of the service groups and service environments are impacted by the fault.

4. The method of claim 1 in which the external resources comprise non-partitioned external resources, the non-partitioned external resources being implemented through a service upon which the local application relies and which the local application observes as either a single entity or a black box.

5. The method of claim 1 in which the external resources comprise partitioned external resources, the partitioned external resources being implemented through a service upon which the local application relies and having sub-components that are observable by the local application.

6. The method of claim 1 further including a step of discovering (420) additions and deletions of partitioned external resources or non-partitioned external resources.

7. The method of claim 6 in which the discovering (420) comprises one of enumerating (805) performance counter instances, reading (810) a configuration file, reading (815) a configuration database, or evaluating (820) network traffic.

8. The method of claim 1 in which the step of adding or removing (415) comprises one of adding (710) a new local application to the health map, adding (715) a service group to the health map if the service group is not already a member of the health map, or adding (720) a service environment to the health map if the service environment is not already a member of the health map.

9. Computer-readable storage media storing computer-readable instructions which, when executed by a processing unit (1005; 1102) of a computer system (1000; 1100), causes the computer system to perform the method of any preceding claim.

Ansprüche

1. Computerimplementiertes Verfahren zum dynamischen Ermitteln von Anwendungen, die auf Servern laufen, wobei das Verfahren die folgenden Schritte umfasst:

Durchführen einer Abfrage über einen Überwachungsdienst (220), um zu ermitteln (405), ob eine lokale Anwendung auf einem Server vorhanden ist, wobei die lokale Anwendung eine einzelne Instanz einer Anwendung ist, die auf einem einzelnen Server läuft;

Bestimmen (410) über den Überwachungsdienst einer Dienstumgebung (115), zu der die ermittelte lokale Anwendung gehört, unter Verwendung eines der Folgenden:
Abfragen der Domäne eines Betriebssystems (605), Lesen einer Zeichenfolge in einer Registrierung (610), Lesen einer Zeile in einer Konfigurationsdatei (615) oder Lesen einer Konfigurationsdatenbank (620), wobei die Dienstumgebung eine Gruppe von Dienstgruppen ist, die einen gemeinsamen Verbraucher bedienen, wobei eine Dienstgruppe eine Gruppe von lokalen Anwendungen ist, die dem gemeinsamen Verbraucher eine gemeinsame Funktion bereitstellen;

Hinzufügen oder Entfernen (415) ermittelter lokaler Anwendungen, Dienstgruppen und Dienstumgebungen als Objekte in einer Zustandsabbildung (225), wobei die Zustandsabbildung dynamisch aktualisiert wird, indem Objekte eingeschlossen werden, wenn sie zu einer unternehmensweiten Dienstumgebung hinzugefügt und aus dieser gelöscht werden, und wobei die Zustandsabbildung zu jedem Zeitpunkt eine Momentaufnahme der Dienstumgebung (115) darstellt;

Hinzufügen (425) von externen Ressourcen als Objekte zur Zustandsabbildung, wenn sie nicht bereits bekannt sind;

Überwachen (430) von Zustandsindikatoren für die ermittelten lokalen Anwendungen, Dienstgruppen, Dienstumgebungen und externen Ressourcen über den Überwachungsdienst;

Zuordnen (435) der Zustandsindikatoren entweder zum Zustand einer lokalen Anwendung oder zum Zustand einer externen Ressource und dynamisches Aktualisieren der Zustandsabbildung; und

basierend auf den zugeordneten überwachten Zustandsindikatoren in der Zustandsabbildung, die einen oder mehrere Fehler in der Dienstumgebung identifizieren;

wobei die Zustandsindikatoren mindestens eines von Ereignissen, Leistungszählern, synthetischen Transaktionen, SysLog-Dienstereignissen oder Simple Network Management Protocol (SNMP)-Dienstereignissen einschließen.

2. Verfahren nach Anspruch 1, weiter einschließend den Schritt des
Auslösens (440) einer einzelnen Grundursachenwarnung (230), um den oder jeden Fehler anzuzeigen, wobei die Warnung entweder einer lokalen Anwendung oder einer externen Ressource zuordenbar ist.

3. Verfahren nach Anspruch 1, weiter einschließend den Schritt des
Anzeigens (445), welche der Dienstgruppen und Dienstumgebungen von dem Fehler betroffen sind.

4. Verfahren nach Anspruch 1, wobei die externen Ressourcen nicht-partitionierte externe Ressourcen umfassen, wobei die nicht-partitionierten externen Ressourcen durch einen Dienst implementiert werden, auf den die lokale Anwendung angewiesen ist und den die lokale Anwendung entweder als einzelne Einheit oder als Blackbox beobachtet.

5. Verfahren nach Anspruch 1, wobei die externen Ressourcen partitionierte externe Ressourcen umfassen, wobei die partitionierten externen Ressourcen durch einen Dienst implementiert werden, auf den die lokale Anwendung angewiesen ist, und Unterkomponenten aufweisen, die von der lokalen Anwendung beobachtet werden können.

6. Verfahren nach Anspruch 1, das weiter einen Schritt zum Ermitteln (420) von Hinzufügungen und Löschungen von partitionierten externen Ressourcen oder nicht-partitionierten externen Ressourcen einschließt.

7. Verfahren nach Anspruch 6, wobei das Ermitteln (420) eines von Aufzählen (805) von Leistungszählerinstanzen, Lesen (810) einer Konfigurationsdatei, Lesen (815) einer Konfigurationsdatenbank oder Auswerten (820) des Netzwerkdatenverkehrs umfasst.

8. Verfahren nach Anspruch 1, wobei der Schritt des Hinzufügens oder Entfernens (415) eines von Hinzufügen (710) einer neuen lokalen Anwendung zur Zustandsabbildung, Hinzufügen (715) einer Dienstgruppe zur Zustandsabbildung, wenn die Dienstgruppe nicht bereits Mitglied der Zustandsabbildung ist, oder Hinzufügen (720) einer Dienstumgebung zur Zustandsabbildung, wenn die Dienstumgebung nicht bereits Mitglied der Zustandsabbildung ist.

9. Computerlesbares Speichermedium, das computerlesbare Anweisungen speichert, die, wenn sie von einer Verarbeitungseinheit (1005; 1102) eines Computersystems (1000; 1100) ausgeführt werden, das Computersystem veranlassen, das Verfahren nach einem der vorstehenden Ansprüche durchzuführen.

Revendications

1. Procédé mis en œuvre par ordinateur pour découvrir de manière dynamique des applications s'exécutant sur des serveurs, le procédé comprenant les étapes consistant à :

effectuer, via un service de surveillance (220), une requête pour découvrir (405) si une application locale est présente sur un serveur, l'application locale étant une instance unique d'une application s'exécutant sur un serveur unique ;

déterminer (410) un environnement de services (115) auquel appartient l'application locale découverte via le service de surveillance en utilisant une des étapes suivantes : requérir un domaine de système d'exploitation (605), lire une chaîne dans un registre (610), lire une ligne dans un fichier de configuration (615), ou lire une base de données de configuration (620), dans lequel l'environnement de services est un groupe de groupes de services qui desservent un consommateur commun, un groupe de services étant un groupe d'applications locales qui fournissent une fonction commune au consommateur commun ;

ajouter ou supprimer (415) des applications locales découvertes, des groupes de services et des environnements de services en tant qu'objets dans une carte sanitaire (225), dans lequel la carte sanitaire est mise à jour de manière dynamique en incluant des objets lorsqu'ils sont ajoutés à et supprimés d'un environnement de services à l'échelle de l'entreprise et dans lequel à tout moment la carte sanitaire représente un instantané de l'environnement de services (115) ;

ajouter (425) des ressources externes en tant qu'objets à la carte sanitaire si elles ne sont pas déjà connues ;

surveiller (430), via le service de surveillance, des indicateurs sanitaires pour les applications locales découvertes, les groupes de services, les environnements de services et les ressources externes ;

attribuer (435) les indicateurs sanitaires à la santé d'une application locale ou à la santé d'une ressource externe et mettre à jour de manière dynamique la carte sanitaire ; et

sur la base des indicateurs sanitaires surveillés attribués dans la carte sanitaire, identifier un ou plusieurs défauts dans l'environnement de services ;

dans lequel les indicateurs sanitaires incluent au moins certains parmi des événements, des compteurs de performance, des transactions synthétiques, des événements de services SysLog ou des événements de services à protocole de gestion de réseau simple, SNMP.

2. Procédé selon la revendication 1, incluant en outre une étape consistant à
déclencher (440) une alerte de cause première unique (230) pour indiquer le ou chaque défaut, l'alerte étant attribuable soit à une application locale soit à une ressource externe.

3. Procédé selon la revendication 2, incluant en outre une étape consistant à
indiquer (445) lesquels des groupes de services et des environnements de services sont affectés par le défaut.

4. Procédé selon la revendication 1, dans lequel les ressources externes comprennent des ressources externes non partitionnées, les ressources externes non partitionnées étant mises en œuvre via un service sur lequel s'appuie l'application locale et que l'application locale observe soit comme une entité unique soit comme une boîte noire.

5. Procédé selon la revendication 1, dans lequel les ressources externes comprennent des ressources externes partitionnées, les ressources externes partitionnées étant mises en œuvre via un service sur lequel s'appuie l'application locale et présentant des souscomposants qui peuvent être observées par l'application locale.

6. Procédé selon la revendication 1, incluant en outre une étape de découverte (420) d'ajouts et de suppressions de ressources externes partitionnées ou de ressources externes non partitionnées.

7. Procédé selon la revendication 6, dans lequel la découverte (420) comprend une parmi une énumération (805) d'instances de compteur de performance, une lecture (810) d'un fichier de configuration, une lecture (815) d'une base de données de configuration, ou une évaluation (820) de trafic de réseau.

8. Procédé selon la revendication 1, dans lequel l'étape consistant à ajouter ou supprimer (415) comprend un ajout (710) d'une nouvelle application locale à la carte sanitaire, un ajout (715) d'un groupe de services à la carte sanitaire si le groupe de services n'est pas déjà un membre de la carte sanitaire, ou un ajout (720) d'un environnement de services à la carte sanitaire si l'environnement de services n'est pas déjà membre de la carte sanitaire.

9. Support de stockage lisible par ordinateur stockant des instructions lisibles par ordinateur qui, lorsqu'elles sont exécutées par une unité de traitement (1005 ; 1102) d'un système informatique (1000; 1100), amènent le système informatique à exécuter le procédé de l'une quelconque des revendications précédentes.

Drawing