SERVER AND APPLICATION MONITORING

Abstract

A system for monitoring server and application events, metrics or topology of an airport management system in a cloud infrastructure environment. The adapter can be coupled to a vROPS API of the cloud infrastructure environment and arranged to issue requests for data to the network via the vROPS API. The adapter can include a means for issuing multiple initial requests. The adapter can include a means for receiving initial responses to the multiple initial requests. The adapter can include a means for issuing multiple subsequent requests in response to each initial response. The adapter can include a means for receiving subsequent responses to the subsequent requests. The adapter can include a means for processing the subsequent responses related to each resource ID to provide events, metrics or topology information. The adapter can include a means for delivering the events, metrics or topology information to a user display system.

Claims

1. A system for monitoring server and application events, metrics or topology of a an airport management system in a cloud infrastructure environment, comprising: an adapter configured to couple to a vROPS API of the cloud infrastructure environment and arranged to issue requests for data to the network via the vROPS API, wherein the adapter includes: means for issuing multiple initial requests, each initial request being for resource IDs of resources; means for receiving initial responses to the multiple initial requests, each initial response including at least resource IDs of the resources; means for issuing multiple subsequent requests in response to each initial response, each subsequent request including one of the resource IDs and being for additional data; means for receiving subsequent responses to the subsequent requests, the subsequent responses including the resource ID and additional data; means for processing the subsequent responses related to each resource ID to provide events, metrics or topology information; and means for delivering the events, metrics or topology information to a user display system.

2. A system according to claim 1, wherein the initial requests are for events and are for resource IDs and event IDs.

3. A system according to claim 2, wherein the additional data comprises event details comprising one or more of host name, event name or event text.

4. A system according to claim 1, 2 or 3, wherein the initial requests are for performance information and are for resource IDs and details of virtual machines of the computer network.

5. A system according to claim 4, wherein the additional data comprises objects of the virtual machines.

6. A system according to claim 5, wherein the additional data comprises metrics of the objects.

7. A system according to claim 6, wherein the means for issuing multiple subsequent requests includes means for querying a list of objects on the cloud infrastructure environment and issuing the subsequent requests based on the list of objects.

8. A system according to any preceding claim, wherein the initial requests are for topology information and are for resource IDs and details of virtual machines of the cloud infrastructure environment.

9. A system according to claim 8, wherein the additional data comprises information related to the virtual machines.

10. A system according to claim any preceding claim, wherein the requests are issued as multiple threads to the cloud infrastructure environment such that multiple requests are handled in parallel.

11. A method for monitoring server and application events, metrics or topology of an airport management system in a cloud infrastructure environment, comprising: operating a request process to a vROPS API of the cloud infrastructure environment, wherein the request process includes: issuing multiple initial requests, each initial request being for resource IDs of resources; receiving initial responses to the multiple initial requests, each initial response including at least resource IDs of the resources; issuing multiple subsequent requests in response to each initial response, each subsequent request including one of the resource IDs and being for additional data; receiving subsequent responses to the subsequent requests, the subsequent responses including the resource ID and additional data; processing the subsequent responses related to each resource ID to provide events, metrics or topology information; and delivering the events, metrics or topology information to a user display system.

12. A method according to claim 11, wherein the initial requests are for events and are for resource IDs and event IDs.

13. A method according to claim 12, wherein the additional data comprises event details comprising one or more of host name, event name or event text.

14. A method according to claim 11, 12 or 13, wherein the initial requests are for performance information and are for resource IDs and details of virtual machines of the computer network.

15. A computer program comprising code which when executed on a computer undertakes the method of any of claims 11 to 14.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

[0015] FIG. 1 is an overview of the high-level architecture of a monitoring system referred to as SITA's OSSHub;

[0016] FIG. 2 shows at high level an adapter embodying the invention referred to as the vROPS adapter with the monitoring system SITA's OSSHub;

[0017] FIG. 3 shows the monitoring system OSSHub to Cloud 2 vROPS API connectivity using the adapter embodying the invention;

[0018] FIG. 4 shows Smarts topology Data flow diagram;

[0019] FIG. 5 shows the architecture of SITA Smarts vROPS topology adapter embodying the invention;

[0020] FIG. 6 shows events referred to as ROSS events as seen by the SITA command centre SCC when using the invention;

[0021] FIG. 7 shows Smarts events data flow diagram;

[0022] FIG. 8 shows the architecture of SITA Smarts vROPS using an events adapter embodying the invention;

[0023] FIG. 9 shows ROSS events view as seen by the SITA command centre SCC when using the invention;

[0024] FIG. 10 shows the performance metrics, APG/M&R metrics, data flow diagram;

[0025] FIG. 11 shows the architecture of SITA VMware APG vROPS performance metrics adapter embodying the invention;

[0026] FIG. 12 is a flow diagram showing an example process for obtaining CPU metrics; and

[0027] FIG. 13 shows an illustration of data presented in APG to a user.

DETAILED DESCRIPTION

[0028] An embodiment of the invention provides a tool to facilitate monitoring of performance of an airport management system, in particular server and application performance.

[0029] The embodiment described provides various advantages by providing adapters for a particular environment. As an example, the embodiment allows a central visualisation and proactive fault management of an environment such as the cloud based SITA environment through existing tools used by an existing command centre for 24-hour monitoring.

[0030] The embodiment of the invention focuses on the vROPS integration into VMware Smarts & APG products (FIG. 2). The adapter uses the TCP/IP protocol on port 443 to interrogate the vROPS API located in a cloud environment. Using REST API posts to issue commands to return required data. The invention could be applicable to other infrastructures.

[0031] The role of the adapters is important for providing proactive fault monitoring for customers hosted in the cloud infrastructure and feeding events of over 4000 hosts to the SITA SCC using OSSHub as their monitoring tool, where 24×7 support is provided.

[0032] In a particular use case, a customer may experience issues with their systems. Proactive monitoring may highlight systems becoming stressed, giving the operations time to remediate the issue before it became a system failure. Without using the adapters embodying the invention, this would not be possible.

[0033] The adapter provides the ability to trend system utilisation by way of APG (Advanced Performance Grapher) performance reports. This gives the advantage of analysing for future system resource requirements. This can be used in terms of CPU, memory & disk utilisation, highlighting potential system resource increases.

[0034] The embodiment described in relation to FIGS. 1 to 13 is one example, but in general the embodiment provides monitoring of servers and applications using an adapter to generate calls into a system via an API.

[0035] FIG. 1 shows the main components of an arrangement to which the invention may be applied. A monitoring system 10 comprising a collection of tools is arranged to monitor a virtualised infrastructure 12 here deployed on a cloud environment. The monitoring system allows monitoring of the cloud infrastructure and virtual machines. Such an arrangement may have various connectivity to extract certain information from the virtualised infrastructure 12 to the monitoring system 10. However, as previously noted, the inventors appreciated that there are no adapters available to integrate certain specific aspects of virtualised infrastructure in order to provide effective monitoring of events and performance.

[0036] FIG. 2 shows the arrangement at FIG. 1 but now showing the use of an adapter embodying the invention arranged to pull events and metric data into the monitoring system OSSHub. The adapter 14 is shown schematically by the requests HTTPS/TCP/443 shown retrieving information via an API to VMware Smarts and APG. Smarts is the fault management sub-system & APG is the performance management system of the monitoring system 10. The invention could be applicable to other technologies. The processes provided by the adapter 14 will be described in greater detail later. The use of vROPS API is of particular note. VMware vRealize Operations (vROPS) is a tool that allows operations management from apps to infrastructure to optimize, plan and scale hybrid cloud and HCl deployments while unifying multi-cloud monitoring. However, we have appreciated that this tool may also be used as part of an external monitoring system, such as OSSHub, to facilitate monitoring of events, metrics or performance. This is achieved using an arrangement of initial requests and multiple subsequent requests as described below.

[0037] A specific example of an adapter connecting to an aspect of the cloud infrastructure is shown in FIG. 3. The adapter 14 is arranged to issue one or more API calls via a network to a specific server within the cloud infrastructure here shown as the vROPS server 16. The call is made on a particular port TCP/443. This arrangement provides security in that a specific port is selected and rendered accessible to the adapter 14 that is arranged to issue repeated API calls as described later. The adapter 14 may be deployed in various ways depending upon the aspect of the infrastructure to be monitored. A particular advantage of the adapter arrangement is the ability to gather data that may be used to gather Topology information for a network, event information for proactive fault management and performance metrics. As previously noted, come onto all of the use cases is the way in which one or more initial calls are supplemented by subsequent calls such that the adapter provides appropriate information to a monitoring system. In effect, the adapter allows the monitoring system to gather data needed for performance management using a vROPS API in a new manner by an arrangement of multiple requests. The reason for issuing multiple requests depends upon the nature of the resource being monitored. As an example, hardware such as a kiosk, hard disk, printer or the like may have multiple instances, each having their own unique resource ID. Multiple requests may be needed to gather data collectively from the multiple instances. A key reason for issuing multiple requests, though, is that the initial request may provide insufficient data and so a determination is made to issue further requests in relation to the same resource ID.

[0038] The arrangement of an adapter to monitor Topology will first be described with relation to FIGS. 4 and 5. FIG. 4 shows a flow diagram of the arrangement whilst FIG. 5 is a block diagram of the main components. As shown in FIG. 5, the adapter for the specific scenario of Topology information referred to as Smarts adapter 14, can explore an API deployed using Smarts Perl to a Smarts ESM (EMC Server Manager) 18 and in turn to SAM 20 and OI 22. SAM is Service Assurance Manager or event aggregator & console OI is Open Integration platform or integration point to gather data from other sources These are both aspects of the monitoring system 10. The adapter 14 also connects via the vROPS API 24 to provide information to the monitoring system. In this way, the adapter 14 uses the API 24 as part of the arrangement to gather information. The API command used may be a REST API command that gathers properties as follows:

[0039] Topology properties are gathered via REST API command:

TABLE-US-00001 https://host/suite-api/api/resources/${resource_id}/properties summary|parentDatacenter summary|parentCluster summary|parentVcenter summary|parentHost ops:property|ip_address ops:propertyconfig|guestFullName Additional topology data is acquired via REST API post: https://host/suite-api/api/resources?resourceKindKey=VirtualMachine&pageSize=−1 getAttribute|identifier ops:resourceKindKey ops:name

[0040] The process operated by the adapter 14 of FIG. 5 is shown in FIG. 4. At step 40 the adapter waits to determine whether data is received at step 42 from any previous request. If data is determined to be received at determining step 42 then data is collected at step 43, acquired at step 44 and a determination made at determining step 45 as to whether a poll for supplementary data is required. If supplementary data is required, then a further request for data is made. if no further data is needed then the data received is provided to data storage 46 processed into Smart step Topology data at step 47 stored in database 48 and then provided to a user interface at step 49. If it is determined that further data is needed at step 45 then a further poll for data is issued by the API at step 41 and the adapter then waits to determine if data is received at step 42. The loop provided by the initial request for data and supplementary request for data determined at step 45 provides the advantage that the adapter performs the function of aggregating data so as to provide information to the monitoring system. An example of the view of information received is shown in FIG. 6 which shows Topology information passed into Smarts ESM Extended Server Manager and used in the Smarts Topology view.

[0041] An adapter arranged for event gathering for performance management is described in relation to FIGS. 7 and 8. Like components are given the same numbering as previously described. Here, the adapter 14 deployed as a Smarts events adapter connects to SAM 20 and OI 22 and also to vROPS API 24. The gathering process for events is shown in FIG. 7. At an initial wait step 70 the adapter waits to see if data is received from a previous request at determining step 72. After the wait a request is issued at step 71 for events. If data is received at step 72 then the event data is collected at step 73 and acquired at step 74. At determining step 75 a determination is made whether supplementary data is needed. If yes, then a further request is issued and the process repeated. If not then the data acquired at step 74 is passed to event processing in Smarts at step 76 and stored in a live data update store at step 77 for display on a user display 78. As with the previous example, the loop provided by acquisition of data repeatedly provides appropriate and useful information to the monitoring system by aggregating event information together.

[0042] An example display of the event view provided by the information gathered by the event adapter is shown in FIG. 9.

[0043] To gather the event information alerts are interrogated via REST API command:

TABLE-US-00002  https://host/suite-api/api/alerts/query API call payload: <ops:alert-query compositeOperator=\“AND\” xmlns:xs=\“http://www.w3.org/2001/XMLSchema\” xmlns:xsi=\“http://www.w3.org/2001/XMLSchema-instan ce\” xmlns:ops=\“http://webservice.vmware.com/vRealizeOpsMgr/1.0/\”>    <ops:alertId></ops:alertId>    <ops:resource-query>    <ops:resourceId>${resource_id}</ops:resourceId>    <ops:statKeyInclusive>true</ops:statKeyInclusive>    </ops:resource-query>    <ops:activeOnly>true</ops:activeOnly>   >ops:alertCriticality>    <ops:alertCriticality>CRITICAL</ops:alertCriticality>    <ops:alertStatus></ops:alertStatus>    <ops:alertImpact></ops:alertImpact>    <ops:alertControlState></ops:alertControlState> <ops:includeChildrenResources>true</ops:includeChildrenResources>    </ops:alert-query>

[0044] The third example of data gathering provided by the API is shown in FIGS. 11 and 10. As shown in FIG. 11, an adapter 14 is arranged to gather information and provided via API 24 to the user in the form of the monitoring system. The adapter 14 connects to an M&R stream collector 26 which in turn connects to an M &R backend 28 and an M& R database 30. The database is also accessible by an M& R frontend 32. M & R (Monitoring & Reporting) Stream XML collector module provides the direct interface from the TCP/IP data stream, the backend module, takes the data from the XML collector and processes to subsequently add the data into the database module. M & R Frontend module provides the user presentation display.

[0045] FIG. 10 shows the process for gathering the performance metrics using the adapter. At step 100 the adapter waits to see if data is received from a previous request at step 102. If data is required, then a request is posted via API at step 101. If data is received as determined at step 102 it is collected at step 103 and acquired at step 104. At step 105 a determination is made as to whether to poll for supplementary data. If yes, then a further request is issued at step 101 and the process repeated including waiting at step 100 and determining if further data is received at step 102. If no further data is required then the data acquired at step 104 is then passed to storage 106 and processed into APG at step 108. The processing into APG is a built in XML adapter pushing the data gathered through the API into the Datastore. Any supplementary enrichment data from ROSS (Rapid Operational Support System—single pain of glass view operational console for SCC which holds all the multitenant and model information) is received at step 107 and the data thus acquired provided to database storage 109 and subsequently to a user display on the monitoring system at step 110.

[0046] To Gather Data

[0047] Virtual Machine Metrics:

[0048] Metrics are gathered via several API commands:

TABLE-US-00003 https://host/suite-api/api/resources/stats/latest?resourceId=${resource_id} https://host/suite-api/api/resources?resourceKindKey=VirtualMachine&pageSize=−1 https://host/suite-api/api/resources/$(resource_id}/properties /suite-api/api/resources/${resource_id}/relationships

[0049] As with the two prior examples, the repeated request and re-request is important in gathering the information needed for the monitoring system.

[0050] A worked example showing the specifics of initial acquisition and subsequent acquisitions common to all three of the examples above is shown in FIG. 12. The adapter is arranged to initially wait for a period at step 1201 to then receive data from any previous requests at step 1202. At determining step 1203 a check is repeatedly made as to whether data is received. If yes, the data is collected at step 1204. An initial acquisition of data is performed at step 1206 being the acquisition in response to an initial request. If the data acquisition is deemed successful at step 1207 then no further request is needed and the process ends at step 1208. However, more typically the information received in an initial request will not be sufficient and for that purpose the event has a processing loop to issue a further request using the resource ID of the event just acquired at step 1209. Data is collected at step 1205 to re-request another instance or more data, and the request for data posted to the API at step 1202. This loop is repeated for multiple initial requests and subsequent requests related to the initial requests using the resource ID as a mechanism to gather further data related to each event. At step 1210 if it is deemed at decision step 1210 that acquisition has been successful the process ends at 1211. If it is determined that further information is needed on a base object then step 1212 causes a further request to be issued. The base object can be the sub-object of the host VM, which again uses the resource ID to pull the correct associated object data. At step 1213 may be determined that acquisition of data has been completed and the process ends at step 1214. On the other hand, if further information is required in relation to CPU metrics at step 1215, a further request may be issued to collect data at step 1205 and an API request is viewed at step 1202. This causes the loop to repeat. Finally, at step 1216 the data received by the initial request and any subsequent requests is gathered and processed into APG at step 1218 and any additional enrichment data from ROSS is gathered at step 1217. Finally, the event details and additional data relating to each resource ID is gathered in database storage 1219 to provide to the monitoring system by way of a user interface or dashboard at 1220.

[0051] As can be seen from the specific example of FIG. 12, the system embodying the invention uses an adapter that issues multiple initial requests and multiple subsequent requests in response to each initial response to an initial request, to aggregate information together using the resource ID of information provided in response to an initial request. In this way, the adapter cannot simply provide the events to the monitoring system but actually aggregates information together in a way that the monitoring system can then process.

[0052] FIG. 13 shows how performance metrics may be displayed as a result of the operation of the processes embodying the invention.

[0053] Further features of embodiments of the invention are set out on the following clauses: [0054] 1. A system for monitoring server and application events, metrics or topology of a an airport management system in a cloud infrastructure environment, comprising: [0055] an adapter configured to couple to a vROPS API of the cloud infrastructure environment and arranged to issue requests for data to the network via the vROPS API, wherein the adapter includes: [0056] means for issuing multiple initial requests, each initial request being for resource IDs of resources; [0057] means for receiving initial responses to the multiple initial requests, each initial response including at least resource IDs of the resources; [0058] means for issuing multiple subsequent requests in response to each initial response, each subsequent request including one of the resource IDs and being for additional data; [0059] means for receiving subsequent responses to the subsequent requests, the subsequent responses including the resource ID and additional data; [0060] means for processing the subsequent responses related to each resource ID to provide events, metrics or topology information; and [0061] means for delivering the events, metrics or topology information to a user display system. [0062] 2. A system according to clause 1, wherein the initial requests are for events and are for resource IDs and event IDs. [0063] 3. A system according to clause 2, wherein the additional data comprises event details comprising one or more of host name, event name or event text. [0064] 4. A system according to clause 1, 2 or 3, wherein the initial requests are for performance information and are for resource IDs and details of virtual machines of the computer network. [0065] 5. A system according to clause 4, wherein the additional data comprises objects of the virtual machines. [0066] 6. A system according to clause 5, wherein the additional data comprises metrics of the objects. [0067] 7. A system according to clause 6, wherein the means for issuing multiple subsequent requests includes means for querying a list of objects on the cloud infrastructure environment and issuing the subsequent requests based on the list of objects. [0068] 8. A system according to any preceding clause, wherein the initial requests are for topology information and are for resource IDs and details of virtual machines of the cloud infrastructure environment. [0069] 9. A system according to clause 8, wherein the additional data comprises information related to the virtual machines. [0070] 10. A system according to clause any preceding clause, wherein the requests are issued as multiple threads to the cloud infrastructure environment such that multiple requests are handled in parallel. [0071] 11. A method for monitoring server and application events, metrics or topology of an airport management system in a cloud infrastructure environment, comprising: [0072] operating a request process to a vROPS API of the cloud infrastructure environment, wherein the request process includes: [0073] issuing multiple initial requests, each initial request being for resource IDs of resources; [0074] receiving initial responses to the multiple initial requests, each initial response including at least resource IDs of the resources; [0075] issuing multiple subsequent requests in response to each initial response, each subsequent request including one of the resource IDs and being for additional data; [0076] receiving subsequent responses to the subsequent requests, the subsequent responses including the resource ID and additional data; [0077] processing the subsequent responses related to each resource ID to provide events, metrics or topology information; and [0078] delivering the events, metrics or topology information to a user display system. [0079] 12. A method according to clause 11, wherein the initial requests are for events and are for resource IDs and event IDs. [0080] 13. A method according to clause 12, wherein the additional data comprises event details comprising one or more of host name, event name or event text. [0081] 14. A method according to clause 11, 12 or 13, wherein the initial requests are for performance information and are for resource IDs and details of virtual machines of the computer network. [0082] 15. A method according to clause 14, wherein the additional data comprises objects of the virtual machines. [0083] 16. A method according to clause 15, wherein the additional data comprises metrics of the objects. [0084] 17. A method according to clause 16, wherein the issuing multiple subsequent requests includes querying a list of objects on the cloud infrastructure environment and issuing the subsequent requests based on the list of objects. [0085] 18. A method according to any of clauses 11 to 17, wherein the initial requests are for topology information and are for resource IDs and details of virtual machines of the cloud infrastructure environment. [0086] 19. A method according to clause 18, wherein the additional data comprises information related to the virtual machines. [0087] 20. A method according to of clauses 11 to 19, wherein the requests are issued as multiple threads to the cloud infrastructure environment such that multiple requests are handled in parallel. [0088] 21. A computer program comprising code which when executed on a computer undertakes the method of any of clauses 11 to 20.