Patent Application
20060189330
The term Operations Support System (OSS) generally refers to a system (or systems) that performs management, inventory, engineering, planning, and repair functions for communications service providers and their networks. Originally, OSS's were mainframe-based, stand-alone systems designed to support telephone company staff members in their daily jobs by automating manual processes, making operation of the network more error-free and efficient. Today's OSS's manage an increasingly complex set of products and services in a dynamic, competitive marketplace helping service providers maximize their return on investment (ROI) in one of their key assets-information. The ultimate goal of OSS's is to enable service providers to reduce costs, provide superior customer service, and accelerate their time to market for new products and services.
OSS's, such as the AGILENT QoS Manager, model the topography of the system under test and collect a variety of data describing the state of and activity on the system under test. Data can be gathered from individual applications, servers, network links and networking equipment. In general, the data comprises a stream of scalar values which are stored and analyzed by the OSS's. The values are used to produce graphics describing the operation of the system under test. Such graphics may include graphs and charts, from which a trained user may assess end-to-end service performance. For example, displays may be formulated that provide an indication of whether the service provider is adhering to service level agreements with subscribers.
Taking the AGILENT QOS MANAGER as an example, displays of data usually take the form of a graph or chart. Some examples include, line graph, bar chart, stacked bar chart, health, and histograms (usually presented as a bar chart). Navigation through the various displays is usually facilitated using a graphical interface comprising a hierarchical tree that models the services provided by the network under test. Organization of the tree may be based on the type of measurement, the type of service or the piece of equipment being monitored or some combination thereof. The user navigates the tree structure and selects an aspect of a network to be displayed.
For example. a user may select a server on a top level of the hierarchial tree and be presented with several selectable categories, for example Web Services; TopN Critical Test; and Service Level Agreement Test. If the user selects the Web Services node, he may be asked to select from a set of sub-nodes, for example: Service Metrics; Http Servers; and TopN Response Time. Under the Service Metrics node a set of nodes that bring up graphs that provide indications of the availability of the system, for example Http Availability and Http Total Response Time.
In the past, the type of graph displayed is pre-determined for a particular display node on the tree. Thus, there was no easy way to generate a different type of graph for the same data. Further, known systems limit the types of graphs based on the type of measurement semantic. For example, measurement values are only displayed as measurement values; state information is only displayed as state values; and TopN measurement data is only displayed as TopN measurement data. No known system permits a user to display collected data in a different form other than the default forms. For example, no mechanism exists to permit a user to view a measurement data as health states. Similarly, no mechanism exists to permit a user to easily switch between related graphs, such as parent nodes, child nodes, or underlying data without navigating the tree structure.
Accordingly, the present inventors have recognized a need for new methods for permitting a user to view measurement data in multiple forms using a simple navigation process.
An understanding of some embodiments of the present invention can be gained from the following detailed description, taken in conjunction with the accompanying drawings of which:
a, 11b, and 11c are representations of displays in accordance with an embodiment of the present invention.
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout. The detailed description which follows presents methods that may be embodied by routines and symbolic representations of operations of data bits within a computer readable medium, associated processors, general purpose personal computers and the like. These descriptions and representations are the means used by those skilled in the art effectively convey the substance of their work to others skilled in the art.
A method is here, and generally, conceived to be a sequence of steps or actions leading to a desired result, and as such, encompasses such terms of art as “routine,” “program,” “objects,” “functions,” “subroutines,” and “procedures.” The methods recited herein may operate on a general purpose computer or other network device selectively activated or reconfigured by a routine stored in the computer and interface with the necessary signal processing capabilities. More to the point, the methods presented herein are not inherently related to any particular device; rather, various devices may be used to implement the claimed methods. Machines useful for implementation of the described embodiments of the present invention include those manufactured by such companies as AGILENT TECHNOLOGIES, INC. and HEWLETT PACKARD, as well as other manufacturers of computer and network equipment.
With respect to the software described herein, those of ordinary skill in the art will recognize that there exist a variety of platforms and languages for creating software for performing the methods outlined herein. The described embodiments of the present invention can be implemented using any of a number of varieties of JAVA, however, those of ordinary skill in the art also recognize that the choice of the exact platform and language is often dictated by the specifics of the actual system constructed, such that what may work for one type of system may not be efficient on another system. It should also be understood that the methods described herein are not limited to being executed as software on a microprocessor, but can also be implemented in other types of processors. For example, the methods could be implemented with HDL (Hardware Design Language) in an ASIC (application specific integrated circuits).
TopN measurements, as discussed herein, are described in co-pending United States Patent Application XX/XXX,XXX, entitled: METHOD FOR IMPLEMENTING TOPN MEASUREMENTS IN OPERATIONS SUPPORT SYSTEMS, filed on the same day as the present application and assigned to the same assignee. The 'XXX application is incorporated herein by reference.
The core of the OSS 100 is one or more diagnostic measurement servers (DMS) 102. The primary function of the DMS 102 is to manage and analyze data collected by agents 104n. Some of the typical functions of the DMS 102, include: storing and maintaining all measurement data; calculating baseline and thresholds; determining the health of elements of the system under test; implementing actions when a threshold is exceeded or a health state changes; and configuring agents.
The agents 104n are responsible for running test, collecting measurements and forwarding measurement data to the DMS 102. Typically, at least one agent 104n is installed on the DMS 102. Other agents 104n may be installed on elements of the system under test, such as an FTP server 106, and SMTP server 108, and a HTML server 110. Agents 104n run independent of the DMS 102, in other words the availability of the DMS 102 does not affect the operation of the Agents 104n. Agents 104n are configured to interact with the elements they are to measure, for example agent 104b will use simple mail transfer protocol to communicate with SMTP server 108.
The DMS 102 utilizes the service model 114 to identify elements of the system under test. The service model 114 integrates elements of the system under test into a hierarchical tree structure that permits the visualization of elements and their interdependencies. The service model is more fully explained in U.S. Pat. No. 6,336,138, entitled Template-Driven Approach For Generating Models of Network Services, issued Jan. 1, 2002 and incorporated herein by reference. The DMS 102 stores information, including measurements, in at least one database, such as the database 112. The database could, for example, comprise an ORACLE database.
Graphical user interfaces 116n interact with the DMS 102 to provide a user with displays that facilitate interaction with the DMS 102 and agents 104n. Functions of the user interface include building and managing the service model 114; defining thresholds; defining event triggers; viewing events, and viewing graphs, reports, and service level compliance agreements.
Next, in step 204, user input is received indicating a selection, e.g. a node, on the navigation interface for which a graphical display is desired. In step 206 a determination is made as to whether the user has requested an alternative graphics display or whether the default graphics is acceptable. Generally, by left clicking on a node the user signifies that the default graphic is acceptable. Right clicking on a node will present the user with a pop-up menu related to alternative graphics (discussed with respect to steps 212 through 222).
Assuming that the default graphic was selected, the method proceeds to step 208 and a default graphical display is generated based on default preferences associated with the selected node. Preferences include: time frame to be displayed; time intervals; whether to display thresholds; whether to display baselines; preferences related to grid lines (thickness, scale, etc. . . . ); preferences related to legends (font, size, placement, ect. . . . ); and preferences related to labels (font, size, placement, ect. . . . ). The Examples of displays may be found in FIGS. 5 though 11 and will be discussed in more detail hereinbelow.
In step 210 a determination is made as to whether the user desires to see the data presented in an alternative graphic or view a graphic illustrating data related to the current data set. In the first instance, the method proceeds to step 212 where the request to view the data using a different graphic is recognized. In the second instance, the method proceeds to step 224 where the request to view a graphic for a related data set is recognized. If neither an alternative graphic nor a related data set is desired, the method proceeds to step 234.
If an alternative graphic display is desired, in either step 206 or 210, the method proceeds to step 212, where the request is received. This generally comprises a right click on the node for which an alternative display is requested. If a default display has already been completed, this may comprise a right click on the default graphic. It is to be noted that various methods exists to facilitate the indication that some action is required and that such methods vary with the operating system. Once the request has been received, the method proceeds to step 214 where a determination is made as to what alternative graphics are available. This determination is more fully discussed with respect to
In step 216, a display is generated providing the user with indications of what alternative graphics are available. It may prove preferable to provide generic graphical representations of the available types of alternative graphics. It is envisioned that alternative graphics generally comprise different graph types. For example, if the default graph is a measurement graph, e.g. a series of values plotted over time, alternative graphs may include: a health graph (wherein the health state of the node is indicated for each time period, typically using green, yellow, and red icons); a histogram; a geographical representation; tables of data and a time series, etc. . . . It is to be understood that other types of displays may be provided as options to the user, such as the textual display of the data from which the graphs are derived.
Next in step 218, the user selects an alternative graph to display. In step 220, the default display preferences are retrieved for the selected graph type. As noted above the display preferences may include, for example: time frame to be displayed; time intervals; whether to display thresholds; whether to display baselines; preferences related to grid lines (thickness, scale, etc. . . . ); preferences related to legends (font, size, placement, ect. . . . ); and preferences related to labels (font, size, placement, ect. . . . ). Subsequently, in step 222, the alternative graphic is displayed using the default preferences. The method then proceeds to step 234.
If in step 210, the creation of a display of a related data set is requested, the method proceeds to step 224, where the request is received. This generally comprises a right click on the element on the graph for which an alternative display is requested. It may also comprise a right click on a selected node. It is to be noted that various methods exists to facilitate the indication that some action is required and that such methods vary with the operating system. Once the request has been received, the method proceeds to step 226 where a determination is made as to what alternative data sets are available. This determination is more fully discussed with respect to
Related data sets include: data sets from the same source over a different time period; data underlying an aggregated data point (such as a Top N value); data referenced by a parent node in the service model; data referenced by a child node in the service model; information about the node being viewed; and navigation information linking to external data (such as a database or web site related in some manner to the selected node). It may also prove useful to consider alternative graphics as a related data set and integrate them into the available options.
Once the available related data sets have been identified, they are displayed to the user. In this case it may prove preferable to simply provide a textual list of the possibilities—although graphical representations, such as icons can certainly be used. In step 230, the user selects which related data set he wishes to view. In step 232, the default graphic for the selected data is generated. The method then proceeds to step 234.
In step 234, a determination is made as to whether the user desires to change the display preferences. If such changes are desired, the method proceeds to step 236 where the user indicates which display preferences to change. In step 238, a new display is created based on the changed preferences.
Once the new graph has been display, or if no changes are required in step 234, the method proceed to step 240 where a check is made as to whether the user wishes to exit the method. If an exit is desired, the method ends in step 242, otherwise a return is made to step 210 or step 204.
In step 404, available zooms are identified. Generally, zoom levels are identified by routines associated with the GUI 116n based on a current zoom level. As used herein, the term zoom generally refers to the time period associated with the displayed graphic, e.g. 1 hour, 1 day, 1 week . . . Thus, if an entire data set from a 1 day block was currently displayed, there might exist the possibility for two levels of zoom—1 hour and 1 week.
In step 406, indications of the available related data sets are returned, e.g. to the GUI 116n.
Under each service node 504n, two additional intermediate nodes 506n and 508n represent collections of measurements related to service metrics (506n) and the actual servers related to the services (508n). Measurement nodes 51 On under the intermediate nodes (only nodes 506n being shown as expanded) represent various measurements, each with an associated default graphic display, available for viewing. Three types of measurements are shown, as examples, for each expanded branch: Availability; Total Response Time; and TopN Total Response Time.
Further details of the navigation mechanism illustrated in
In
The menu 1006 provides several related data sources, including options facilitating: looking up the node in the service model; retrieving node information from the service model; zooming (in and out); pulling up graphics associated with parent and child nodes; and graphing derived sources (individual sources of data underlying an aggregated data point). With respect to
a, 11b, and 11c are representations of displays in accordance with an embodiment of the present invention. The displays illustrated in
Although some embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes may be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the claims and their equivalents.
